Re: [TLS] Requiring that (EC)DHE public values be fresh

[[e-mail] (Martin Rex)]

Adam Langley wrote:
>
> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
> specifies that (EC)DH values must be fresh for both parties in TLS
> 1.3.
> 
> For clients, this is standard practice (as far as I'm aware) so should
> make no difference. For servers, this is not always the case:
> 
> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
>   ? 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more
>     than a day.
>   ? 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day.
> 
> Since this defeats forward security, and is clearly something that
> implementations of previous versions have done, this change
> specifically calls it out as a MUST NOT. Implementations would then be
> free to detect and reject violations of this.

While you may have good intentions, the idea "and reject violations of this"
sounds like a bad idea to me.

First of all, forward secrecy is equally defeated by TLS session caching
(traditional as well as session tickets), and the effect of rfc5077
TLS session tickets is likely at least a magnitude worse--and cannot
be "fixed" by clients purging the tickets earlier.

Reuse of DHE values should not come as a surprise, PFS with DHE is
prohibitively expensive with 2048+ bit ephemeral keys.  DHE in TLS has
been well known to be fatally flawed (publicly known since the issue
was raised by Yngve on the TLS ietf mailing list in 2007).
  https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7,
i.e. on Billions on devices out there, DHE in TLS is a very dead horse.


Ephemeral ECDHE values should be much less painful performance-wise,
but may happen to accidentally share the same properties as DHE values.
Potentially, the (EC)DHE keypairs are (mis-)managed above the TLS stack,
instead of entirely within--in which case this would not be the fault of the
TLS implementation code, but of the TLS implementation API (design).


Now what does it mean when a _client_ that happens to connect to one
of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a
reuse of ECDHE on a repeated full handshake (which will not happen
immediately due to session caching&resumption).  This would result
is random handshake failures (client aborting the TLS handshake).
The server doesn't know why the client chokes, only the client can
decided to retry, but this is unlikely to affect the servers approach
to reusing the (EC)DHE value at all.


So the only thing this will cause is headaches to users and support
folks.  It will *NOT* improve the security by one iota.
 

If you want to improve something, then specify how to obtain the
desired behaviour, not how to panic and choke.



-Martin