Re: Same Origin Policy - Re: Agenda: <keygen> being destroyed when we need it

On 12 September 2015 at 19:54, Alex Russell <slightlyoff@google.com> wrote:

> On 12 Sep 2015 3:19 am, "Henry Story" <henry.story@co-operating.systems>
> wrote:
> >
> > Thanks Alex for your very good summary.  I don't want to go over the
> good points made by
> > Melvin and Anders, but to hightlight this part of your mail:
> >
> > > On 12 Sep 2015, at 02:20, Alex Russell <slightlyoff@google.com> wrote:
> > > [snip]
> > > Developers who want to persistent keys to the local system should
> acknowledge that this is an operation that lives outside the Same Origin
> Model. The inability to scope the use of keys added via <keygen> (via
> addition to the effective keychain) creates a major hole in our one
> workable security primitive. It's true that this isn't part of the <keygen>
> spec, but compatibility requirements have caused this to be true in
> practice. From an architectural perspective, this alone should be enough to
> cause the TAG to recommend removal of <keygen> and replacement with a
> better, origin-scoped alternative.
> > > [snip]
> >
> > I think this is the core of the discussion. It is this blind application
> of SOP here that I and others wish to question.
>
> I'm glad we're discussing this.
>
> You might know that the TAG recently wrote a Finding on Unsanctioned
> Tracking: http://www.w3.org/2001/tag/doc/unsanctioned-tracking/
>
> It's relevant here because storage and identification mechanisms that let
> sites persist data outside of effective user control -- and in particular
> those that work across origins -- are ripe for use as "supercookies".
>
> Consistent application of the SOP is what enables positive user control.
> User action at key installation time can similarly be thought of as
> consent. The status quo is suspect on both points.
>
> > It is quite clear to me that if this principle were not thought to be
> untouchable then people would long ago have found an answer to all the
> other problems you and others have mentioned. The Browser vendor Engineers
> would have
> >  - found a way to improve or replace spkac,
> >  - a debate about how to extend the <keygen> tag so that it could enable
> a better UI, and many other features required would have lead to fruitful
> results
> >  - taken the opportunity to work with the IETF on better certificate
> formats such as JOSE or supported work on non syntactic bound certificate
> formats by reading up on research done on the semantic web side of things
> >  - people would have even found ways of taking a leaf from FIDO and find
> a language to limit certificate usage to certain range of applications
> >  - there would have been enthusiastic support for improving the user
> interface of browsers to integrate WebID and make the experience extreemly
> user friendly and social network aware
> >  - ....
> >
> > But of course if you believe that a certificate should only be used for
> the origin from which you got it, then it makes no sense to continue with
> <keygen> which allows you to generate a certificate (X509 at present) whose
> whole purpose is to safely allow you to use it cross origin ( which is why
> it is used for server authentication in TLS ).
> >    So client-certificates-usable-across-origin is really what people
> think SOP argues against. And so from that perspective the anti SOP,
> anti-linkeability commitments of FIDO [1] makes perfect sense.
> >
> > But SOP is not a foundational principle of the web, which is primarily
> about linkeability historically and conceptually. SOP is essentially a
> JavaScript (JS) limitation introduced because JS introduced agentood into a
> declarative web. In addition to the agenthood of the User Agent and the
> User, JS introduced the agenthood of JS fetched from the web. This follows
> from JS being a procedural/functional language that can act in the browser
> environment by clicking links, downloading information, POSTing forms, ...
> SOP is one way of identifying JS agency, and then limiting it.
>
> This is less than half the story. All manner of buggery is possible via
> purely declarative forms. The browser enforces SOP in those cases as well.
> It may have seemed easier to reason about interactions between actors with
> only declarative systems in play, but we continue to be astonished at some
> of the things forms + images + CSS + iframes can do.
>
> JS made it clearer, faster, but browsers would be still separating actors
> with SOP regardless.
>
> But that's all indulgent thinking. JavaScript is a core part of the web
> stack today. We live in a world where it exists. We cannot pretend it
> doesn't.
>
> > Note: It is not a particularly good way of identifying JS agency, as it
> is way too broad. Signed JS attributing it to an author or organisation
> would be a lot better. ( requiring therefore a certificate ).
>
> That misreads the JS capability model in a very concerning way. Signing
> might let you know who sent you the code, but once you execute code from
> multiple actors inside the same heap, and in such a dynamic language, they
> have unfettered acccess to any capability the container will grant any
> participant. This is why SOP is important at runtime: unlike signing, it
> gives us a workable actor partition (via Workers and iframes) that maps
> cleanly onto the web's process & proviledge model.
>
> > SOP applies to cookies. But the user is never asked by the chrome
> whether or not a cookie should be set. Cookies are SOP by design.
> >
> > So Why is SOP important for certificate usage? It is clear that any
> privacy enabled browser should
> >
> > a. on being asked for a certificate by a web site first ask the user
> which certificate to choose
>
> At TLS connection time? Modern site make tens and sometimes hundreds of
> distinct connections per page.
>
> > b. show the user which certificate he is actually using during a session
> at a site
>
> With which actor? The primary document? An iframe?
>
> > c. enable a mode where the user is not using that certificate ( Chrome
> has the Persona UI for example ) [2]
>
> This is key scoping. SOP is just another form of scoping.
>
Very well put.  SOP is a form of scoping.  The question arises as to which
aspects of the browser should belong to a single origin and which should be
cross origin.  We have a few examples of each living today, perhaps it's
worth documenting a list of each.  e.g.

same origin (localstorage, webcrypto, indexeddb, cookies)
cross origin* (location, plugins, bookmarks, user, images)

* mainly for illustrative purposes, not sure all of these are fully cross
origin, happy to be corrected

> What I'd like to understand from you is why:
>
> - removing <keygen> as currently shipped hurts anything
>

removing keygen disables ability to create a cross origin private key that
can be used as the basis of an X.509 identity to authentiate

> - why the Web Crypto solution isn't strictly better
>
Web Crypto is potentially better in a lot of ways, but does not (yet) store
the key in the x.509 keystore or the equivalent.


> - what you imagine your ideal key provision solution to look like.
>
Instead of users having a (hopefully different) password for every site.
It would be good if they could benefit from PKI by keeping the private key
in their browser, and making the public key public, and tied to an online
account (ie name/avatar/url).

This would enable secure passwordless sign in across the web using the
secret in your browser, which in this case, would be an RSA private key.

What would it look like visually?  Best suggest I have seen to date was
from mozilla labs:

http://www.azarask.in/blog/post/identity-in-the-browser-firefox/


> These can be stylized versions, but need to include detail sufficient to
> let us discriminate, e.g. main document from iframe.
>
> > At all these stages the chrome is giving the user control of decisions.
> There is no JS agency that can take this over. Exactly for this reason SOP
> does not apply, and it is exactly for this reason that chrome integration
> of identity is so important.
> >
> > This is my analysis. Where am I wrong about the non-application of SOP?
> What Web Architectural Principles do you rely on to justify the application
> to this case of certificate generation and useage.
> >
> > Sincerely,
> >
> > Henry Story
> >
> >
> > [1] see my previous mail "(un)linkability - Re: Agenda: <keygen> being
> destroyed when we need it" for references
> >    https://lists.w3.org/Archives/Public/www-tag/2015Sep/0023.html
> > [2] I realise now that  logout does not actually make sense because one
> a user has authenticated a cookie can be set to track him, or information
> kept in URLs. This should be explained somewhere.
> >
> >
>