On 7/11/2017 6:11 AM, Ted Lemon wrote: > What the draft actually says is that you can install a fixed key on the > server rather than generating new keys every time, and then that fixed key > can also be installed on monitoring software. This is, I believe, the > actual intended use of the proposal. > > It’s also true that you can just exfiltrate every key as it’s generated, but > that’s not what’s being proposed and would not, I think, suit the needs of > the operators who are making this proposal. > > I don’t see how you could mitigate against deliberate key exfiltration. At > some point you really are relying on the security of the endpoint. But > being able to detect repeated keys is useful for preventing pervasive > monitoring: it requires the monitored either to have access to the key > generation stream in realtime, or to request the key for a particular > conversation. To paraphrase what Ted says using my own words, the use of static (EC)DH shares is an attack against the integrity of the TLS 1.3 protocol. I think this attack should be documented in the TLS spec, probably in Appendix E since the attack compromises security properties of the protocol, or maybe in Appendix C if we want to outline the implementation issues. Some text like:
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. -- Christian Huitema -- Christian Huitema _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
