Re: Propigation of non exportability in DH

I think I'm with Ryan on this.  KDFs are designed such that it's hard to go
from the derived product to the input key, so you're not violating the
non-extractability of the original key by creating an extractable key from
it.  And with the current API, the JS can specify that the derived key be
non-extractable anyway.

--Richard


On Sat, Mar 1, 2014 at 9:27 PM, Ryan Sleevi <sleevi@google.com> wrote:

> -1
> On Mar 1, 2014 1:10 PM, "Jim Schaad" <ietf@augustcellars.com> wrote:
>
>> Since Ryan and I have not been able to come to agreement on the topic of
>> how to do secret agreement and key/bits derivation in the API, I thought
>> that I would toss in a new topic that we can probably fail to come to
>> agreement on as well.
>>
>>
>>
>> What are the requirements of propagation of non-exportability on the
>> deriveKey, deriveBits functions?
>>
>>
>>
>> If I assume that I start with a JWK encrypted by an RSA key that is
>> tagged as non-exportable. I can get from a non-exportable RSA key to a
>> non-exportable AES key in one step without any requirements on the function
>> implementations that the non-exportability bit be propagated from the RSA
>> key to the AES key.  One might wish to do this if one wishes to support the
>> same functionality for a raw AES key wrapped in RSA however.  This may or
>> may not be sufficient for the Netflix use case.
>>
>>
>>
>> There is a problem however if I want to do the same thing using a DH key
>> that is tagged as non-exportable.  Specifically if the non-exportability is
>> not propagated forward into the shared secret and then into the key
>> agreement key, there is nothing to stop the final AES key (wrapped in JWK
>> and tagged as non-exportable) from being unwrapped by the application using
>> one of the two intermediate values and performing its own decryption of the
>> JWK object.
>>
>>
>>
>> Therefore I would like to see non-exportability be propagated forward by
>> the secretAgreemnt and KDF functionality   The same issues will exist for
>> the ECDH and RSA-KEM functionality.
>>
>>
>>
>> The flip side of the argument is that this would basically totally
>> destroy the usability of the deriveBits function if one starts from a
>> non-exportable key.  It might be possible to loosen the requirements on,
>> for example, the second KDF function that was created.  However, since it
>> would be impossible to prevent the first KDF function to not generate the
>> key from the deriveBits function, I don't know how one goes about
>> protecting this except to be extremely draconian.
>>
>>
>>
>> One argument in my favor would be how TLS approaches the problem.  They
>> do keep the pre-master-secret a secret, as is the master-secret.  If one
>> wishes to get bits (such as channel binding data) this is all derived from
>> the master-secret not the pre-master-secret.  Thus the ability to do a
>> deriveBits is two steps removed from the ZZ value.
>>
>>
>>
>> Jim
>>
>>
>>
>