On Fri, Sep 9, 2016 at 4:22 AM, Ilari Liusvaara <ilariliusva...@welho.com>
wrote:
> On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> > On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> > >
> > > - The hash has output length at most input length (true for all SHA-2
> > > variants)
> > >
> >
> > Just curious: Can you explain the need for this property? Note that if a
> > key to HMAC is larger than the (compression) function output size then
> > this key is first hashed into a full output hence preserving CR.
>
> Simply me not bothering to figure out what the heck HMAC does if this
> isn't true (or if it is even well-defined in all cases).
>
> > - HKDF-extract salt length is constant (in current draft, always
> hash_olen)
> > > - HKDF-expand PRK length is constant (in current draft, always
> hash_olen)
> > > - The HKDF-expand output output length is at least hash output length
> > > (in current draft, hash_olen except in key expansions).
> > >
> >
> > These are a lot of restrictions that no one has spelled out as conditions
> > on the KDF and they do not follow from the natural properties of KDFs.
> > Collision resistance is never needed as far as I can tell for generation
> of
> > keys or to compute PRF and/or MAC values (e.g., for the original
> > functionality of Finished that is essentially a MAC/PRF on the
> transcript).
> > The reason we find ourselves considering the CR properties of HKDF is
> that
> > we are using it to derive *strings* that serve as binders/digests of past
> > transcripts. Luckily, HKDF with the right hash functions can provide that
> > functionality but it is not a native KDF functionality.
>
> So I presume some more text for Security Considerations...
>
> > I do not mean this as an academic discussion (although we could have that
> > too) but as a warning for future (if not present) misuse and an obstacle
> in
> > replacing HKDF in the future.
> > I would be much happier if we had a clear distinction between PRF/MAC
> > computations, KDF computations and digest computations., even if we
> > currently used HKDF for all these functions.
>
> Unfortunately there are things like exporter outputs, that need to be
> both "secret" (i.e. "keys") and "nonces" (i.e. "binders"). At least if
> application wants so... Dropping either would cause MAJOR security
> problems.
>
> I think those and the dynamically provisioned PSKs are the only ones
> that have that property of being both key and binder.
>
I would much prefer to have two elements associated with such keys. One is
the key itself and the other is a binder (or whatever other name one
chooses for it) that consists of a context string or digest associated to
that key. Then, you would use the key to key crypto algorithms and use the
descriptor as a binder to the key's original context, usually as input to a
crypto algorithm (and not as a key). This will make the functionality of
each element (key or binder) more explicit and will make it clear when is
that we need collision resistance and when we don't.
Hugo
> > > It is a bit more problematic than that:
> > >
> > > The hello_finished / "PSK Creation Binder" derives from the PSK key.
> > >
> > > Deriving separate value in context of dynamic PSK provisioning does not
> > > work properly as "static" PSKs lack this value, and if one then tries
> to
> > > use such key with combined authentication, you got an attack[1].
> > >
> >
> > I could not follow this argument.
>
> Basically, one can't make a distinction between static ("non-resumption)
> and dynamic ("resumption") PSKs here. Because such distinction would
> run into security problems with some other features.
>
>
>
> -Ilari
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
