Re: [TLS] confirming the room’s consensus: adopt HKDF PRF for TLS 1.3

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, 2015-04-01 at 17:21 -0400, Sean Turner wrote:
> > ----- Original Message -----
> >> This message is to confirm the consensus reached @ the IETF 92 TLS session in
> >> Dallas and at the TLS Interim in Seattle to make the TLS 1.3 PRF be an
> >> HKDF-based PRF (see
> >> http://datatracker.ietf.org/doc/rfc5869/?include_text=1).
> >> Please indicate whether or not you agree with the consensus by 2015-04-17.
> >> If not, please indicate why.  Also, please note that we’re interested in
> >> uncovering new issues not rehashing issues already discussed.
> > 
> > I believe the question is totally unwarranteed. No-one has presented any argument
> > on why the TLS PRF is not sufficient for its purpose. The only arguments presented
> > are theoretical advantages of HKDF, which are fine, but do they add value to TLS?
> > Does the advantages of HKDF translate into weaknesses of the TLS PRF?
> 
> Both ekr and I queued the whole discussion up with there’s "nothing really wrong" with the PRF as far as we know.  The discussion in Dallas starts about 2:31:15 on audio stream - listen for a muffled ekr saying "oh god":
> http://www.ietf.org/audio/ietf92/ietf92-oak-20150326-0900-am1.mp3
> 
> At about 2:34:47 of the audio stream, Hugo discuses some of the “sub-optimal” aspects of the current PRF.

Ok, if I can summarize the argument presented against the current PRF is
the fact that it works well when the input (pre_master_secret) is
uniform but not otherwise. So in the words of the speaker it works well
for the RSA ciphersuites because the premaster secret is simply a random
nonce, but not in the other ciphersuites. My words now. The other
ciphersuites are Diffie-Hellman and Elliptic curve Diffie-Hellman. In
these cases the pre-master-secret is the negotiated key. I've seem
several cryptographic proofs assuming that the negotiated key in DH and
ECDH is uniform, but indeed that may not be correct, and let's accept
the speaker's argument.

So we have a problem in the TLS handshake, and we have decided in an
afternoon to replace the PRF with what the speaker suggested which is
HKDF. That also happens to be the speaker's invention. That's pretty
much expected of course. Shouldn't, however, the WG investigate whether
there are better alternatives to fix the problem? Shouldn't other
cryptographers asked to say their opinion on the fix and the issue?
That's what the WG did with Salsa20 proposal, asked the CFRG. Maybe
there are even more issues in the current PRF we don't know. In any
case, HKDF is not bad choice, it is a good choice and already used in
IKEv2. However, I am not an expert in PRFs, but I still see many design
similarities in HKDF and the TLS PRF. So I wonder whether there are
better from these two choices which we will never know if we only listen
to one opinion.

> > So no matter the output of that poll the result will be an uneducated guess. In all cases
> > it is alarming to see the easiness with which the protocol is being rewritten completely.
> > Now its only similarity with TLS 1.2 is the TLS acronym. Would that rewrite bring value
> > in par with the efford needed for the rewrite? Would it make us safer in 2030 or are we
> > simply apply yesterday's technology today?
> I guess I don’t follow - the PRF changed in previous versions and we kept the “TLS” moniker.

That's not the comment I make. My main concern is "Would that rewrite
bring value in par with the efford needed for the rewrite?". In that
particular case with HKDF; is HKDF the best choice we can do now to keep
us with a good PRF until 2030?

regards,
Nikos