Re: [TLS] Initial draft of DH-based key exchange

[Eric Rescorla <[e-mail]>]

On Tue, Mar 24, 2015 at 9:03 AM, Ilari Liusvaara <
[e-mail]> wrote:

> On Tue, Mar 24, 2015 at 09:28:29AM +0100, Nikos Mavrogiannopoulos wrote:
> > On Mon, 2015-03-23 at 15:22 -0400, Hugo Krawczyk wrote:
> >
> >
> > > ​Two important things change in TLS 1.3:​
> > > - Forward secrecy (PFS) is now mandatory.
> > >
> > > - The protocol accommodate a 0-RTT mode.
> > >
> > >
> > > These two changes can only be implemented via Diffie-Hellman
> > > transforms (in theory, any CCA-secure public key encryption can be
> > > used but (EC)DH is the only currently practical instantiation in this
> > > setting). In particular, 0-RTT requires supporting semi-static DH keys
> > > for the server. All that ekr draft does is to build a protocol where
> > > PFS is supported, 0-RTT is supported, semi-static keys are supported,
> > > and TLS-type signatures are supported in any case where the client
> > > does not have a cached semi-static key of the server. The beauty of
> > > it, if I can say so, is that all these modes are just subsets of a
> > > single protocol with a single crypto logic and uniform specification
> > > (which also covers uniformly PSK and resumption).
> >
> > So if I understand well the additional semi-static key is to support the
> > 0-rtt case only, and otherwise it should be simply a copy of the
> > ephemeral key? I cannot say I fully follow the protocol in all possible
> > scenarios. It would be nice to have a message flow of the interactions
> > for the DH key exchange in all the cases (e.g., PSK) either as an
> > appendix or the main text. As we are moving to non-widely known key
> > exchanges it makes sense to document them clearly, or at least link to
> > documents which define them.
>
> >From what I can understand, it adds interrim server DH key, which server
> signs (which may be the same as the server eph. key), computes DH of
> both with client eph. key and mixes those to become session keys
> (the interrim key can be reused to become 0RTT key for the next
> connection).
>
> So roughly:
> - Client: C_pub_e
> - Server: S_pub_e, S_pub_s, Sign(S_pub_s, handshake_messages)
> - 0RTT key: F(DH(S_pub_s_prev, C_pub_e)
> - Session keys: G(DH(S_pub_s, C_pub_e), DH(S_pub_e, C_pub_e))
>
>
> To me, this looks to lose all the benefits of of offline version:
> - The offline version is two-level key scheme, this isn't.
> - This version is quite a bit slower unless you disable 0RTT.
>

Note: we haven't yet determined how we are going to establish
the key for  future 0-RTT messages. You could reuse the key
as you said above, but you could also just send a second key
in a separate message, in which case you wouldn't have to take
the hit, but at slightly more protocol complexity.

-Ekr