Re: [TLS] HKDF

[Ilari Liusvaara <[e-mail]>]

On Wed, Mar 25, 2015 at 11:21:38AM -0400, Hugo Krawczyk wrote:
> On Wed, Mar 25, 2015 at 11:02 AM, Andrey Jivsov <[e-mail]> wrote:
> 
> > A problem with this is additional options.
> >
> 
> ​What are the additional options? ​
> 
> ​You use the defined hash function.
> 
> > There is no problem with HKDF that I see other than it relaxes assumptions
> > on hash functions,
> >
> ​Relaxing assumptions is not a problem but rather a good thing: It means
> that you need to assume less from the hash function, e.g. not having a
> scheme broken if collisions are found on that function.

TLS 1.3 already assumes prf-hash is collision-resistant.

Changing this is incredibly hard, requiring extreme effort. You would need
incredibly broad security proofs.

> > HKDF is probably viewed as an insurance. Please note that the benefits
> > will be bound by the "ad-hoc" methods to process entropy into private keys.
> 
> ​That's true, but these ad-hoc methods have a better analytical basis than
> just using non-uniform keys to key directly a PRF.

I'm not seeing how you can have any sort of adversarial input fed to TLS
PRF without having much more serious problems.

Prf-hash on the other hand needs to take full burnt of adversarial input,
with no strengthening at all. ​

> > One idea for meaningful reduction of complexity in TLS is if we could
> > switch to cipher-based KDF.
> >
> ​That's for the WG to decide but the results we have for the extraction
> properties of block-cipher based PRFs are much weaker.

Because you need a CR hash function anyway, you can't reduce complexity
that way.



-Ilari