Re: A Somewhat Critical View of SOP (Same Origin Policy)

On 15 Sep 2015 6:19 pm, "Henry Story" <henry.story@co-operating.systems>
wrote:
>
>
> > On 15 Sep 2015, at 22:48, Alex Russell <slightlyoff@google.com> wrote:
> >
> >
> > On 15 Sep 2015 5:29 pm, "Henry Story" <henry.story@co-operating.systems>
wrote:
> > >[snip]
> > >
> > > ( They could have also have added WebID to the mix http://webid.info/
> > > but that is anoyingly simple, which is why I like it :-)
> > >
> > > Now WebID is not tied logically to TLS [1]. We have some interesting
> > > prototypes that show how WebID could work with pure HTTP.
> > >   • Andrei Sambra's first sketch with
> > >       https://github.com/solid/solid-spec#webid-rsa
> > >   • Manu Sporny's more fully fleshed out HTTP Message signature
> > >       https://tools.ietf.org/html/draft-cavage-http-signatures-04
> > > these two could be improved and merged.
> > >
> > > This would allow a move to use strong identity in  HTTP/2.0 ( SPDY ) ,
> > which could then be supported by the browsers who could build User
> > Interfaces that give the users control of their identity with user
> > interfaces described by your Credentials Management document developed
here
> > >
https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection
> > >
> > > Funnily enough one should already be able to try Andrei or Manu's
> > protocol in the Browser with JS, WebCrypto, and ServiceWorkers [2].
> > There are many things to explore here [3] and the technology is still
> > very new. [4]
> > >
> > > But this shows that WebCrypto actually allows one to do authentication
> > > across origins. ( And how could it not, since it is a set of  low
> > > level crypto primitives? ). A Single Page application from one site
> > > can publish a public key and authenticate to any other site with that
key.
> > >
> > > So its a bit weird that SOP is invoked to remove functionality that
> > > puts the user in control in the browser,
> >
> > This assessment is patently false. What's being proposed for removal
> > is silent, automatic installation of keys without user consent. To
> > treat that as removal of user control is perverse bordering on
prevarication.
>
> We have 5 years of experience using keygen, and that is our experience of
it
> on all the browsers for certificate creation and selection.
>
> A certificate creation
>
> The <keygen> is an html element that is placed in a form and adds
> a menu item allowing the user to choose key strenght. The user has
> to
>   1) click the form in order for the browser's keystore to create
>    a public/private key pair, and send the public key with the rest
>    of the form elements to the server.

Form submission can be scripted.

> Here the user is in control.
>   2) when the server receives the public key it can create a certificate
>    and send that back to the browser with the mime type
application/x-x509-user-cert
>    as you can see in the code here
>
https://github.com/read-write-web/rww-play/blob/dev/app/controllers/ClientCertificateApp.scala#L236
>    3) the user agent on receiving that certificate checks that the public
>   key of the certificate has a corresponding private key in its keystore.
>   If it has it can ask the user to add it to the keystore. Firefox did
that.
>   Chrome just alerts the user. If Chrome whishes to give the user more
choice
>   it could do the same too.

A stronger form of this is to simply remove x509 mimetype handling and
allow users to place keys in stores manually. This you object to for
reasons that are unclear but can't reasonably be down to user chouce.

>   The user chooses to submit the form, and the user can UI depending,
choose
> to add it. Where is the user not put in control?
>
> B. Certificate selection
>
>    When a site asks the user for a certificte using TLS's simple mechanism
> for that, the browser pops up a certificate selection box to do this. The
> user can choose to select one or not to send any. ( Not all browsers are
as
> good at this as Chrome or IE is, but I don't want to name names here )
> Where is the user not in control?
>
>   This is not unlike Basic Auth. And it is not unlike what is proposed
> in the credential management document
>
https://w3c.github.io/webappsec/specs/credentialmanagement/#user-mediated-selection
>
> I don't see how it can be provocative to point out the facts here.
>
> >
> > > and that WebCrypto is then touted simultaneously as the answer,
> > > when in fact WebCrypto allows Single Page Applications (SPA) to do
> > > authenticate across Origins, and do what the browser will no longer
> > > be able to do.
> > > Lets make sure the browser can also have an identity. It's an
> > > application after all!
> > >
> > > Let's stop using SOP as a way to shut down intelligent conversation.
> > > Let's think about user control as the aim.
> > >
> > > Henry
> > >
> > >
> > > [1] as it may seem from the TLS-spec which we developed first because
it actually worked.
> > > http://www.w3.org/2005/Incubator/webid/spec/
> > > [2]
http://www.html5rocks.com/en/tutorials/service-worker/introduction/
> > > [3] https://lists.w3.org/Archives/Public/www-tag/2015Sep/0051.html
> > > [4] which is why it is wrong to remove 15 year old <keygen>
technology on which a lot of people depend
> > > around the world as explained so well by Dirk Willem Van Gulik on the
blink thread before a
> > > successor is actually verified to be working.
> > >  See Dirk's messages here:
> > >
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/GnxmmtxSAgAJ
> > >
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/4kKNMVCdAgAJ
>