On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley <[email protected]> wrote: > I don't expect that those who want to intercept TLS connections will > see a MUST NOT and go do something else. Rather I think they should > understand that TLS isn't supposed to be intercepted and, if they want > to do that, then they're going to be breaking the spec in places. I > think they're going to do that no matter what we do so I want to > ensure that these "interceptable" implementations don't inadvertently > proliferate. (Because if everything Just Works when you accidentally > copy such a config to your frontend server, then it'll happen.)
I had understood that the desire from some large institutions to intercept TLS connections arose only in a datacenter setting. However, based on private conversations, it appears that at-least one of those institutions does this on their public frontends and will very likely do something worse than persistent ECDHE if that's not possible with TLS 1.3. Thus the hope that we can detect and reject this configuration by default, and thus prevent unintended loss of forward security, without pushing people into implementing interception in a way that's even worse, appears to be gone. So I'm disappointingly now thinking that we should simply say that DH values "SHOULD NOT" be cached for more than 10 seconds. Something like SSLLabs can still warn when that's violated, but clients probably cannot enforce it without perverse consequences. Cheers AGL -- Adam Langley [email protected] https://www.imperialviolet.org _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
