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

[Eric Rescorla <[e-mail]>]

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.

-Ekr