On Thu, Dec 29, 2016 at 08:28:45PM +0100, Martin Rex wrote: > Adam Langley wrote: > > 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. > > 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 we add an alert to be sent in this case, it would be possible for the server to know why the clients were disconnecting and resolve the issue. -- Scott Schmit _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
