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

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

On Thu, Sep 17, 2015 at 5:48 PM, Colin Gallagher <
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> 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
>>   • Manu Sporny's more fully fleshed out HTTP Message signature
>>      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
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>