W3C home > Mailing lists > Public > public-web-security@w3.org > February 2015

Re: [W3C Web Crypto WG] Rechartering discussion - Gemalto contribution

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 2 Feb 2015 18:08:15 -0800
Message-ID: <CACvaWvbk3=MwFnjhXojpF5gRV1te4_7T+0Yq=tbhZzJhLjx7Jg@mail.gmail.com>
To: Sean Michael Wykes <sean.wykes@nascent.com.br>
Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, Siva Narendra <siva@tyfone.com>, Harry Halpin <hhalpin@w3.org>, Anders Rundgren <anders.rundgren.net@gmail.com>, Brad Hill <hillbrad@fb.com>, GALINDO Virginie <Virginie.Galindo@gemalto.com>, Lu HongQian Karen <karen.lu@gemalto.com>, Wendy Seltzer <wseltzer@w3.org>, "public-web-security@w3.org" <public-web-security@w3.org>, POTONNIEE Olivier <Olivier.Potonniee@gemalto.com>, "PHoyer@hidglobal.com" <PHoyer@hidglobal.com>
On Mon, Feb 2, 2015 at 5:32 PM, Sean Michael Wykes
<sean.wykes@nascent.com.br> wrote:
> Suggestion:
> We can start by mapping between smart-card “AppID"s (ISO7816-5 RID) and internet domains, such that a domain/origin can be identified as the owner of an RID. The internet already has IANA registries, DNS lookups, certificate authorities and even online lookups for “FIDO Application Facets”  (pls correct me if I’m wrong on this), so I sure this is feasible.

This doesn't really work. Setting aside the legal framework as to
whether domains are property, domains do not represent permanent
bindings. example.com may belong to FooCorp one day and BarCorp the
next.

As to "online lookups of facets", just look at
http://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-appid-and-facets-v1.0-ps-20141208.html
.. Note that any additional grants require that the FacetIDs belong to
the same administrative domain boundary (e.g. what is used for cookie
scoping, aka the "effective TLD + 1 name component")

> Once the user-agent can determine an origin is for the credential/application, it can do SOP checking and permit or deny access to the smart-card application based on the page origin. This can be extended using something like CORS/CSP, to enable the origin site to “delegate” permissions where necessary, using wildcards. If ident.gov.xx wishes to allow access to “*.gov.xx” it can, but can also decide to allow access to “*.com.xx” or even “*”, if it so wishes. On the other hand, “id-provider.com” can restrict access to it’s own domain, and provide identity services a lá OAUTH/OpenID.

The problem with this delegation is that it works against the user's
interests and violates the priority of constituencies.

That is, the user may _not wish_ that their credential be usable to
*.com.xx or even *. In the incentive model, every service provider has
an incentive to ensure their credential is as widely used as possible,
precisely because it favours their ubiquity of deployment. To the
user, this is anathema to privacy - granting access to that credential
allows persistence of tracking and collapses the effective security
model for that credential into "the weakest link in *", which will, of
course, be weak as all get out.

The FIDO model does not _expand_ grants of privileges (beyond the
scope of the existing web model); rather, it could be argued that it
exists to _restrict_.

> Issue 2: User-control of centrally “issued” devices/credentials
> The web is based on a fundamental premise of user-choice. Contrary to this, Global Platform style access-control models and application-loading permissions are based on the idea of centrally managed devices. For bank-issued payment cards and gov-issued e-ID cards, this makes a lot of sense, and is not really a problem.

I would disagree here, in that governments should hardly be more
trusted to keep their citizens' interests at heart compared to
corporations and their consumers. Indeed, private corporations run
more risk of consumer backlash, whereas short of an insurgency, most
governments at a whole are isolated from their citizenry.

> For carrier-issued USIM and eSE devices, there is a fear of lock-out due to the carriers dominant position within the mobile device. The ideal situation would be one in that the user has full control over his/her device. Note however that the problem here is one of who “controls" provisioning (installation of secure applications), not who “uses” the credentials.

