On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex <m...@sap.com> wrote: > 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.
That is true in TLS 1.2, but one of the things that have been addressed in 1.3. > 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. Again, true in 1.2 but 1.3 has fixed the groups to stronger values. Also, the key-generation of DHE is significantly cheaper than the key-agreement so ephemeral values might be more reasonable then benchmarks suggest. As noted, I think specifying a maximum caching duration is plausible. (Google servers cache QUIC X25519 values for 60-seconds, for example.) But I'm worried about an endless discussion about how long is too long (or long enough). > 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. The idea is to establish this in clients early in the life of 1.3 so that the pressure is enough to keep the ecosystem clean. I don't think that enforcing it in versions prior to 1.3 is viable. Cheers AGL _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
