Re: [TLS] proposal to encrypt ContentType for TLS 1.3

Eric Rescorla <> Sat, 05 July 2014 00:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 57BF61A0145 for <>; Fri, 4 Jul 2014 17:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tFPAnTq3DVKt for <>; Fri, 4 Jul 2014 17:12:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 868B21A0092 for <>; Fri, 4 Jul 2014 17:12:36 -0700 (PDT)
Received: by with SMTP id cc10so13559770wib.0 for <>; Fri, 04 Jul 2014 17:12:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=qMU58h7niSy9aZzWtoWSC4m+arQqVBTAFXHUE0Q8L3k=; b=iTNwwK/On8dD7mVQXDyG6W8aDV1cINYjDq7U4vNqXwMsf6aMqY5mWA2F0OxvyYHmaG bPp2j0t/eEAfUqopxWacVGJrRyAi5u1vU/BzSQgoHxy7dlZwW7ODIQcPCTKZBpd1uWDG Kb7CycR6bcv+DReaEKQwBJzGhM0lIxLuXSWVRzcw/iJvd1EkEqTGgetJMIFL72kg5cjl eJ/+W9ZzyTr13fcbK0Qt7nKAevXj/4mWGQe9kGreJ2UkGWjglQRBW5r/mdzppcDiLpom UwEMp2trG24ykEzA+zKY17pqbVMJ34n1bUFez3qtZI3eAAK0mcjeKMWcz9lAba7Rizq4 09AQ==
X-Gm-Message-State: ALoCoQk02xhEWIyTmvDyLekAw+heotWa/m4/r0l+/5SGTicqYZRZVKH07v2FSnKGcOQ1vND8jk5S
X-Received: by with SMTP id g20mr20122729wiw.7.1404519155200; Fri, 04 Jul 2014 17:12:35 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 4 Jul 2014 17:11:55 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Fri, 4 Jul 2014 17:11:55 -0700
Message-ID: <>
To: Daniel Kahn Gillmor <>
Content-Type: multipart/alternative; boundary=f46d04343946538e8104fd671983
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Jul 2014 00:12:39 -0000

On Tue, Jul 1, 2014 at 3:09 PM, Daniel Kahn Gillmor <>

> hey folks--
> i just opened a pull request to propose that the TLS ContentType (when
> actually using a proper cipher) should itself be encrypted, rather than
> in the clear:
> As the main commit in this request says:
> >     Move Content Type inside encryption
> >
> >     Previous versions of TLS have left the Content Type in the clear
> >     without justifying the exposure of this piece of information.
> >
> >     This change moves the Content Type inside the encryption to protect
> >     its confidentiality.
> >
> >     For backward compatibility during the initial handshake negotiation,
> >     we need to keep the type field at its original location on the wire
> >     for cleartext packets.  This means redefining the NULL_NULL case to
> >     not simply be an pseudo-cipher that implements the identity
> >     transformation, but to explicitly state it as sending the
> TLSPlaintext
> >     struct directly over the wire.
> I'd be interested in feedback on this suggestion.
> Having the content-type encrypted would mean that TLS alerts,
> handshakes, and application data would be indistinguishable from one
> another to an observer, once a ChangeCipherSpec had taken place.
> This also opens the way to consider the creation of other content types
> (e.g. "padded application data") without having to decide whether the
> exposure of a novel ContentType to an observer is itself a risk.
> If this change is made, it's also relatively easy to just drop the TLS
> version field for each encrypted TLS record layer fragment.

This seems like an idea with a fair bit of merit, but if I understand
correctly, it's going to result in a stream of data which cannot be
parsed into TLS records by existing network elements.
I'm concerned about how this is going to interact with various
elements which process the ciphertext. For instance:

- Protocol enforcement devices which expect to see a stream of records.
- RFC 5764 elements which multiplex STUN, SRTP, and DTLS and
  use the first byte for this purpose.

I think we can fix the second category by requiring explicit opt-in for
this feature, either by an extension or by it being TLS 1.3 (though
we would still need to define how to demux), but the first category
seems potentially more problematic. It seems like it might be worth
doing some experiments to see what the impact on success rates
is. [0]


[0] If this turns out to be a problem, there is an ugly but workable
solution, which is to have all TLSCiphertext records start with
an application_data type byte, regardless of their content. This
would of course expand packets by one byte.

> All the best,
>         --dkg
> _______________________________________________
> TLS mailing list