The user. The user. The user always controls.

> Question: Can and should the internet support both “centrally-controlled” devices and “user-administered” models?
>
> Suggestion:
> The GP protocols are the de-facto standard for smart card provisioning, with an honorary mention for MULTOS and it’s public-key based alternative. Both can be supported via a “pipe” mechanism to an “admin" AppID owner (thus obeying SOP). Going forwards, the smart-card/secure-chip industry can and should develop alternative methods that permit greater user-control over loading and deleting applications, in a secure fashion (easier said than done, of course!). How long until we see the first “smart-card app-store”?

And until such a solution exists where the user is in control, it
doesn't really bear discussing, does it? If we recognize that the
proposal fails to respect the priority of constituencies, shouldn't
the proposal be ignored until it does?

> Suggestion:
> Several of the recent proposals discuss using browser sandboxing capabilities to isolate the javascript-based middeware from the web-application.

This, of course, is based on a misunderstanding of browser sandboxing
and how it works. It's not some magic sprinkle sauce to be added as
the solution celebre for all our security woes. It requires a careful
and concrete understanding of the risks and the trust model.

In this model, explain why:
1) The user should trust that the middleware is acting in their interests
2) The browser should trust that the middleware is acting in the users interests

Put differently, what would prevent iwanttotrackyou.evil.example.com
from having "Evil Middleware" that fails to separate out per-origin
the keys being used, and instead offers a persistent tracking
identifier?
What would prevent FooCorp from installing "Evil AppID" onto all of
the TPMs they ship on their Smart Televisions, restricting access
unless you consent to "Evil Middleware"?
What would prevent BarCorp from creating "Earnest Effort Middleware",
where they try to do the right thing, but botch security miserably.

This solution is, in effect, a suggestion that the JavaScript language
replace the Java VM as our generic "write once, run everywhere" driver
solution, with roughly the same consideration for security
considerations and implementation correctness. The benefits of
solutions _like_ FIDO (lest I be seen as arguing FIDO uber alles) is
that they can be freely implemented _in the user agent_ and the user
agent can itself verify the protocol is securely and correctly
implemented, as can anyone else. This is a vastly different trust
model than the "trust JS from Honest Achmed"

> There are other issues, and the proposed solutions / suggestions are somewhat freshly-baked, but can we get any consensus on what problems we need to solve and how? We clearly need to find some common ground, and find ways to adapt ISO7816 smart-card paradigms, many that date from the 1970/80’s, to a 2015 web with basic security premises such as SOP.

It depends on your definition of "we".

"We" is not public-webcrypto, nor is it public-web-security. "We" is
the people and vendors who wish to promote such technology for the
Web. They (not "we") have an onus to work to understand the issues and
attendant security concerns, and look to explore if there are
solutions that they can adopt to work with this. I think you've made a
good faith effort to decompose the problem, and I think with further
thought and consideration, it might yield a fruitful result. But I
don't think it's incumbent upon the WebCrypto WG to solve, hence the
opposition to "exploratory chartering".

In particular, start with an approach that "Everything is hostile
_except_ the browser" and "Trust no one, not even 'trusted' parties".
That's the foundational premise of Web Security. Further, if you find
yourself resorting to the notion of prompting, put on your UA hat and
ask the following:
1) What is it we need to ask of the user?
2) Can we be assured that what will happen is what the user expects?
3) Do we expect the user to understand this?

Most problems - including ones in use today - fail this test, and UAs
are trying very hard to do better.

For example, allowing Geolocation over HTTP fails sniff test #2 (we
can't be assured that there is not a MITM attempting to determine the
users' location). Prompting "Do you want to allow access to Key X"
fails question 3, and there is not even a semblance of hope that a
browser can ascertain #1, thus cannot know #2 either.
Received on Tuesday, 3 February 2015 02:10:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 3 February 2015 02:10:12 UTC