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

[Nikos Mavrogiannopoulos <[e-mail]>]

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.

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

regards,
Nikos