1244959 - Implement complete FIDO AppID and Facet algorithm

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, enhancement, P5)

Description

[J.C. Jones [:jcj] (he/they)]

Bug 1231681 did not implement the complete "FIDO AppID and Facet Specification" (https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-appid-and-facets.html), particularly omitting the remote fetches of the TrustedFacets resources. This bug is to complete that implementation.

Comment 1

[J.C. Jones [:jcj] (he/they)]

One can use WebIDL to parse out the JSON in a simpler fashion than was originally expected. See JSON parsing in SubtleCrypto:

https://dxr.mozilla.org/mozilla-central/source/obj-x86_64-pc-linux-gnu/dom/bindings/SubtleCryptoBinding.cpp#3268

Comment 2

[J.C. Jones [:jcj] (he/they)]

This algorithm is 1) not needed for most use cases of using U2F, and 2) not simple to implement, so downgrading to P5. Chances are we'll WONTFIX this unless we find a use case in the wild.

Comment 3

[g.rantila]

Firefox cannot claim to support U2F without it. Period.

On your point "1" JC, please elaborate on how you came to that conclusion. In my opinion, you're simply dead wrong. Websites will not be able to have a mysite.com/account or account.mysite.com where you register your token, and then have a landing.mysite.com where you login. This is NOT uncommon, for numerous reasons. This has worked in Chrome for a few years now, so "2) too hard to implement" would be better off with not supporting U2F at all, rather than a really crippled version.

WONTFIX for this means Firefox doesn't support U2F. Except for some websites under certain circumstances... Feels like a flashback to 1997.

Comment 4

[J.C. Jones [:jcj] (he/they)]

Patches are certainly welcome!

Re: #1, one is conversations among FIDO developers, and also https://github.com/prefiks/u2f4moz/issues/59#issuecomment-326103302 where I asked that of the u2f4moz developer.

Re: #2, this is true; My focus is supporting U2F hardware tokens for Web Authentication, not the FIDO U2F JS API. FIDO U2F API is a best-effort spare-time activity for me. But I'm happy to help others move it along!

Comment 5

[My1]

well jcj there are usecases in the wild.
as of some comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
facebook and github, 2 very big sires apparently use multifacet.

also the solution we have now is just half-baked, multifacet has many uses, like subdomains or apps, so the facets should be properly supported.

Comment 6

[vincent.vanackere]

