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

[Watson Ladd <[e-mail]>]

On Sat, Nov 1, 2014 at 4:22 PM, Eric Rescorla <[e-mail]> wrote:
>
>
> 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?

It does make sense, but it's wrong.

First, it's not clear that NTP works the way you think it does: my
laptop has no problem imposing a 15-hour jump on the system clock when
connecting to a timeserver after I fiddled with the clock. I'll try
some more tests to be sure that is what is going on, but I see no
description of such sanity checks in the OpenBSD manpage, or
OpenNTPD.org documentation, and haven't found it in the OpenNTPD code
yet. I've found documents indicating that OpenNTPD does change the
time massively on boot, namely presentations by the developers.

I've also had adventures when dual-booting where the RTC would get set
strangely on reboots, and ntp would straighten it out.

The protection that does exist on BSD systems is that the clock can
only be set backwards by adjtime(2) when in secure modes greater than
1. I don't think this used as much as it should be.

Secondly, suppose as an attacker I can twist time by a certain amount
d. This means any credential valid at any time in the range [t-d, t+d]
that I steal can be used at time t. The length of time the credential
is valid for doesn't enter into this analysis: while the attacker
would only be interested in doing this for short validity credentials,
the longer validity credentials are still useful if stolen. I don't
need to play any NTP games if I get the cert.

So to the extent that short-lived credentials work in the sense that
an attacker can only use them until a certain time in the future if
they extract them, it depends entirely on the value of d, which
currently is unbounded. Long-term credentials are just going to work
until they expire, and then plus d, just as short-term credentials do.
But it's more interesting in the case of short-term credentials.

Maybe being able to screw with the clock isn't a realistic assumption,
or we've already ruled it out. Certainly existing revocation
mechanisms can also be avoided in similar ways, under similar
conditions, and protecting system time isn't that hard conceptually:
NTP is massive overkill for most systems, being designed to attain
accuracies far beyond the few seconds a week computers can attain on
their own. So I don't think this security issue necessarily dooms this
proposal.

Of course, this is all moot if RFC 5906 is supported. However, it
seems that most NTP servers the public can use do not support autokey:
the best source for this is a debian bug where a member of the
pool.ntp.org team explains they can't set up an authenticated pool.

Sincerely,
Watson Ladd

>
> -Ekr
>
>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin