Re: [TLS] OPTLS: Signature-less TLS 1.3

[Watson Ladd <[e-mail]>]

On Sat, Nov 1, 2014 at 2:45 PM, Eric Rescorla <[e-mail]> wrote:
>
>
> On Sat, Nov 1, 2014 at 2:07 PM, Watson Ladd <[e-mail]> wrote:
>>
>> On Sat, Nov 1, 2014 at 7:46 AM, Eric Rescorla <[e-mail]> wrote:
>> >
>> > On Sat, Nov 1, 2014 at 3:16 AM, Ilari Liusvaara
>> > <[e-mail]> wrote:
>> >>
<snip>
>> >>
>> >> However, this poses some challenges with respect to revocation. From
>> >> what
>> >> I
>> >> understand, the parameters are intended to have limited lifetime (much
>> >> shorter than EE certificates).
>> >>
>> >> The reason this is problematic is that one can't really rely on clocks:
>> >> - Even if you happen to have sub-second accurate clock, a lot of
>> >> computers
>> >> don't.
>> >> - The time protocols often aren't secured, allowing attacker to play
>> >> tricks
>> >>   with endpoint time.
>> >
>> >
>> > We're already starting to have that problem because of a desire to move
>> > to
>> > OCSP
>> > stapling, which, with staple, effectively gives the server a credential
>> > which is
>> > valid only within a fairly narrow window. However, I think you're right
>> > that
>> > this
>> > probably limits the range of lifetimes you can use with these signed DH
>> > keys.
>>
>> That's not the problem Illari was talking about: It's not that g^s has
>> limited lifetime, but that there is no way to know that the lifetime
>> is expired, so it has long lifetime. NTP is not secure, so we have to
>> deal with bad clocks. In the case of certificates, this is usually not
>> so bad as the lifetimes are long. It might not be a problem for this,
>> as we can occasionally resign, keep s in memory and not be worse off
>> than today, or say that TLS clients need trusted clocks to avoid
>> compromise when s is revealed.
>
>
> Yes. I understand this. My point is that OCSP Stapling is effectively
> like short-lived certificates (and short-lived DHE shares) in that
> you have a credential which is valid for a relatively short period of
> time and which therefore requires that therefore requires tight
> clock synchronization. And since we're moving towards OCSP
> stapling and short-lived certs, we've got this problem in any case.

Ah, I was thinking of a different problem with OCSP stapling, which is
getting the response to staple periodically, and when you don't...

Thinking about it more, I think I don't understand this. X509
certificates have expiration dates. Doesn't that mean the client needs
a synchronized clock already? Why does the duration of the validity of
the response affect the existence of this issue?

With OCSP stapling this problem gets worse because there is no
freshness: it's a stapled response, and one of the security goals was
making revocation take hold quickly So I think an attacker who can
play games with time can already break OCSP stapling. Here we're
limiting the validity time of something equivalent to a certificate,
to deal with all sorts of problems that could lead to disclosure of
secrets.

But it seems like this mechanism might not work, because of endpoint
timing issues where the attacker gets to set the clock. How much worse
off are we than when certificate expiration times or OCSP validity
times get played with?

>
> Arguably, the situation is slightly better here because the server
> gets to select the key lifetime and so it can tune it depending on
> its assessment of client clock accuracy, which is unlikely to be
> the case with OCSP stapling.

The problem isn't that the client has an imprecise clock: +/- 10
minutes should not pose a problem. The problem is an that an attacker
can set the clock to whatever they want if they control the network.
Tuning the validity period doesn't change this. It's not an
operational issue, but a security issue.
>
> -Ekr
>

Sincerely,
Watson Ladd