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

[Eric Rescorla <[e-mail]>]

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:
> >>
> >> > > PROTOCOL OPTLS:
> >> > >
> >> > > ClientHello
> >> > > ClientKeyShare
> >> > > ClientData* [K0]       -------->
> >> > >                                            ServerHello
> >> > >                                            ServerKeyShare
> >> > >                                            ServerCertificate* [K1]
> >> > >                                            ServerFinished [K2]
> >> > >                        <--------           ServerData* [K2]
> >> > > ClientFinished* [K2]   -------->
> >> > >
> >> > >
> >> > >             Protected Application Data [K3]
> >> > >                        <------->
> >> > > 1-RTT CASE:
> >> > >
> >> > > The basic 1-RTT case omits the ClientData* field. It includes a
> >> > > ClientKeyShare
> >> > > g^x and a ServerKeyShare g^y and an optional (encrypted) server
> >> > > certificate.
> >> > > If the certificate is sent (it can be omitted if the client has
> >> > > indicated
> >> > > that
> >> > > it knows the server key as in the case in the 0-RTT scenario) and is
> >> > > encrypted,
> >> > > the encryption key K1 is derived from g^{xy}.
> >> > >
> >> > > Key K2 is an encryption key derived from both g^{xs} and g^{xy}. It
> is
> >> > > used
> >> > > to
> >> > > authenticate-encrypt the ServerFinished and ClientFinished messages
> >> > > (which
> >> > > include a hash of the previous traffic) and to encrypt data from the
> >> > > server
> >> > > if
> >> > > such data is piggybacked to the second message.
> >> >
> >> > How does the client get the DH (or ECDH) group parameters used by the
> >> > server?
> >>
> >> Presumably from ServerHello (with CKS being optimistic).
> >>
> >> But the case where client misses all its guesses needs to be handled.
> >
> >
> > Unless I'm missing something, this can be handled the way that we
> > currently handle missed guesses, I.e., by having a HelloRetryRequest
> > followed by a new ClientHello/ClientKeyShare. Though of course
> > the server does need to either keep their RSA private key online
> > or periodically generate new signed DH shares for every group.
> >
> >
> >>
> >> 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.

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.

-Ekr