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: > > On Wed, Sep 7, 2016 at 7:18 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > > > > > > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <h...@ee.technion.ac.il> > > > wrote: > > > > > > I also have a problem with names. "Resumption context" is very explicit > > >> about providing, well, resumption context. > > >> "Hello_Finished", in turn, means nothing. > > >> Also, RC may better match the notion of "binder" hence more naturally > > >> requiring collision resistance, while all Finished uses in TLS (1.3 > and > > >> before) have a MAC functionality (for which, say, 128 bits are good > enough) > > >> and it would be better not to abuse them for other uses. > > >> > > > > > > Two points about this: > > > > > > 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash > is > > > SHA-256, so I believe we have enough strength here. We could of course > > > require a minimum size. > > > > > > > If you keep this, you definitely need to have a minimum size > specification > > in boldface. > > Well, the PRF hash is already assumed to be CR, and if HKDF is used with > certain restrictions, it preserves CR: > > - 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. - 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. 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. > Furthermore Finished construction uses HMAC. There for CR-preserving, > one needs key to be of constant length (it always is hash_olen). > > > Then there's things that are "nonces": > > - Exporter master secret > - Resumption master secret > - hello_finished > - Some outputs of TLS exporter (depending on application). > > So I would be more concerned about some future extension changing the > way things are computed, breaking CR-preserving, or someone adding a > weak PRF hash. > > Agreed. > > (Of course, if SHA-2 breaks, we have really messy practical problem > too...) > > > > > 2. I wouldn't object to changing names here, of course. > > > > > > > I think that's a must. "Finished" says absolutely nothing about the > > functionality of this extension (it may actually mislead to think of it > as > > a MAC of some sorts). > > Call it something that can be understood as "PSK Creation Binder" and > make > > sure to specify (and explain in English) that all the values in the key > > derivation chain to lead to this value are collision resistant mappings > of > > the original handshake context (including the server's certificate). > > 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]. > > > [1] Apparently combined authentication is to be in separate spec[2], but > the main spec needs to be safe with it. > > [2] There apparently the server signature_algorithms to "support" that, > except I can't figure out _any_ use for that except a footgun[3]. > > [3] If using PSK, it has ill-defined semantics. If not, it pretty much > only useful for attacking the client. > I could not follow this argument. Hugo > > > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
