Re: [TLS] HSM-friendly Key Computation

[Hugo Krawczyk <[e-mail]>]

On Thu, Apr 23, 2015 at 4:07 PM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Thu, Apr 23, 2015 at 1:03 PM, Michael StJohns <[e-mail]>
> wrote:
>
>>  On 4/22/2015 7:03 PM, Eric Rescorla wrote:
>>
>>
>>
>> On Wed, Apr 22, 2015 at 5:30 PM, Michael StJohns <[e-mail]>
>> 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
>>>
>>>
>>  Sorry, read that as "HKD-Expand".
>>
>> Actually, use HKDF as the term with no expand or extract suffix.
>>
>
> I discussed this extensively with Hugo and Hoeteck and their advice was to
> use
> them separately in a similar way to what's here (though they suggested a
> slightly
> different hierarchy which I have to edit in). Perhaps Hugo will weigh in
> as to
> the reasoning.
>

​I've just addressed this issue in an email in the
"confirming the room’s consensus: adopt HKDF PRF for TLS 1.3" thread
(it's the first point in the list of issues in that email).

Hugo


> -Ekr
>
>
>> Mike
>>
>>
>>
>>
>>
>>  -Ekr
>>
>>
>>>  Basically, no.
>>>
>>> The Extract function is really not designed to be used standalone but as
>>> a way of concentrating entropy for input to the expansion phase.  Its
>>> dangerous to talk of these functions as separately callable.  They are
>>> steps not separate functions.
>>>
>>>  The extract step's only non-key input - salt - is not the same as the
>>> "info" input used in the expand phase - 'salt' is supposed to be missing or
>>> random,  not a fixed string like a label.
>>>
>>> "info" is where the various labels go and that's only present in the
>>> expand phase.
>>>
>>>
>>> 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.
>>>
>>> A software module will basically ignore these because - really - its all
>>> the same memory although it should really make sure the key lengths and
>>> types matc.  An HSM will look at these and be able to make policy decisions
>>> for protection of the segments (e.g. preventing export of material that was
>>> created to be non-exportable).
>>>
>>> Having all of these in the mixins means that the key stream expansion
>>> completely changes if ANY of these mixins change which in turn means  that
>>> the various ways you can use to extract truly secret key material (as
>>> differentiated from exportable material) from an HSM using the currently
>>> defined mechanism can be eliminated.  (I can explain my reasoning if
>>> necessary).
>>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>> On Wed, Apr 22, 2015 at 1:35 PM, Ilari Liusvaara <
>>> [e-mail]> wrote:
>>>
>>>> On Wed, Apr 22, 2015 at 10:02:50AM -0700, Robert Relyea wrote:
>>>> > On 04/20/2015 09:37 AM, Ilari Liusvaara wrote:
>>>> > >
>>>> > >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 would using two different PRF functions, one for parts that don't
>>>> downgrade and another for parts that do downgrade (e.g. IV derivation,
>>>> unique / finished calculations, exporter calculations, etc..) solve the
>>>> issue?
>>>>
>>>> (Of course, the two functions should be closely related, so not to
>>>> annoy software implementations too much)...
>>>>
>>>>
>>>> -Ilari
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing [e-mail]://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>