Re: ACTION-22: Key export

On Sun, Aug 26, 2012 at 1:06 AM, Mitch Zollinger <mzollinger@netflix.com> wrote:
> Ryan,
>
> First off, thank you. Things are beginning to make more sense because of
> your detailed response. More inline below...
>
>
> On 8/25/12 1:10 PM, Ryan Sleevi wrote:
>>
<snip>
>> // Handles completion of Phase 2 of DH agreement
>> function onDHDeriveKeyComplete(keyDeriver) {
>>    // zz is the result of the Phase 2 of PKCS #3 and is equivalent to ZZ
>>    // as documented in X9.42 - aka the shared secret
>>    // ZZ = g ^ (xb * xa) mod p
>>    var zz = keyDeriver.result;
>
>
> Is zz the actual shared secret, or is it an opaque handle at this point?

For sake of discussion, let's say an opaque Key handle. That is, I
imagine where there are cases where it might be more useful to be able
to combine the (derive+export as opaque bytes) into a single step, at
which point you'd want zz to be an ArrayBuffer, but for the sake of
the example & discussion, I think using a Key object here is fine.

<snip>
>> Am I also understanding that
>> this is being proposed as an OPTIONAL / MAY (not even a normative RFC
>> SHOULD) - eg: not all user agents need to support
>> ProtectedKeyExchange?
>
>
> I don't want to add the ProtectedKeyExchange if we can meet the intended
> goals of a multi-step key exchange / derivation where no keying material
> created during the different phases is visible to the script code at any
> time.

To make sure I'm on the same page - we're talking about ensuring that
the "Core API" (eg: excluding specific algorithm definitions) makes no
normative requirements on what the output of operations MUST be,
right? That is, to ensure the spec DOES NOT say that every output MUST
be an ArrayBuffer for this type of operation (for example)

If so, I'd agree, that's a reasonable concern, and I would want to
ensure that whatever is normatively specified is the bare minimum of
algorithm-independent functionality, and to leave the majority of
normative behaviours to individual algorithms. The "Core API"'s
normative behaviours should focus on state machines and error
handling, while the algorithms themselves should define inputs &
outputs.

Is that a reasonable understanding of the concerns?

<snip>
>>
>> So, there's two meanings of protected key exchange here
>> - Protected from content script, but the content script is allowed to
>> 'drive' the operation. I think this need is already met (as
>> demonstrated by the pseudo-code)
>
>
> This is what we're aiming for.
>
>
>> - Protected from the user agent (as in, secure element provisioning),
>> which I think is, at best, secondary features, but more likely out of
>> scope in general.
>
>
> I get this point. It's still somewhat unclear where this goal is
> incompatible with the "protected from content script" goal given that the
> underlying implementation could call out to a HW element. But that's more of
> a curiosity question.

What I mean is whether the spec should normatively mandate or claim
any protection from user agents.

I want to ensure that the spec doesn't *mandate* a secure element in
order to implement the normative criteria. If the definition of
'protected' means you distrust the user agent, then no user agent that
trusts or protects users can ever actually implement this, short of
outsourcing the crypto.

My view is that a conforming user agent should be able to implement
this in terms of storing the secrets in plain text in stable storage,
even when a key has been flagged 'protected' (meaning: protected from
/future/ content script). That you /can/ implement more protection -
eg: by using a secure element - is great, but by no means is it
mandated in the API that you MUST do so.

Make sense?

<snip>

>> In which case, your application would/should never request the
>> 'exportable' flag, and your problem should be solved.
>
>
> I believe this is one of the key points that I would like to make certain we
> agree on. Would I be correct in taking the above comment and expanding it in
> more detail:
> * Our application would never request "exportable = true".
> * If our application ever did request "exportable = true" the underlying
> implementation would throw an error.
> * Every phase in our key exchange + session key derivation, including the
> final stage, would have a result which was an opaque handle to the
> underlying key data, inaccessible to the script code.
>
> ?

re: throwing an error: Yes, I think that's the intent, but that means
normative text should be added to the appropriate places to clarify
the handling of unsupported parameters/algorithms/modes and raising
the right exceptions. But yes, I think that's correct.

re: every phase: I think that behaviour is going to be dictated by how
the algorithms are defined (what their inputs are, what their outputs
are). I think for the algorithms documented by this WG/endorsed by the
W3C, we'll want to reach consensus on what the right form of each
output should be. Should it be data, a single Key, multiple Keys, etc.
If an implementation does do something vendor-specific, then it's up
to that implementation to describe the outputs and their behaviour.

Received on Monday, 27 August 2012 17:43:49 UTC