Re: [TLS] Encryption of TLS 1.3 content type

[Yoav Nir <[e-mail]>]

On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos <[e-mail]> wrote:

> On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote:
>> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd <[e-mail]>
> wrote:
>>> This is a change with no rationale: the content type leaks extremely
>>> limited information. It complicates implementations that wish to
> keep
>>> a high degree of codepath similarity between TLS 1.2 and TLS 1.3.
>> Leaking alert messages has been a recurring theme common to several
>> attacks; hindering a MITM's ability to discern alert messages seems
>> like a rational rationale.
> 
> Are there any pointers to these attacks? Will these attacks be countered
> with such a change? I believe not as alert messages consist of only two
> bytes and will be distinct from any other higher protocol messages
> transferred by the TLS record protocol. Unless TLS 1.3 intended to
> include a length hiding mechanism I see this change as unnecessary and I
> agree with Watson on that.

While no definite decisions were made, there was a positive response to the idea of allowing arbitrary length padding to the plaintext in all encrypted records, which can be used to hide alert messages. 

Of course, non-fatal alerts are (1) rare, and (2) not always treated as such, so it’s easy to spot the alert record, because it’s the one before the FIN or RST. In DTLS alerts are mostly non-fatal, so it makes more sense.

So on balance, +1.

> If we cannot avoid changes to TLS 1.3 charter, I believe that any new
> proposal comes with a concrete case for it and associated costs of
> implementing vs not-implementing. The initial agreement was for a small
> revision to TLS (even though I didn't agree on that), and that is now
> used as a vehicle to push unrelated to the charter major changes with no
> planning whatsoever. 

Our charter does say “Develop a mode that encrypts as much of the handshake as is possible”

Yoav