Subject: Re: [TLS] Simplifying the record protocol

From: Tom Ritter <[email-masked]>
Date: Tue, 10 Jun 2014 22:56:18 -0400

On 19 May 2014 15:26, Martin Thomson <[email-masked]> wrote:

> On 19 May 2014 12:04, Adam Langley <[email-masked]> wrote:
> > On Mon, May 19, 2014 at 11:57 AM, Andy Lutomirski <[email-masked]>
> wrote:
> >> There is a lot of redundancy here.  The type, version, and length appear
> >> twice.  Of those, the version appears to be almost completely pointless,
> >> and the type and length don't need to appear twice.  If I'm counting
> >> right, fixing this will save six bytes in every record.
> >
> > Putting the version in every record is a waste, but TLSPlaintext and
> > TLSCiphertext don't work in the way that you think: the type, version
> > and length aren't repeated on the wire. TLSPlaintext is more of a
> > conceptual structure. A TLS record, on the wire, contains only the 5
> > byte header of the TLSCiphertext.
>
>
> Bad presentation in RFC 5246 notwithstanding, I think that Andy's
> proposal has merit.  This drops the version, encrypts the type.
>

An advantage of encrypting the content type is making it possible for TLS
padding to be built-in for no additional bytes. The existing content
Content Type means no padding, and a new Content Type means the plaintext
is padded, and the receiver should strip off the padding after decryption
and ignore it.  Encrypting the Content Type is necessary for this approach
so that an observer can't be certain there is padding happening or not.

-tom

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 11 Jun 2014 09:44:41 +0200

On Tue, 2014-06-10 at 22:56 -0400, Tom Ritter wrote:

> An advantage of encrypting the content type is making it possible for
> TLS padding to be built-in for no additional bytes. 

TLS padding can be built-in for no additional bytes and for no change in
outside format of the TLS record:
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

regards,
Nikos

---

From: Tom Ritter <[email-masked]>
Date: Wed, 11 Jun 2014 10:46:53 -0400

> http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
I would strongly prefer padding not to require an extension and be built
in. While some extensions could be protected in an encrypted handshake (See
Type B extensions in [0]), this would require a significant change to
extensions and I'm not banking on it.  So assuming that extensions are in
the clear, I would prefer an observer be unsure if there is padding or not.

This is especially important because a large class of attacks we want to
defend against are passive attacks, where the observer has only a single
traffic stream and wants to try correlation, and is unable to induce
multiple sends or streams with which to try statistical or timing
correlation.

(Re-reading the draft and minutes[1]) I believe that the padding in this
draft, if we remove the extension, would add an additional two bytes to all
messages to be unambiguous and indicate if there is padding or not. If I'm
wrong about that, I don't think I'm the only one so I'd be happy to be
corrected.

My goal is to get padding support (for receiving, not necessarily sending)
built in to the protocol, with no additional on-wire bytes for people who
don't want to pad, and with no plaintext indicators of whether padding is
being done or not.

-tom

[0]
http://www.ietf.org/proceedings/interim/2014/05/15/tls/slides/slides-interim-2014-tls-1-4.pdf
[1]
http://www.ietf.org/proceedings/interim/2014/05/15/tls/minutes/minutes-interim-2014-tls-1
around "Padding issues "