Re: ISSUE-35 - Wrap/Unwrap - Why JOSE?

On Mon, May 6, 2013 at 8:46 AM, Mark Watson <watsonm@netflix.com> wrote:
> Sent from my iPhone
>
> On Apr 29, 2013, at 5:24 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>> On Sat, Apr 27, 2013 at 6:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 26, 2013 at 6:01 PM, Ryan Sleevi <sleevi@google.com> wrote:
>> <snip>
>>>> Is this a good summary of our disagreement?
>>>
>>>
>>> Let's discuss on our next call, after I get back.
>>>
>>> I believe the above is roughly correct about the point of disagreement, but to fully understand your position I need to understand how the extractable flag fits into your view of the situation ? How is that valuable if there is no boundary at all between JS and UA for the purposes of this API ?
>>
>> Right, and this represents my general unease with 'extractable' at all
>> - in what situation DOES it make sense?
>>
>> It feels very meaningless today already, in the presence of structured
>> clone + inter-origin postMessage. In such a scenario, you don't even
>> have to worry about extractability - an XSS attacker can just clone
>> the object into their own attacker controlled origin, which they can
>> then use to potentially spoof messages from a UA.
>
> Ok, so I don't see how you draw a line between extractable and
> wrap/unwrap then. If one is meaningless, so is the other and vice
> versa.
>
> If the group agrees with your position, I think we must remove the
> extractable attribute.
>
>>
>>> I agree that there are situations where the UA/JS boundary is unimportant and situations where it is significant but I don't agree that the difference is tied fundamentally to the presence or absence of pre-provisioned keys. Of course pre-provisioned keys make a big difference, but from a practical security engineering standpoint the JS and the UA are different in all cases. They are subject to different attacks. They have different security properties. If we make a fundamental assumption that they are the same (for this API), we are pre-judging the security engineers who will actually use this API. That's not our job. Unless we have a mathematical reason to believe that there is no boundary of interest here the people who will decide whether it matters to their application are the engineers using the API.
>>>
>>> ...Mark
>>>
>>> PS: I didn't answer your other points above only because I am going on vacation. I'll get back to you on those.
>>
>> Naturally, I disagree with this :-)
>>
>> I think it's important to model our API after the existing separations
>> that exist in the web platform - that is, at the origin level. I
>> realize that for sysapps/"extensions", there may be a greater
>> opportunity to model boundaries, but I think any attempts to try to
>> treat the boundary between UA and JS executing is, in many ways,
>> doomed to failure. You'll recall this is one of the many criticisms
>> pointed out by the "web crypto haters" - and rightfully so, as
>> attempts to somehow redefine that boundary "securely", but in
>> isolation of this API alone, are exercises in hubris.
>>
>> Rather than discussing specific API proposals, I almost think this
>> should be an exercise for the WG to reach consensus by modelling
>> attack scenarios (ideally, those against use cases reflected in our
>> use cases document) and reaching consensus as to which attacks are and
>> are not in scope. If we're in agreement that attacks X, Y, and Z are
>> all in scope, and are unaddressed by the API, then we have a
>> reasonable point for discussions on mitigation - whether it be changes
>> in how structured clone behaves, in how export behaves, or in how
>> wrap/unwrap SHOULD work.
>>
>> This gets to the core of our disagreement - whether and how much XSS
>> (persistent or reflective) should be in scope for the threat model,
>> when they're already so far out of scope for every API today
>> (including those that require permissions - such as video,
>> geolocation, etc).
>>
>> If you'll notice, the position I'm arguing for is that, as far as
>> normative requirements go, we should provide the LEAST amount of
>> guarantees, unless it can be demonstrated that we need to provide
>> more. I interpret (and perhaps incorrectly) your response as
>> suggesting we should try to include MORE guarantees, because "why not"
>> or "someone might need them" - positions as an implementer that
>> naturally give me great pause, even when there is at least one use
>> case requesting them.
>
> No, I am not suggestion normative guarantees other than
> straightforward requirements on the functionality of the API: a key
> object with extractable = false cannot be used with 'exportKey' or
> 'wrapKey' methods (the API must throw an error if you try), a key
> object with usage 'encrypt' cannot be used with sign or verify etc.
>
> Perhaps, if we are paranoid, we should specify that UAs must not
> provide other JS APIs that circumvent these requirements.

You mean like the "Structured Clone"?

It's easy to put forward straightforward requirements like you have -
but if they aren't consistent with the threat they claim to be
preventing, what's their value?

It's a simple argument: If "extractable = false" is meant to prevent
key material from leaking past the origin/UA boundary, than having
"Structured Clone" for Key objects handily defeats that - an XSS to a
site can export the Key object via postMessage to an origin under the
attackers control, from which they've now elevated it into a
"persistent signing oracle".

If THAT is not your threat model, then please be clear about what is.

You can't simply say "The JS is outside the boundary," but then have
the entire API driven by the JS, without actually exploring what it is
you're trying to protect.

Is it the key material [as you have suggested]?
Is it the act of signing [as Mountie, Karen, and Nick have suggested]?
Is it something else, gated on some other capability?

>
> My point is that the security significance of the boundary between UA
> and JS - the boundary across which our API calls are made - is an
> application-specific security engineering question. Given a reasonable
> use-case, we can reasonably include support for features which are
> meaningful only when this boundary has some security significance
> (such as extractable and wrap/unwrap).
>
> You accept that given pre-provisioned keys the boundary is
> significant. There are other ways (outside the scope of this
> specification) that an application may gain some kind of confidence in
> the UA - to a greater or lesser extent. None of this is
> black-and-white, especially when the risk is low. For example,
> theft-of-service is something we care about at Netflix, but theft of a
> $7.99 service is not the same as forging of a $7.99M Internet banking
> transaction.
>
> You are free to argue that our use-case is unreasonable, though I am
> not sure to what extent it is the role of this group to subject
> use-cases to detailed security analysis. We know that this API can be
> used to build stuff that is not secure - we're not designing something
> that guarantees the security of all applications which use it - but of
> course we should not provide primitives that can never be secure. It
> sounds like this is your position on extractable/wrap/unwrap for all
> values of 'secure' absent pre-provisioned keys.  This is where we
> disagree.

We're in the security area - every use case MUST be subject to
detailed security analysis to figure out what exactly makes sense, and
what the threats are and what the guarantees are - especially when
designing a generic API that will be used by a variety of
applications.

Because of this generalization, it's vitally important to be very
clear about what guarantees are made, what the threats are, and what
the mitigations are. You seem to be arguing that this particular API
should do something to try to mitigate a particular set of threats.
It's entirely reasonable to question whether or not those mitigations
can or should be provided elsewhere / through other APIs, and to
question the validity of the threats in a holistic sense to see
whether or not it makes sense for them to be dealt with per-API.

We have a dedicated WG for dealing with these issues, so let's not put
the cart before the horse when designing the API.

To put it differently, much like the use cases presented at the F2F
for Korean Banking, I'm trying to distill what are the core
requirements of this particular use case, and where the web platform
falls short, so that we can look at actually addressing the root
needs, rather than provide a particular, implementation-specific API.

>
> Let's discuss it on the call.
>
> ...Mark

Received on Monday, 6 May 2013 16:47:26 UTC