Re: [TLS] HSM-friendly Key Computation

[Robert Relyea <[e-mail]>]

On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
> 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.
That's not a a problem. The problem is using the same mechanism to 
derive the public data that we use to derive the keys.
It's even OK to use the same secret key for both (from an HSM POV).

What Michael is saying is that there are existing functions for both KDF 
(secret material -> key) and Mac (secret material-> unique public data). 
He's requesting that TLS not have it's own versions of these functions.

So there are really 3 things being discussed here and there is some 
conflation:

1) The use of the same mechanism to create both secret and public data. 
This is the most serious issue because there is no work around for 
HSM's, today people with access to HSM's can use the existing mechanism 
for IV to leak actual keys protected by the HSM.
2) The use of a single mechanism to generate multiple keys (and IVs) in 
a single operation. This isn't HSM pain, it's more a PKCS #11 pain. I 
think this is more of a 'cleanliness' issue. PKCS #11  may still choose 
to provide a single mechanism for performance reasons.
3) The use of yet another KDF and MAC. The world has lots of KDF's and 
MAC's out there, we does TLS need another. I'm a bit ambivalent about 
this. In an ideal world we would all use the same KDFs rather than 
inventing a new one for each protocol. On the other hand TLS is a big 
enough fish I don't see a big issue having it's own. I'd rather someone 
propose exactly what other KDF TLS would use. Currently I don't support 
many KDF's myself, TLS being the main one.

For me 1) is the only show stopper, 2 and 3 are basically bike shedding 
(though I admit we are talking some pretty ugly bike sheds;).

bob
>
> E.g. extractor and unique/resumption-interaction. There might be others as
> well.
>
>
> -Ilari
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls