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

> On 18 Sep 2015, at 02:56, Alex Russell <slightlyoff@google.com> wrote:
> 
> I'm not sure I'm the right party to try to summarize, but here's what I think are the roots of various discussion points that have been raised:
> Some browsers have an allergy to PKCS#11, largely down to the API not working well with the now-pervasive multi-process model
> The system keystore lives (conceptually) outside the Same Origin Model. This raises questions about how schemes (like TLS authentication) that use it can scope the effect of their actions
> Some people find these side-effects to be beneficial in cases they care about
> Others find it to be discomfiting and raise the point that users are not well equipped to reason about these more global effects
> <keygen> has a set of related behaviors, all of which have been flagged as having issues (many of which are peculiar to long-standing implementation choices):
> Persistence of a private key for a public/private keypair (sometimes without UI or consent)
> The SKPAC challenge mechanism
> The x509 cert mimetype handling behavior
> The overall system is poorly documented and specified
> The MD5 hash used in the <keygen> SKPAC challenge mechanism makes these challenges untrustworthy...
> ...which means that certain use-cases look like they can be safely accomplished but, in reality, cannot in a portable way
> FIDO is a more-scoped solution to some subset of the discussed use-cases
> WebCrypto, pending agreement in these threads on the threat models, can be used to bootstrap the <keygen>-like behavior
> Regards

Thanks Alex for this technical overview. The subject of keygen, MD5 hashes and TLS
authentication is complex due to the long history of those technologies, which nobody
- least of all me - would want to defend as being the best possible technology to use.
It happens to work in current browsers which is why I made use of it in the WebID TLS
protocol, in a minimal way, saving myself thereby the problem of having to invent much
new and having to deal with all the security issues that inevitably come up, relegating
that work to the TLS WG at the IETF, and hoping the rest would be taken care
of by the w3c and browser vendors.

Looking forward though, I think what many of us would be interesting to know,
is how you stand in relation to SOP as applied to WebCrypto. As I showed in
somewhat tedious detail in my post on the 16th Sept [1],  WebCrypto
allows one to use keys generated at one origin across differernt origins for
authentication, and potentially for signing . Is this a problem?

• If it is, does this mean that WebCrypto is going to be removed from browsers?
Or that all kinds of restrictions need to be added to it? After all it is not as clearly
single origin as FIDO is. 
• If not, do you then agree that SOP is a principle that must be used in a more
nuanced manner? What criteria can we use to decide when SOP should be
used and when it should not be used? For example: one possible way of moving
in this direction would be to say that where SOP does not apply, user control must
be guaranteed in another way.

Working out such principles would help a lot if we are to be able to invest time
in using WebCrypto and other technologies that could go nicely with it such
as service workers. Otherwise our fear is that any time invested in this space
will be for wasted as at some future point the SOP argument may re-emerge
to block various potential usages. This would leave us as 
only choice to move all code out of the browser and onto the server, where
we have all the freedom to be as innovative as we can.

Henry Story


[1] https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html <https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0101.html> 


> 
> On Thu, Sep 17, 2015 at 5:48 PM, Colin Gallagher <colingallagher.rpcv@gmail.com <mailto:colingallagher.rpcv@gmail.com>> wrote:
> Hmm.
> 
> I have been watching this thread from afar, and I have a request,
> 
> Without use of terms such as "doomed standards" or "impossible to implement" or "what (browsers) won't use/implement," and also while avoiding negatory or accusatory language, could someone craft and post at least several bullet points that sum up what you gained from reading this thread, and the direction you think you should go based on what you've learned from it?
> 
> On Sep 17, 2015 12:09 PM, "Henry Story" <henry.story@co-operating.systems> wrote:
> 
> > On 17 Sep 2015, at 14:51, Brad Hill <hillbrad@gmail.com <mailto:hillbrad@gmail.com>> wrote:
> >
> >
> > 3/ Is FIDO excluding all other authentication and security tools
> >
> > No. I believe there is a place for something else that is less dependent on
> > large origins for their trust relation... --Rigo
> >
> > Again, with respect, this fundamentally misunderstands what FIDO does.
> >
> > FIDO works directly between end users and the sites they visit.  There is no third party dependency, let alone any relationship to "large origins" AKA "super-providers".
> >
> > This is exactly the beauty of de-coupling strong authentication from Identity,  FIDO makes strong authentication instantly available to every web application at every scale, without having to establish *any* trust relationships with third parties.  The relationships between users and applications are unmediated.
> >
> > How you exchange Identity or AuthZ assertions is an independent problem.  Federation is one way (which happens to have a large installed base and history of successful deployment) but it's an orthogonal issue.  FIDO can work with this, but it can work as well with other technologies.  Whatever shortcomings you may think that federation systems as deployed today, they are not shortcomings of FIDO.
> >
> > You can even do an Identity-entangled authentication with a client certificate, and then re-authenticate with FIDO over that secure channel.
> >
> > FIDO is just strong authentication, sans identity.  So rather than trying to hang the sins (whatever they are) of Federated Identity around FIDO's neck, you might instead consider whether perhaps the fact that we've failed to deploy strong authentication successfully at scale for so many years has anything to do with the fact that so far we've always made it dependent on a grand vision of Identity.
> >
> > Maybe we can do better by solving one hard problem at a time and using composable solutions.  To me, being able to make independent choices about the method and strength of my authentication, and whether and how I share information about my identity, seems to be much more respectful of the principle of User Choice than any entangled solution can ever be.
> 
> I think Rigo was conflating a number of points which when seperated clearly I think you can actually agree with:
> 
> 1) that FIDO is a good answer to the password problem
> 
> 2) that FIDO is a good answer to establishing personhood, removing the need for captchas
> 
>   because the verificator comes with a cryptographic key, identifying the type of device, and the server knows that a some personhood verification was made.
> 
> 3) that FIDO does not exclude linkability solutions
> 
>    it states so in the architectural document that it works with OpenID, OAuth and other federation protocols. As such it does not exclude certificate based authentication such as that provided by TLS, e-id systems, or much simpler cryptographic protocols such as those I mentioned earlier that would be compatible with HTTP/2.0
> 
>   • Andrei Sambra's first sketch authentication protocol
>      https://github.com/solid/solid-spec#webid-rsa <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 <https://tools.ietf.org/html/draft-cavage-http-signatures-04>
> 
>  4) that FIDO does not solve all privacy problems
> 
>    for example not those that arise by having all information centralised on some huge servers. Eg. if in the Soviet Union the only computer system one were allowed to connect to were one owned by the party, and one were forced to do this with FIDO, one would nevertheless not say that people in this hypothetical Soviet Union using this system had any real privacy..
> I am invoking a very exagerated imaginary case just to make the point clear..
> 
> All the best,
> 
>    Henry
> 
> >
> > -Brad
> >
> >
> >
> >
> >
> >
> 
> 
>