Re: [TLS] HSM-friendly Key Computation

[Ilari Liusvaara <[e-mail]>]

On Thu, Apr 23, 2015 at 04:05:52PM -0400, Eric Rescorla wrote:
> 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:
> 
> Can you explain what you mean by "perturbs"? If you include the session hash
> it includes the randoms.

HKDF RFC seems to essentially say 'if you can use salt, do so'

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

Which semi-static DH (x client's ephemeral)?
- Current
- Previous (may not be available!)
- Both

For current, the only even semi-sane use I can come up with is server
fixedDH certs (this input not a good place to stick PSKs if one wants
"unified" something).

For previous, it is useful if 0RTT group can differ from main exchange
group (but server has to signal if this is to be included or not, since
it may not be computable).

(And both for when both of above apply).


Also, it occurs to me that trying to stick keying data into non-key
PRF inputs may not be a good idea...

And the signature looks more complicated in draft "DH based key exchange",
because the params are in the same message as certificate verify, instead
of separate message (where hash would get it instead of having to be
included separatedly).


-Ilari