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

[Adam Langley <[e-mail]>]

On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir <[e-mail]> wrote:
> I’m assuming that the server generates private keys and saves them to a file
> along with the time period that they were used, and another machine in a
> different part of the network records traffic. It’s not so much that the
> clocks need to be accurate, as that they need to be synchronized, and there
> will still be some misalignment because of (variable) latency.
>
> I guess we are making guesses about systems that haven’t been written yet.

Addressing a few messages in one:

I didn't intend that this MUST NOT just be a "MUST NOT (but we know
you will)". I agree they're pretty useless. Rather I want this to be
checked in some clients and in tools like SSLLabs. I have some faith
that such measures will work to push an ecosystem towards correctness.

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.)


Cheers

AGL