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

[Hugo Krawczyk <[e-mail]>]

0-RTT with (EC)IES is exactly what we are doing.
Keeping online signatures is what the WG wanted (the other option is
offline signatures or DH certificates which had opposition).
If you can come with a simplified design combining these things, I will be
happy to hear.

The KDF derivation scheme is as simple as it gets for all keys that need to
be derived and is uniform for all modes.
You could save one level of extraction if you were willing to key the prf
with your DH secrets, which I do not recommend.

Hugo


On Mon, Mar 23, 2015 at 4:54 PM, Ilari Liusvaara <
[e-mail]> wrote:

> On Mon, Mar 23, 2015 at 03:22:05PM -0400, Hugo Krawczyk wrote:
> > Hi Nikos,
> >
> > These are good questions - see responses below.
> >
> > On Mon, Mar 23, 2015 at 11:05 AM, Nikos Mavrogiannopoulos <
> [e-mail]>
> > wrote:
> >
> > > On Mon, 2015-03-23 at 08:36 -0500, Eric Rescorla wrote:
> > > [...]
> > > > The WG sentiment was generally favorable to exploring this avenue but
> > > > there was also airly strong WG sentiment that we didn't presently
> want
> > > > to do an offline signatures. This leaves with a model in which the
> > > > client initially learns the server's semi-static DH share through
> > > > an online-signed 1-RTT handshake but then can cache it for use with
> > > > future connections.
> > >
> > > Wasn't that discussed in the list before? My impression was that the
> > > outcome of that discussion was not to add that.
> > >
> >
> > ​The objections to the original proposal were related to the use of
> offline
> > signatures to sign a semi-static DH key. This is not an option in ekr's
> > draft. Neither the draft accommodates DH certificates. All server's
> > authentication is based on regular (online) TLS signatures except if the
> > client has cached a semi-static key from the server as needed to support
> > 0-RTT.
>
> I think that is the worst case.
>
> ECC signature generation are faster than ECDH operation. But OTOH, ECDH
> operation is much easier to implement than ECC signature. So one gets
> slowdown for no simplification.
>
> Also, two-level key schemes have certain benefits, but lack of offline
> signing makes it one-level key scheme with two keys.
>
> > > Anyway, a first question that comes to mind, is why this isn't defined
> > > as separate ciphersuites? Why does it even have to be TLS 1.3 related?
> > > Static DH parameters is an experiment that failed years ago. What has
> > > changed since then that we believe now it is going to work? You even
> > >
> >
> > ​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).
> >
> > The alternative is to keep TLS 1.2 and add to it the semi-static case as
> a
> > patch, hence requiring essentially implementing all that is now in ekr's
> > draft (for PFS and 0-RTT) plus all the mechanics of 1.2. From the
> > cryptographic analysis point of view this would mean analyzing two
> separate
> > protocols as well as making sure these two protocols do not have any bad
> > interaction when put together.
>
> The simplest way to do 0RTT would be for server to signal parameters for
> 0RTT in extension and then client to put public keys and 0RTT data
> ((EC)IES)
> into ClientHello extension (doesn't work that well in TLS 1.2 still).
>
> Of course, that provodes absolutely no replay protection...
>
> > > dropped the static DH ciphersuites from TLS 1.3. Please make that part
> > > optional so you don't doom the whole TLS 1.3 protocol enhancements if
> > > no-one switches to static DH keys (in the document they are described
> as
> > > semi-static DH keys - but there is no definition of what that means).
> > >
> > > A second question is why HKDF? Why is it even there? Is there any issue
> > > with the current TLS PRF and we need another? Is there a valid reason
> to
> > > bloat implementations with shipping multiple KDFs? This kind of changes
> > > shouldn't be done without thought, as it is now there cannot be any
> code
> > > sharing between TLS 1.2 and 1.3 and we risk having implementers stay
> > > with TLS 1.2 for the next decade.
> > >
> >
> > ​HKDF is just a way of structuring the use of TLS PRF (HMAC-PRF) in a way
> > that supports a uniform, hierarchical key derivation scheme which is
> common
> > to all the modes of the protocol as discussed above (including PSK,
> Export,
> > resumption, etc.) and which accommodates deriving keys from possibly
> > non-uniform secrets such as DH values, passphrases, etc. In particular,
> it
> > sets no requirements or assumptions in the form of the secret/entropy
> > source from which keys are derived, hence freeing the protocol
> > instantiation from things like point representation in an elliptic curve
> > (it will work with compressed representation, uncompressed ones, etc).
> >
> > I believe these are all huge benefits at all levels: design, analysis,
> > specification, implementation, maintenance of the protocol (future
> > changes/additions). I cannot comment on code sharing though, although I
> > hope we do not ruin the future by tying ourselves too much to the past.
>
> Well, to me the key derivation in EKR draft (using HKDF) looks much more
> messy than the one in editor draft (using classic TLS PRF)
>
>
> -Ilari
>