Re: [TLS] Finished stuffing

[Ilari Liusvaara <[e-mail]>]

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-mail]> wrote:
> 
> >
> >
> > On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <[e-mail]>
> > 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)
- 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).

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


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



-Ilari