Re: [TLS] HSM-friendly Key Computation

[Eric Rescorla <[e-mail]>]

On Thu, Apr 23, 2015 at 7:02 AM, Ilari Liusvaara <
[e-mail]> wrote:

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


My proposal for HKDF is to have null-terminated labels (in the same
way as for the signing contexts.




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


Can you explain what you mean by "perturbs"? If you include the session hash
it includes the randoms.


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


It's not FixedDH, it's the servers semi-static DH and the client's
ephemeral.

-Ekr


> -Ilari
>