Propigation of non exportability in DH

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