Re: [TLS] HSM-friendly Key Computation

[Ilari Liusvaara <[e-mail]>]

On Mon, Apr 20, 2015 at 12:09:56PM -0400, StJohns, Michael wrote:
> On Monday, April 20, 2015, Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Sun, Apr 19, 2015 at 02:49:58PM -0400, Michael StJohns wrote:
> > >
> > > What I would love to see for TLS1.3 is NO TLS specific mechanisms being
> > > added to PKCS11.    That if we still sign the finished message, we use a
> > > true MAC function.  That if we derive keys, we use a bog standard KDF.
> > That
> > > we stomp on every TLS specific twist unless there is a specific security
> > > need to keep TLS secure.
> >
> > Not possible. There are features (e.g. extractor and resumption/unique
> > interaction) that can't be feasibly removed (or even deprecated) and which
> > need PRF'ing secret keys into public data.
> 
> I'm not quite sure how you've come to this conclusion.  The underlying
> function for a KDF is generally a MAC function which by definition produces
> public data.  It's only when bound into a KDF that it by definition
> produces secret data.  The main problem we've encountered is that we use
> the same key to produce public (IV) data and private key material.   Fixing
> this is more an issue of how to cryptographically isolate products of the
> diverse operations in a way that enhances security.

Maybe I used bad terminology, but...

There are other places in TLS that fundamentally need to (indirectly) derive
public data out of secret key material.

E.g. extractor and unique/resumption-interaction. There might be others as
well.


-Ilari