Hi,

 Just another datapoint: our identity provider service (https://trustelem.com) supports the use of U2F hardware tokens and also requires proper AppID support to work properly.
 So I'd like to add my voice to ask that U2F in Firefox should not be enabled/advertised until proper AppID support has been added. In the opposite case our users will be very confused and this would even be a regression since the current u2f4moz plugin has proper support for this feature...

Comment 7

[J.C. Jones [:jcj] (he/they)]

(In reply to My1 from comment #5)
> well jcj there are usecases in the wild.
> as of some comments on https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> facebook and github, 2 very big sires apparently use multifacet.
> 
> also the solution we have now is just half-baked, multifacet has many uses,
> like subdomains or apps, so the facets should be properly supported.

Fair. That said, Github's U2F works fine for me as-is -- used it just now, and Facebook has previously worked alright before their user-agent detection. While they might use the facet descriptors for some federation login aspects, it's not needed for basic login flows.

In the good news though, I don't personally have any plans to ship FIDO U2F API support, so we don't need to worry about shipping a halfway implementation. I expect this to remain an experimental feature - the purpose in getting it here was to help along W3C Web Authentication.

Other good news: Since this initial implementation, a C++ API for DOM Fetch now exists [1], so it's now just somewhat painful to fetch and decode the Facet metadata -- when I wrote this code last year, it was going to be much harder.


[1] http://searchfox.org/mozilla-central/source/dom/fetch/Fetch.h

Comment 8

[Brad Hill]

Hi.  I was a co-editor / author of the FIDO Alliance facet spec (https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html) with Dirk Balfanz.  In the years since we developed that standard, we've discussed it several times, and both agree that the application to Web Origins was generally too restrictive and perhaps a mistake entirely.  I was originally concerned that a generic eTLD+1 scope would create too broad a scope for phishing using compromised hosts that are otherwise low-value and weakly secured but share the same general DNS scope.  In hindsight, I've come to feel that the concrete benefit of this is much outweighed by the additional complexity for web use cases and the latency introduced in fetching and parsing the facet list.

The Web Authentication WG at the W3C has decided that scoping credentials to the scope of single organizational control, as reflected by the Public Suffix List, is sufficiently secure and meets most use cases.

I would not be sad if Firefox chose to implement U2F using the Web Authentication scoping rules.  However, I would seriously consider not enabling U2F features of Facebook for Firefox if it implements an exact origin match only, since this is likely to leave people stuck in circumstances they cannot remedy.  We root our AppID at https://www.facebook.com but use many other domains, e.g. https://business.facebook.com, https://m.facebook.com, https://www.alpha.facebook.com, https://m.alpha.facebook.com, etc.  We use U2F in more places than just login, e.g. to do in-context re-authentication or "step up" auth on these domains. Introducing additional redirects to a canonical single U2F host would be a big engineering effort and the user experience far from ideal.

Scoping to the eTLD+1 would work fine for us. Algorithmically, this could look like taking both the AppID domain and domain issuing the challenge, descending towards the least-specific label until a PSL boundary is hit, and seeing if the eTLD+1 is a match for both.

These are the rules we'll have to live with anyway in the Web Authentication world, so I see little harm in applying them now, especially if the alternative is the simple match deployed today, which will just break existing scenarios to the point we (Facebook) likely can't enable it.

Comment 9

[My1]

well I think it IS a bit too restrictive. it would have been more awesome if you could allow any domain or whatever in the app id json file and not just subdomains.

especially for services like amazon or so which run the same accounts over a ton of different domains this would have made it easier for those to implement auth.

Comment 10

[Brad Hill]

(In reply to My1 from comment #9)
> well I think it IS a bit too restrictive. it would have been more awesome if
> you could allow any domain or whatever in the app id json file and not just
> subdomains.
> 
> especially for services like amazon or so which run the same accounts over a
> ton of different domains this would have made it easier for those to
> implement auth.

The point is to make it so that no user decision is necessary to avoid phishing attacks.  It is the responsibility of the user agent to verify the authenticity of the remote site issuing the challenge and whether it is a valid scope for signing.  If any origin could sign with any key, forwarding attacks would be possible.  

This would also allow U2F to be used as a sort of super-cookie.  

It is important that U2F not regress to the situation we have today where we are expecting end-users to make trust decisions about what domain they see in the address bar, nor to introduce tracking and non-consensual authentication issues which might make the security benefits of U2F unacceptable to some due to privacy risks.

Restricting to a single organizational scope as defined by the PSL meets these goals while being congruent with other features of the web platform, like cookies and domain lowering, which already allow similar levels information sharing.

Comment 11

[My1]

well if site B would want to be able to get users from site A in, site A would obviously put Site B into the json file, and the json file as far as I know is the only way to get multiple places for one authentication scope anyway.

meaning no phisher can try to get a U2F recognize a challenge for for example facebook.com if they dont have access to facebook's appid file.

Comment 12

[Brad Hill]

(In reply to My1 from comment #11)
> well if site B would want to be able to get users from site A in, site A
> would obviously put Site B into the json file, and the json file as far as I
> know is the only way to get multiple places for one authentication scope
> anyway.
> 
> meaning no phisher can try to get a U2F recognize a challenge for for
> example facebook.com if they dont have access to facebook's appid file.

This bug is about the Firefox implementation.  Nobody is going to update the 3 year old FIDO spec at this point to support web facets outside the eTLD+1, and if Firefox chose to do this, no site would support it because it wouldn't work on any other user agent.  I'm sorry you aren't happy with the spec, My1, but the reasonable choices for resolving this bug seem to be to:

1) stick with current strict match implementation (and break many existing service deployments of U2F)
2) implement the full Facet spec
3) implement the WebAuthN scoping, which is a superset of the Facet scoping and will work with all existing deployments but be somewhat less restrictive

Comment 13

[g.rantila]

Regarding latency, 2FA is something most likely needing human input. The added latency for fetching a sub-kb JSON file (that could even be h2-pushed from "/login") is in comparison, a fly in space, and is to me a non-argument.

Alternative 1 is incredibly bad, in so many ways. I would block Firefox from https://www.npmjs.com/package/u2f-api.

Alternative 3, going with eTLD+1, is a FIDO U2F API breaker - it's against how sites *today* do it, and it's a breaking change to Chrome's implementation. That would basically mean one would need to User Agent detect the browser and create per-browser Registration/Sign requests. Developers wouldn't really love it. If this would, like 1, break existing deployments, I would block Firefox. Sounds more like a whole new version of the spec.

Whatever non-solution suggested and implemented will just push a lot of trouble to users and developers, unless we're talking about a brand new spec. I for one would like an API with a lot fewer weirdnesses and inconsistencies, and to obviously be Promise-based, have better error handling etc, but until then, we have what we have.

It's crazy how fetching and parsing a JSON file blew up this much.

Comment 14

[My1]

@Brad, yeah true, it's about FF and not about the spec, sorry.
@g.rantila I agree fully, we already have enough places where one browser (usually the IE) blows the plans of web devs up and becomes quite annoying in the long run.

and yeah, is fetching and parsing a JSON file so hard?
I sadly only have experience in doing that in PHP but there it's fairly simple, you pull the file using whatever you like most, and throw a json_decode() over it and you have it.

it's probably not that easy in languages which doesnt have stuff like this, but when we already have a tool being able to parse totally overblown websites with scripts totally overblown as well and honestly, failing to parse a single and also pretty simple json sounds like pretty terrible failure.

especially in all the time the user may need for pulling out their U2F stick, plugging it in and then triggering it, you would have done the whole thing way more often than ever needed and even when the stick is already in, the user will probably take a second to move the hand and trigger the stick.

btw what's h2 fetching?

Comment 15

[Brad Hill]

(In reply to g.rantila from comment #13)

> Alternative 3, going with eTLD+1, is a FIDO U2F API breaker - it's against
> how sites *today* do it, and it's a breaking change to Chrome's
> implementation. That would basically mean one would need to User Agent
> detect the browser and create per-browser Registration/Sign requests.
> Developers wouldn't really love it. If this would, like 1, break existing
> deployments, I would block Firefox. Sounds more like a whole new version of
> the spec.
> 
>

I don't think #3 will break any existing service deployments.  The choice to allow or not a signing request based on facet scoping is internal to the user agent and the Web Authentication scoping is a superset of the FIDO 1.0 scoping.

Comment 16

[My1]

well in the direction from chrome to FF isnt a breaker but if someone who uses FF to develop sites and stuff just works and wont work in chrome for a reaon the dev might not see at first glance then well, stuff gets annoying.

Comment 17

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Our guidelines ask you don't argue about priority setting on bugs. Triage leads and Mozillians working on the bug set the priority. See: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Extended, off-topic comments on a bug add noise to the signal. Per, https://bugzilla.mozilla.org/page.cgi?id=restrict_comments_guidelines.html, we've restricted comments on this bug to Mozillians with EDITBUGS permissions.

Comment 18

[J.C. Jones [:jcj] (he/they)]

Attachment: Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

In Comment 8 of Bug 1244959 [1], Brad Hill argues that instead of leaving our
U2F Facet support completely half-way, that we could use the Public Suffix logic
introduced into HTML for W3C Web Authentication (the method named
IsRegistrableDomainSuffixOfOrEqualTo) to scope the FIDO AppID to an eTLD+1
heirarchy. This is a deviation from the FIDO specification, but doesn't break
anything that currently works with our U2F implementation, and theoretically
enables sites that otherwise need an external FacetID fetch which we aren't
implementing.

The downside to this is that it's then Firefox-specific behavior. But since this
isn't a shipped feature, we have more room to experiment. As an additional
bonus, it encourages U2F sites to use the upcoming Web Authentication security
model, which will help them prepare to adopt the newer standard.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1244959#c8

Review commit: https://reviewboard.mozilla.org/r/184944/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/184944/

Comment 19

[J.C. Jones [:jcj] (he/they)]

Comment on attachment 8913563 [details]
Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/184944/diff/1-2/

Comment 20

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8913563 [details]
Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

https://reviewboard.mozilla.org/r/184944/#review191414

I think this is a good compromise, but also a great idea because (as you wrote) folks can focus on a single security model that won't break with WebAuthn in the future. Let's do this.

::: commit-message-6dea0:7
(Diff revision 2)
> +
> +In Comment 8 of Bug 1244959 [1], Brad Hill argues that instead of leaving our
> +U2F Facet support completely half-way, that we could use the Public Suffix logic
> +introduced into HTML for W3C Web Authentication (the method named
> +IsRegistrableDomainSuffixOfOrEqualTo) to scope the FIDO AppID to an eTLD+1
> +heirarchy. This is a deviation from the FIDO specification, but doesn't break

nit: hierarchy

::: dom/u2f/U2F.cpp:149
(Diff revision 2)
> +  nsHTMLDocument* html = document->AsHTMLDocument();
> +  if (NS_WARN_IF(!html)) {
> +    return ErrorCode::BAD_REQUEST;
> +  }
> +
> +  // Use the base domain as the facet for evalution. This lets this algorithm

nit: evaluation

::: dom/u2f/U2F.cpp:171
(Diff revision 2)
> +  MOZ_LOG(gU2FLog, LogLevel::Debug,
> +          ("AppId %s Facet %s", appIdHost.get(), lowestFacetHost.get()));
> +
> +  if (html->IsRegistrableDomainSuffixOfOrEqualTo(NS_ConvertUTF8toUTF16(lowestFacetHost),
> +                                                 appIdHost)) {
>      return ErrorCode::OK;

(I love the fact that `ErrorCode::OK` exists.)

Comment 21

[J.C. Jones [:jcj] (he/they)]

Comment on attachment 8913563 [details]
Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

https://reviewboard.mozilla.org/r/184944/#review191414

Thanks!

Comment 22

[J.C. Jones [:jcj] (he/they)]

Comment on attachment 8913563 [details]
Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/184944/diff/2-3/

Comment 23

[Code Review Bot [:reviewbot]]

Comment on attachment 8913563 [details]
Bug 1244959 - Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets

https://reviewboard.mozilla.org/r/184944/#review191430


C/C++ static analysis didn't find any defects in this patch. Hooray!

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f2d25c30aaed
Use IsRegistrableDomainSuffixOfOrEqualTo for U2F Facets r=ttaubert

Comment 25

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f2d25c30aaed