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

> On 15 Sep 2015, at 23:40, Alex Russell <slightlyoff@google.com> wrote:
> 
> 
> 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.

Ryan Sleevi actually pointed to the docs substantiating this claim in the TAG Mailing list.
I accept that this is a problem, and that it breaks the intent of <keygen>

But if one applies the principle of user control this means one has 
to be much more creative on the User Interface front for this.
I went into details in the TAG response to Ryan
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0063.html

> > 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.

Unless this is tied to a good Browser/OS experience this will be dangerous and 
unuseable. (see my reply in the tag references above) 

Before I discovered <keygen> we were adding keys to Firefox using the 
puposefully  difficult to find certificate properties file. To get users to do 
this could be exceedingly difficult. Even if they did succeed it would increase
the likelyhood that they would mistakenly add Root Certificates to the keystore.
And even if they managed to place the keys in the right certificate slot the 
danger would be that they would add client certificates with private keys known
to other entities, which is very bad practice.

These are issues of Browser and OS design where ease of use is as important
as security of the crypto protocol. We can't say that the current situation is
great: it is a first step on which should have evolved a lot further over the
past years. 

Once one realises that client certifictes do not require a CA to be useable across origins
( and so the cost of certificates can fall down to $0.000 ) that they can be 
flexible by moving attributes out of the ASN1 into into web based linked Profile 
Documents, and so that the application can be huge, investment in developing the
UI makes a lot more sense.  I understand that without perceiving that, by thinking
of them as only useable by large organisations such as the military, the case
for good investment into user experience makes a lot less sense. 

This is where it would be good for those of you who have the occasion to do so
to talk a bit to Tim Berners Lee, his team or me about some of the possibilities 
that open up with linked data and cryptography. 

Henry

> 
> >   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
> >

Received on Wednesday, 16 September 2015 19:07:16 UTC