Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

[Peter Gutmann <[e-mail]>]

Watson Ladd <[e-mail]> writes:

>As written supporting this draft requires adopting the encrypt-then-MAC
>extension. But there already is a widely implemented secure way to use MACs
>in TLS: AES-GCM. 

This is there as an option if you want it.  Since it offers no length hiding,
it's completely unacceptable to some users, for example one protocol uses TLS
to communicate monitoring commands to remote gear, they're very short and
fixed-length, different for each command, so if you use GCM you may as well be
sending plaintext.  In addition GCM is incredibly brittle, get the IV handling
wrong and you get a complete, catastrophic loss of both integrity and
confidentiality.  The worst that happens with CBC, even with a complete abuse
like using an all-zero IV, is that you drop back to ECB mode.

>Likewise, this draft modifies the way the master secret is computed, despite
>a widely implemented different solution to the problem, namely the EMS triple
>handshake fix. 

Firstly, that solves an entirely different problem, and secondly I don't
recall ever seeing EMS support in any embedded device, it may be widely
implemented in Windows and OpenSSL but I don't know how much further it goes.

>The use of uncompressed points makes off-curve attacks much easier than with
>compressed points. 

Everything uses uncompressed points at the moment without any problems, and
compressed points are patented.

>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively
>analyzed then TLS 1.2. 

As the rationale points out, the mechanisms in SSL were also very heavily
analysed when they were released.  It didn't protect the protocol from 20
years of subsequent attacks, which we've leared about over those 20 years of
implementation and deployment experience.  With TLS 1.3 we have zero
implementation and deployment experience.  Do you really believe there will
never be any attacks on it after it's rolled out?

Peter.