Re: [TLS] HSM-friendly Key Computation

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 23, 2015 at 05:54:02AM -0400, Eric Rescorla wrote:
> On Thu, Apr 23, 2015 at 4:42 AM, Ilari Liusvaara <
> [e-mail]> wrote:
> 
> > On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
> > > On 4/22/2015 1:37 PM, Eric Rescorla wrote:
> > > >If we're using HKDF-Extract, can we just key off different labels?
> > > >
> > > >-Ekr
> > > >
> > >
> > > Basically, no.
> > >
> > > What you want to do is specify as part of the mixins (e.g. 'info' - e.g.
> > the
> > > collection of label and context)  a set of fields that describe 1) how
> > the
> > > key stream is going to be broken up (eg. lengths of the sub keys), 2)
> > what
> > > algorithms will use each of the parts of the key stream, and 3) whether
> > or
> > > not those parts are allowed to be exported/extracted.
> >
> > In TLS 1.2 P_hash (which underlies TLS PRF), the corresponding field is
> > seed,
> > right?
> >
> > So inside that (or whatever the equivalent), serialize:
> > - Label
> > - Lengths, types and exportable flags of subkeys
> > - Context
> >
> > ?
> >
> > Properly serializing that would avoid the well-known TLS 1.2 screwup in
> > PRF defintion (which got copied to "dh based key exchange" draft).
> >
> 
> Can elaborate on this?
> 
> The DH-based key exchange draft uses HKDF and uses separate
> labels for each use of HKDF-Expand so that (for instance) exporters
> and key generation have different labels.

The label+seed thing.
 
> > Also, it occurs to me that if PRF has salt input (like HKDF), one should
> > stick something non-secret but variable there (e.g. client random, or
> > suitable handshake hash, or something).
> 
> 
> Based on talking to Hugo, my understanding is that the best way
> to do this is by incorporating the handshake hash at the HKDF-Expand
> stage, as in:
> 
> client_write_key = HKDF-Expand(Secret, "client write key" + session_hash,
>                                  SecurityParameters.enc_key_length)

Except that now nothing preturbs the secret extraction. Even HKDF RFC
says things like "adds significantly to the strength" and "strengthening
the analytical results that back[...]design".

Also, in where I try to work the simplest key derivation that I think
will work at all (supports 0RTT and (DHE-)PSK, but not fixedDH), I have:

[...]
master_secret = PRF(premaster_secret, "TLS1.3 master secret", hash_1)
[...]
client_hs_key = PRF(master_secret, "Client Key expansion")
[...]
client_app_key = PRF(master_secret, "Client Key expansion", hash_5)
[...]

hash_1 is hash of unencrypted parts, hash_5 is hash of the entiere
handshake. One can stick hash_1 into client_hs_key derivation if one
wants to (but it is still needed in master_secret).

(the rekeying is to deal with kp attacks from key exchange or if
somebody does dumb things with DTLS).

Also, if it had client_application_master_secret, then derivation
of that would have the hash_5.

> Some outputs share a (key,salt)
> > pair. Keys should be combined by serialization.

Ah, I just remembered what the "Keys should be combined by serialization."
meant: If one has multiple keys one needs to feed in, one should serialize
those into a block and then feed that as a key input (not doing things
like feeding secret keys as salts).

The "Some outputs share a (key,salt) pair." means that there may be places
where multiple keys are derived at the same point out of the same master key.

E.g. on the thingy I was working on, there are 3 keys using (MS,hash3) and
2 using (MS,hash5). And if there is no client certificate, hash3=hash5.

> If you're referring to how we combine (say) the static DH and the ephemeral
> DH, what we had discussed was running K1 through HKDF-Extract to
> generate PRK1 and then using PRK1 as the salt for HKDF-Extract on
> PRK2. I.e.,
> 
>    PRK1 = HKDF-Extract(0, K1)
>    PRK2 = HKDF-Extract(0, K2)

AFAIK, nobody really uses FixedDH. And I think it was Adrei Popov who
described how to do 0RTT in simpler way.

Also, maybe the only interesting application of FixedDH is deniable
key exchange. Except that supporting that would cause major issues
elsewhere (and "DH based key exchange" is not deniable).


-Ilari