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

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.

What I'd like to understand from you is why:

- removing <keygen> as currently shipped hurts anything
- why the Web Crypto solution isn't strictly better
- what you imagine your ideal key provision solution to look like.

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