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

[Ilari Liusvaara <[e-mail]>]

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.
- The offline version avoids server to have implement online
  signature, simplifying the code a good bit (especially if the
  signature is apparently intentionally made difficult, like ECDSA).



-Ilari