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

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.

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

Received on Tuesday, 30 April 2013 00:25:09 UTC