Re: Serialized suborigins

Hmm..  I had suggested a cryptographic hash for the collision resistance
properties, to make it extremely difficult to craft suborigin strings that
allow "entering" a suborigin from a different top-level origin.  But if
reversibility is desirable, it's not necessary to use a one-way function to
obtain collision resistance.  Instead we could, e.g., define the
serialization as an AES-ECB encryption of the origin+suborigin strings with
a hard-coded key.

That way you could implement lookupSuborigin without needing a cache.  That
would be useful if the serialized value was passed between apps in Android,
and probably avoid fragility with things like bookmarks, installed/cached
webapps, etc.

Maybe it could even be as simple as ROT13 given the suborigin:// scheme,
but I want to think about that more...

Is the port intended to convey the difference between, e.g. http and https?
 I'm not sure that's adequate.  A network MITM could always fake an http
endpoint on 443.

-Brad


On Wed, Sep 11, 2013 at 4:21 PM, Joel Weinberger <jww@chromium.org> wrote:

> Hi everyone. In our earlier thread, it seemed to me that we were
> converging to an agreement that serialized suborigins are probably the best
> approach to make sure suborigins fail closed. Of course, what that
> serialization should look like is what really seems to be up in the air
> right now.
>
> After talking with Adam Barth, we both agree that Brad's hashing proposal
> has a lot of great advantages. Of course, as Michal pointed out, it also
> isn't particularly developer friendly. Here's a quick set of suggestions
> that Adam and worked out that I think eases some of the concerns.
>
> We propose that we represent serialized suborigins as follows:
> suborigin://HASH:PORT
> where the suborigin is a protocol literal, PORT is a standard origin
> port, and HASH is a hashed combination of the host name and suborigin
> string. Obviously, this is basically Brad's proposal, although we thought
> it was important to make sure to keep a protocol and port in the
> representation.
>
> Furthermore, we propose for a number of built-in functions to take care of
> suborigins for the developer. The goal is basically that a developer should
> never see (and certainly never write) a HASH value. The main API that
> comes to mind is:
>
> location.suborigin(name, [domain]) which returns a suborigin HASH value
> for the suborigin named by name. If no domain is specified, returns the
> value for the current domain, otherwise calculates it for the named domain.
>
> This way, a developer never has to see or calculate these in client. When
> checking one, it should be as simple as:
> if (e.origin == location.suborigin("foo", "some.domain")) {
>    ...
> }
>
> Of course, there are a variety of ways to go from here. Adam pointed out
> that this actually has the interesting property that if you receive a
> message from a suborigin, and the suborigin doesn't name itself, you can't
> know a priori who sent the message. We could consider this a "good thing,"
> but if we don't, we could always keep track of generated suborigin HASH
> values in browser and provide an API call
> location.lookupSuborigin(suborigin) which takes a suborigin value, looks
> it up in browser, and returns a (domain, suborigin_name) pair.
>
> In terms of the actual suborigin value, we define it as SHA256
>
> Like I said, I like Brad's suggestion a lot, so I tried to write up a
> slightly more formal version here. Thoughts?
> --Joel
>