Re: [TLS] HSM-friendly Key Computation

["StJohns, Michael" <[e-mail]>]

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.
>
> Also, true MAC functions just aren't enough for some places (such as
> deriving the various master secrets or unique value).
>
>
>

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.

Replacing the current functions with off the shelf ones along with a few
tweaks to the key derivation mixins and key tree can be done without
removing any functionality.

Mike

>
> -Ilari
>