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

[Eric Rescorla <[e-mail]>]

On Sat, Nov 1, 2014 at 3:22 PM, Watson Ladd <[e-mail]> wrote:

> 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?


Yes, it does.



> Why does the duration of the validity of
> the response affect the existence of this issue?
>

My argument here is that clients have some ability to sanity check
network time information, and so it's not necessarily like the attacker
can set the time to anything (I don't know how NTP clients currently
work). So an attacker who can only move the clock by a day or
two is going to of course be more effective attacking credentials
with a short time window than with a long time window
(though arguably that's because the latter is less secure to start
out with).

Does that make sense?

-Ekr