Re: Wrap/Unwrap with DH

On Thu, Jul 18, 2013 at 3:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>>
>> I seem to be believing that we've discussed this before.
>>
>> Virally propagating extractability unconditionally isn't desirable - you
> may wish
>> to use a non-extractable key to derive an extractable key.
>
> Do you have a use case where this is true?  I seem to be unable to think of
> one easily.

Sure, if software is polyfilling an algorithm implementation that the
UA doesn't support, using a key agreement scheme that the UA does
support.

>
>>
>> However, I do agree that this also highlights why treating extractability
> as a
>> property delivered via JWK, as proposed by Netflix, rather than associated
>> with/through some aspect of the API, is an undesirable solution limited to
> a
>> very specific use case, rather than being of general use.
>
> I think that a large part of this might have to do with the fact that this
> API is not keeping a strong distinction between keys and data.  There is a
> large part of the security world that believes that one should not be able
> to mix keys and data when doing processing.  This means that they believe
> that an encryption algorithm should be able to only process data or only
> process keys.  In this world the use of a JWK to deliver a key is normally
> thought of as being data.

It's hard to respond to "them", but I do not believe this is an
accurate summation of the API designs found in any number of
cryptographic libraries or standards.

>
> In this world view an algorithm would have at most one of encrypt and
> wrapKey set.

Similar to above, this world view is certainly not reflected in the
underlying libraries used by the majority of end-user UAs today.

> This means that one would need to name two different
> algorithms if one wished to have AES-GCM encrypt both keys and data.  (Note
> that this is the approach that is being taken by the JOSE working group.)
> If one does then then propagation of the extractable attribute is trivial as
> one always propagates it when doing a key unwrap and it cannot be propagated
> when decrypting the data.

Similarly, no API I'm aware of implements what you describe. Nor has
this been a cause of great heartache and pain.

>
> One still might have a question of how far one carries it for derivations,
> the first one would be non-extractable but subsequent derivations might be
> extractable.  It might also matter what method of derivation one provided as
> well.
>
> Jim

This is yet another instance of the provisioning problem that, since
the chartering of the WG, I have highlighted as a known pain point and
full of trouble.

The answer taken by every API I'm aware of has been "Do
provisioning/derivation/configuration with someone you trust to
configure the initial parameters"

This only becomes a problem when you do not trust the user or the JS -
an unfortunate use case insisted upon by some members - which are
problems we cannot wave our magic cryptography stick to solve.

I'm somewhat biased in the DH case, because it doesn't give you any
identity assurances. If you don't trust the JS execution environment,
then hostile JS can always just replace the peer's DH key on the fly
and perform DH-in-the-middle for the key wrap/unwrap - JWK or not.

But I'm especially against
1) Algorithm-specific propagation rules re: extractability (eg:
DH/ECDH should not be special cased)
2) Always-viral propagation of extractability

Always-viral propagation will explicitly close off use cases and
future flexibility. *Never* propagating extractability, at least at
first, at least leaves a path for the future to define how
extractability is handled in a way that meets all use cases. I'm
extremely hesitant to burn API bridges to meet a single use case,
especially on an artificial timeline.

Received on Thursday, 18 July 2013 22:42:25 UTC