W3C home > Mailing lists > Public > public-web-security@w3.org > February 2015

Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 2 Feb 2015 12:32:39 -0800
Message-ID: <CACvaWvZqWk4w0mHc0pztj9oDULji6gV3XDYcR77LVc+Ru7V7eA@mail.gmail.com>
To: POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>
Cc: Wendy Seltzer <wseltzer@w3.org>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Harry Halpin <hhalpin@w3.org>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>, "public-web-security@w3.org" <public-web-security@w3.org>, Brad Hill <hillbrad@fb.com>
On Mon, Feb 2, 2015 at 5:28 AM, POTONNIEE Olivier <
Olivier.Potonniee@gemalto.com> wrote:

>  Ryan,
>
>
>
> What I’m saying is: WebRTC and geolocation API give access to personal
> information (your voice, or your position). Any origin may request access
> to these services, and the access control to these services is not based on
> **same-origin policy** but on permissions. Your same voice, and
> potentially your same position, may be shared with multiple origins. Both
> can be used to track you.
>
> Of course the access control mechanism to a service has to be adapted to
> the level of privacy/risk associated to the disclosed information.  And I’m
> not saying the existing one is not adapted to WebRTC and geolocation API.
>
> What we are willing to define in W3C is a hardware backed-up crypto
> service protected with an access control matching the sensitive nature of
> secure hardware tokens.
>
> --
>
> Olivier
>
>
>

Oliver,

The comparison here is about as apples and oranges as you can get.

First, let's be clear: The access control to these services IS based on the
same origin policy. It is ALSO based on permissions. It is not "either/or",
but "and", and that is a critical distinction to note and realize. Granting
permission to Origin A access to any of your capabilities does not and
should not grant access to Origin B. That's (part of) what we mean by the
same origin policy - only the SAME ORIGIN that was originally granted
access to something continues to have access to it.

Second, I think it's important to realize how flawed proposals are that
rely on sharing access to the same device across multiple origins when that
device has a level of persistence. That fundamentally violates many of the
key security guarantees of the web, in that now Origin A and Origin B can
independently influence eachother, collaborate, or otherwise be granted
transient and ambient permissions.

For example, when I grant Origin A access to my microphone, Origin B has no
ability to influence that access whatsoever. It does not receive access, it
can not influence how my voice is presented, nor can it simulate my voice
to Origin A. Similarly, when I grant geolocation to Origin A, the
capabilities granted to it have no ability to influence how Origin B
behaves.

Now, consider what's being proposed here by the hardware vendors on the
list trying to ensure an insecure technology stays relevant in a web world
where security is no longer optional: If I grant Origin A access to key
material, it can impersonate messages from Origin B (if Origin B also has
access). Similarly, if Origin A creates a key, Origin B can discover this
key. Both of these fundamentally violate the origin separation that is
crucial to the web.

This is where the relevance to FIDO is all the more important - even though
a single hardware token may be involved:
- Origin A and Origin B have NO shared key store
- Messages from Origin A are identified as such explicitly as part of the
message construction, preventing it from being compared with Origin B
- Persistent identifiers are (effectively) opaque, and thus user agents can
provide a number of privacy enhancing means on this

I hope you realize how geolocation/microphone permission models are thus
apples & oranges to what has been proposed by Gemalto and Typhone, and
similarly how FIDO and the legacy APDU-based smartcards are, similarly,
night and day.

ANY solution that attempts to expose these capabilities MUST have, as a
first class citizen and intrinsic to the design, a model that recognizes
origins as the basis for all security decisions. Keys MUST NOT be shared
between origins AND messages MUST be attributable to origins are two basic
requirements that are needed for any serious consideration.
Received on Monday, 2 February 2015 20:41:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 February 2015 20:41:15 UTC