RE: Propigation of non exportability in DH

Implementation data point: in CNG ZZ is never exportable. You can only use it as a handle input to a KDF, which is a function interface similar to deriveBits.

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Sunday, March 2, 2014 4:48 AM
To: Ryan Sleevi
Cc: Jim Schaad; public-webcrypto@w3.org
Subject: 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<mailto:sleevi@google.com>> wrote:

-1
On Mar 1, 2014 1:10 PM, "Jim Schaad" <ietf@augustcellars.com<mailto: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