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

[Hugo Krawczyk <[e-mail]>]

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:
> > Folks,
> > At the interim discussed transitioning to a DH-based handshake (rather
> > than a signature-based one) like that proposed by Hugo Krawczyk and
> > Hoeteck Wee. The major rationale for this change is that any 0-RTT
> > mode is inherently DH-based and so if we make that our basic mode,
> > then we can simplify the protocol logic and key derivation model. This
> > model also allows us to pull in PSK modes under the same basic
> > structure.
> [...]
> > 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. In the latte case authentication must be done via the possession of
the semi-static DH secret by the server (a 0-RTT flow cannot be
authenticated via signatures).
​


>
> 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.

​


> 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.

Hugo
​


>
> regards,
> Nikos
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>