ISSUE-26 (was Re: origin bound key generation)

On Wed, Aug 22, 2012 at 1:06 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> Ryan
>
> Thanks for opening an issue related to this. We can use it to track the
> conversations.
>
> I think that depending on how restrictive or flexible (and regardless) our
> origin-bound policy is going to be, it is imaginable that applications may
> want a slightly different interpretation or result. Today, browsers allow
> the (server) applications to set this policy for cookies  and I think we
> can extend the same feature to keys.
>
> Seetharama

cookie.domain is still restricted by SOP. It only covers sub-domains.

You cannot cross-publish domains to other origins. That opens a host
of attack vectors, most notably session pinning.

As I also understand it, the cookie.domain process is not well
regarded as a good or desired API for future security decisions.

To be clear - we're talking about origins on the basis of RFC 6454 (
http://tools.ietf.org/html/rfc6454 ) , the "Web Origin Concept".

In particular, please see Sections 3.4.1 and 3.4.3 for why I think
this is a dangerous idea.

>
> On 8/22/12 11:25 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> On Wed, Aug 22, 2012 at 8:30 AM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>
>
>
> On 8/21/12 7:33 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
> I've been trying to find a way to propose text that balances these
> concerns, but to be honest, I don't have a good solution. Part of this
> is what lead to the proposal of requiring CSP, since this can mitigate
> (some of) the security concerns, but I think there's still a lot of
> security risks that have to be talked through and discussed before we
> go too far.
>
>
> Ryan,
> From my notes at the F2F, we had attributes of type scope (including access
> control and temporary/permanent). These were supposed to be set at the time
> of creation and read-only after that. Access control attribute was meant to
> allow the origin to specify which sites can access/use this key (may be we
> need granularity of purpose too).
>
>
> My notes on access control had it related to key usage.
>
> I have not been following the conversations much lately, but I do not see
> the access control attribute in the draft (temporary is there). Has it been
> dropped because of some reason?
>
>
> To the extent it's been discussed on the list, there seems to be
> opposition to granting multiple origins access to a key. See Mark and
> Mitch's responses about wanting to have keys that are only available
> to a single origin, and what I read as general opposition to
> permitting key sharing.
>
> While David mentioned it as a possibility, there hasn't really been
> discussion on
> 1) What use cases it has
> 2) What the security implications are
> 3) What the behaviour should be
>   3a) Can it only be specified at creation or is it mutable at some later
> point
>   3b) The behaviour of pre-provisioned keys
>
>
> The usage of Web Intents offers one way for origins to "share" keys,
> and without undermining the fundamental properties of the key (eg:
> allowing Origin-B to spoof messages from/to Origin-A).
>
> I think it's something still reasonable to discuss if the WG wants to,
> but we should open another ISSUE to capture the requirements and need.
>

Received on Wednesday, 22 August 2012 20:57:40 UTC