Re: [TLS] HSM-friendly Key Computation

[Joseph Salowey <[e-mail]>]

On Thu, Apr 23, 2015 at 12:01 PM, Michael StJohns <[e-mail]>
wrote:

> On 4/23/2015 1:52 PM, Ilari Liusvaara wrote:
>
>> On Thu, Apr 23, 2015 at 01:34:53PM -0400, Michael StJohns wrote:
>>
>>> On 4/23/2015 4:42 AM, Ilari Liusvaara wrote:
>>>
>>>> On Wed, Apr 22, 2015 at 05:30:42PM -0400, Michael StJohns wrote:
>>>>
>>>> One possible structure in TLS notation:
>>>>
>>>> struct prf_output
>>>> {
>>>>       /*
>>>>       0x0000 => For key derivation
>>>>       0x0001 => For AEAD keying
>>>>       0x8002 => For AEAD IV
>>>>       0x8003 => For octet string (exporters, unique)
>>>>       */
>>>>       uint16 type;
>>>>       uint16 length;  /* In bytes. */
>>>> };
>>>>
>>> I ended up with a bit larger set of key types:
>>>
>>> Master Secret (can only be used with KDFs)
>>>
>> Right.
>>
>>  AES-CMAC
>>>
>> Not used anywhere (insufficient security).
>>
>
> For this and the comment below..... I'm not just thinking about TLS.  And
> I am thinking about how to retrofit this to TLS1.2 which doesn't require
> this to be an AEAD function.  And then there's the composed AEAD suites
> (e.g. AES-CBC with AES-CMAC wrapped as an AEAD function).   So while they
> may not be used by TLS directly, I want to get code points for all the
> possibilities.
>
>>
>>  AES-AEAD
>>>
>> Is there ment to be XXX-AEAD for different encryption algorithms?
>> Do AES-CCM and AES-GCM share a key type? What about AES-CCM8?
>>
>
> Generally yes for xxx-aead having different types per algorithm. Because
> you don't want to (for example) be able to use material for both AES and
> say GOST.   For modes, AEAD modes are mostly supersets or combinations of
> non-AEAD modes and there's an attempt to enforce "releasability only after
> verification" type policies on the CCM and GCM modes.   It would be good to
> have different codes for CCM and GCM (or even other modes), but I don't
> know that adds markedly to security.
>
>>
>>  AES-ENCRYPT
>>>
>> Not used. Encryption always pairs with authentication (AEAD).
>>
>
> See above - one of the questions is how does a composed AEAD suite derive
> subkeys.  Generically it seems to be "split the stream wherever you want"
> and as noted, that has a few problems.
>
>>
>>  HMAC-SHA1
>>>
>> A NULL cipher key? That one wouldn't be directly used for anything else.
>>
>
> For TLS1.2 and before, being able to tag that you're deriving an integrity
> key...  ditto for below.
>
>>
>>  HMAC-SHA2
>>>
>> NULL cipher keys are per algorithm?
>>
>>  GENERIC-DATA (different that PKCS11 generic secret - could be IV material
>>> for example).
>>>
>> This is "octet string" above (except IVs are "AEAD IV").
>>
>
> Not quite. (<begin pedantic mode>  :-) )
>
> One of the problems we have is a lack of common language.  And IV is one
> of those that's very slippery.
>
> TLS - incorrectly - called what's being produced by the master secret
> expansion an "IV".   What it actually was was the "first IV" of the session
> for cipher suites that included  CBC as a mode and a "session nonce" for
> suites with counter based ciphers.
>
> An IV is the common data injected by both sender and receiver to ensure
> that the same data doesn't encrypt the same way if identical data happens
> to occur in the plaintext stream multiple times.  For counter based
> ciphers, the IV is used with the block counter to form the block nonce(s)
> that (is/are) encrypted to form the XOR key stream.
>
> An counter-based IV  (e.g. for CTR, CCM and GCM) is generally composed of
> the concatenation of the session nonce (or as we've been discussing a fixed
> length of zeros) plus a per-message value (and we've been discussing always
> using the message sequence number as that per-message value).
>
> Due to the way TLS is constructed, what comes out of the master secret
> expansion can only be a "first IV" or a session nonce.  It would be
> possible to change this so an expansion is done with each message (e.g.
> same master secret, different mixins such as the sequence number) to
> generate a true per-message IV, but that's expensive and provides little
> security benefit.
>
> </pedantic mode>
>
>
>>  as a starting point.
>>>
>> Depending on view, you also need special type for exporter secret, since
>> it behaves somewhat unlike others.
>>
>
> I think the easiest way to accomplish this is to use a flag saying whether
> or not its exportable (generally removable from an HSM) that gets mixed
> in.  That way you have the common language of what you want to generate and
> then only have to decide on handling criteria.
>
>
[Joe] I've having trouble understanding what exactly you are designing
here, is it the interface to a specific HSM or is it the TLS 1.3 key
derivation or is it something else? I think we need to make sure that we
have the requirements defined for the TLS 1.3 key derivation.

Its not clear to me what the problem is with just including the context
label, session hash and possibly length.   The context label would
differentiate between derived key material for different purposes.  For
example, public and private data would use different context labels.  One
would also probably want to include the cipher suite ID in the context
label for keys derived for encryption.



>
>
>
>>  It turns out that you want to subdivide AES AEAD uses from non AEAD AES
>>> functions because you don't want to be able to use AES-CTR to get around
>>> the
>>> AES-CCM and GCM "don't let the data come out unless its been verified"
>>> policy.
>>>
>> As said, encryption always pairs with authentication.
>>
>>
>>
>> -Ilari
>>
>>
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>