On 11/07/17 20:11, Christian Huitema wrote: > > For various reasons, some implementations may be tempted to use static > (EC) DH private key. Using such keys lowers the security guarantees of > TLS 1.3. Adversaries that get access to the static (EC) DH private key > can now get access to the content of the communication. Adversaries that > acquire the key in real-time can compromise the confidentiality of the > conversation. Adversaries that acquire the key later can use it to > access the content of recorded sessions, thus breaking the forward > secrecy promise of the protocol. TLS 1.3 clients should detect the use > of static (EC)DH keys by corresponding servers, and should treat servers > using such keys as compromised. Clients can perform this detection by > comparing keys proposed by servers at different time, or by cooperating > with other clients to compare the keys proposed to them by servers.
I generally like the idea of such text but I'm not at all sure client detection is really feasible in the general case. It'd seem possible for a server to hold a rather long list of re-used static DH values and unlikely for normal clients to detect those. And it also seems like an arms race too, e.g. if a special zmap-like survey was used to detect this kind of bad crypto. Still worth testing for no doubt, (it'd make for a nice academic publication) but I'm not sure detection could be sufficiently probable that we could make the statement above. Speaking of text changes though, if this wiretapping scheme were to be adopted in any sense, there would be a load of tweaks to text in tls1.3 needed as a result - starting with the abstract to -21 for example as we could no longer say that TLS is "designed to prevent eavesdropping" without a highly embarrassing qualifier. (Hence my request to not have this discussion until after DTLS1.3 is done - and chairs if you're reading this please do reconsider.) Sigh, S.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
