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

[Ilari Liusvaara <[e-mail]>]

On Fri, Apr 03, 2015 at 08:49:24AM +0200, Nikos Mavrogiannopoulos wrote:
> 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.

Can be proven to work well. Big difference.

Furthermore, I think any attack here is at least one of:
- Banana attack.
- Requires seriously breaking the prf-hash.
- Requires seriously breaking other things than just PRF.

And "seriously breaking" means deprecate/replace this ASAP.

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

Furthermore, if prf-hash is even close to being collision-resistant
(which it has to be or some other stuff breaks), I really don't see
how feeding DH or ECDH outputs could cause problems.

Basically, if inputs are adversarial or overly long, you have worse
problems than what those inputs do to the PRF.

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

I know two problems with TLS PRF:

- Label/Seed separation.
  -> The way HKDF is used in the WIP has the exact same mistake.
  -> Could be fixed by maiking label to be ASCIIZ/UTF8Z.
     -> Close enough for many(?) existing implementations.
- Problems with key >1 input block.
  -> HKDF trips the problem with key >1 output block (which is more often)
  -> Big enough keys are mainly seen with (ff)DHE (or P-521 with SHA-256).

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

I think one could make PRF that is better than both TLS-PRF and HKDF,
but I don't know anything that really is.


-Ilari