Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

[Adam Langley <[e-mail]>]

On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley <[e-mail]> 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 [e-mail] https://www.imperialviolet.org