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

[Eric Rescorla <[e-mail]>]

On Mon, Mar 23, 2015 at 10: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.
>

There was enough interest that we decided to revisit it at the interim
in view of the considerations I listed above, and the chairs asked
me to draft it up so we could discuss here and in Dallas. As I said
above, the WG can of course decide not to proceed in this direction
which is why this is a separate branch rather than -06.



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

Well, what's being done here is qualitatively different in three ways:

1. The DH keys aren't in DH certificates (though one supposes they
    could be), rather they are attested to by the server signing key.

2. The semi-static DH keys are expected to be quite short-lived
    (possible because of point #1). Hence 'semi-static'.

3. We are doing a separate ephemeral-ephemeral DH exchange to
    provide PFS.

The argument for not making it a cipher suite is that doing things
this way allows us to have a unified protocol logic whereas that's
not true if it's a separate option.




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?


As I said separately [0], there was some sentiment in the interim that
HKDF was a more modern primitive. As above, I can easily back this
out and use the existing PRF if that's what people prefer.

-Ekr


[0] https://www.ietf.org/mail-archive/web/tls/current/msg15625.html