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

Sent from my iPhone

On Apr 29, 2013, at 5:24 PM, Ryan Sleevi <> wrote:

> On Sat, Apr 27, 2013 at 6:40 AM, Mark Watson <> wrote:
>> On Fri, Apr 26, 2013 at 6:01 PM, Ryan Sleevi <> 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

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.

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

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

Let's discuss it on the call.


Received on Monday, 6 May 2013 15:47:14 UTC