Re: ACTION-22: Key export

On 8/28/12 2:43 AM, Ryan Sleevi wrote:
> 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)

Yes. Having the output be a "Key" or some other object which is a handle 
to the key data -- whether that key data is exportable or not being 
dependent on algorithm and/or implementation -- is the point.

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

That feels like the right approach. Even though the "Netflix proprietary 
DH + KDC" can use a "standard algorithms" we would specify our flavor of 
the algorithm (in essence a particular implementation of the algorithm) 
with a different "algorithm name".

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

That's one way to do it. The other way I mention above is that the 
"exportable" aspect of the output is a function of the algorithm and/or 
how it was invoked. That certainly makes things easier where the output 
type is consistent & the "exportable" setting does not need to be.

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

Agree completely. Like you, we're concerned about getting the APIs right 
first and foremost, and dealing with securing the implementations as 
needed; the API does not need to be "polluted" with the implementation 
details in this case.

Mitch

> <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 Tuesday, 28 August 2012 07:01:47 UTC