Re: Propigation of non exportability in DH

-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
>
>
>