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

[Martin Thomson <[e-mail]>]

On 1 July 2014 15:09, Daniel Kahn Gillmor <[e-mail]> wrote:
> If this change is made, it's also relatively easy to just drop the TLS
> version field for each encrypted TLS record layer fragment.

I'd like to see that happen.

I think that the bit that causes me a little concern is that content
type shifts around, with a special case.  If you have a special case
like that, then there isn't much of a difference between moving it
while under encryption to moving it always (other than the need to
keep ClientHello clean.  But that doesn't seem like the right answer
either.

It's more disruptive, but if the definition of the AEAD cipher were to
encompass the entire struct, then you could define NULL_NULL in a way
that placed content type in the old location.  I don't know if that is
any better, though it would probably be the way I'd structure software
that processed the record layer.

Then you have a different structure in place of TLSCipherText on which
the construction depends on the cipher.  NULL_NULL can define
something that looks like legacy TLS: ContentType, Version,
Payload.length, Payload.data.  Ciphersuite constructions can define
something like this: Payload.length, Nonce, Encrypted { ContentType,
Payload.data }; with variance discouraged, but possible.