Re: crypto-ISSUE-26 (multi-origin access): Should key generation be allowed to specify multi-origin shared access [Web Cryptography API]

On Wed, Aug 22, 2012 at 3:02 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Well, I think the original discussion started with x-domain key access. In
> general, I think that that is a good reason to have accessControl specified
> at the time of key creation. One use case I can think of is that of
> sister-sites (back-end synchronization for symmetric keys is an
> implementation problem).
>
> I am not sure that SOP (Same Origin Policy – thanks Ryan : ) ) is applicable
> when we have accessControl attribute values specified by the origin (key
> creator).
>
> I understand that the cookie model is constrained by SOP at the domain
> level, we can do the same (keep SOP), or do something else (break SOP, I
> guess). May be I am opening a can of worms here.
>

Right. If we're going to allow cross-domain access, I'd say that
breaks the same origin policy, and that's a dangerous proposition.

I think everyone with an opinion on this (positive or negative) should
make sure to read [1]. Additionally, for those not familiar with the
concerns and paranoia of the user agent vendors, [2] is solid reading
to understand the many security issues that have arisen related to the
same origin policy.

These concerns may not be immediately obvious, but other web platform
APIs have taken significant efforts to preserve the same origin policy
and security. For example, consider the <canvas> tag, which blocks raw
access to pixels for images that have been 'tainted' by cross-origin
resources, since such access may represent a way for security issues
to arise [3].

I think this API, being so explicitly security related, should
absolutely respect SOP.

[1] http://tools.ietf.org/html/rfc6454#section-3.4
[2] http://code.google.com/p/browsersec/wiki/Part2
[3] https://developer.mozilla.org/en-US/docs/CORS_Enabled_Image

>
>
> On 8/22/12 3:35 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> On Wed, Aug 22, 2012 at 2:32 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>
> Ryan
> I understand that the current spec is limited to origin-bound key set. I was
> just extrapolating wrt this issue (26). You are right, I think we need to
> spend good time munching this issue. However, I also think that this could
> be a powerful feature (again – like cookie domain/path).
>
> Thanks,
> Seetharama
>
>
> Just to make sure we're on the same page: cookie domain/path is not
> related to the SOP and is a different security model. It is still
> constrained by SOP.
>
> We're talking about breaking SOP. That's a big discussion.
>
>
> On 8/22/12 3:17 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> On Wed, Aug 22, 2012 at 2:07 PM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>
> Assuming that cross-domain usage of keys applies to only asymmetric keys
> (thus we have 'certificates' with attributes the user can inspect), I tend
> to agree with you.
>
>
> I'm not sure this is inherently true. See Netflix's case for (master)
> symmetric keys being used to derive (origin-specific) derived keys.
>
> However, putting the privacy hat on, its possible that users are not always
> wise-enough or attentive-enough to know what decision to make (another
> pop-up to click-through). It is possible that a corporate cert could be
> detected by other sites where they had no business of knowing.
>
>
> Agreed. Although you can already do this to some degree with TLS client
> auth...
>
>
> This brings me to another question – I am assuming that the application
> sifts through crypto.keys array to decide which key to use and which key to
> prompt the user with. Again, putting the privacy hat, that may be too late
> to prevent the application to know what all keys are there.
>
> Seetharama
>
>
> Note that, as currently spec'd, there is no inter-domain access going
> on. KeyStorage is the origin-bound key storage.
>
> So iterating through crypto.keys at present *only* returns keys that
> the system generated, imported, or (for implementations that support
> pre-provisioning) pre-provisioned.
>
> IF we decide to permit multi-origin access, then we'll need to decide
> how it should work. One proposal was the KeyQueryList way of key
> discovery, but that has problems mentioned on
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0161.html
>
> Just to be clear: We're not exposing the entire key store to any
> application to interrogate. As noted in the security considerations,
> exposing the platform key store is equally problematic and should only
> be done so with careful consideration and, likely, with a different
> security model. For example, for Chromium, I'm not sure we would
> expose system keys to web origins, but instead leave it for SysApps
> (W3C SysApps WG) or through our extension mechanisms. This is not a
> commitment either way, but just highlights the real security concerns
> we have for a feature that, to some degree, has been promoted by us. I
> just want to make sure that the messaging is clear.
>
>
>
> On 8/22/12 2:07 PM, "David Dahl" <ddahl@mozilla.com> wrote:
>
> I think at first the single-origin concept for this API was short-sighted as
> we will not have the ability to build decentralized, non-walled-garden
> applications.
>
> On the question of whether an approved-origin for a specific key can approve
> further origins: This operation is perhaps better and more securely handled
> by the browser implementation. I can imagine an implementation prompting the
> user for approval when an attempt to use a key is initiated x-domain for the
> first time, with the browser updating the key origin access list with
> "remember this choice" checked, etc...
>
> Cheers,
>
> David
>
> ----- Original Message -----
>
> From: "Web Cryptography Working Group Issue Tracker" <sysbot+tracker@w3.org>
> To: public-webcrypto@w3.org
> Sent: Wednesday, August 22, 2012 2:43:00 PM
> Subject: crypto-ISSUE-26 (multi-origin access): Should key generation be
> allowed to specify multi-origin shared
> access [Web Cryptography API]
> crypto-ISSUE-26 (multi-origin access): Should key generation be
> allowed to specify multi-origin shared access [Web Cryptography API]
> http://www.w3.org/2012/webcrypto/track/issues/26
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
> The charter defines as "out of scope" as "access-control mechanisms
> beyond the enforcement of the same-origin policy"
> However, it was initially proposed by David Dahl, that during key
> generation, an application may be permitted to specify alternative
> origins be allowed to access the same key material. For example, it
> might include a DOMString[] of authorized origins, for which, if the
> key is generated, they're permitted to access.
> Additionally, there's outstanding question as to whether an origin,
> with access to a key, may be able to grant access to other origins
> proactively.
>
>
>
>
>

Received on Wednesday, 22 August 2012 22:24:15 UTC