Intent to Ship - Support already-enrolled U2F devices with Google Accounts for Web Authentication

[J.C. Jones]

Summary: Support already-enrolled U2F devices with Google Accounts for Web
Authentication

Web Authentication is on-track to ship in Firefox 60 [1], and contains
within it support for already-deployed USB-connected FIDO U2F devices, and
we intend to ship with a spec extension feature implemented to support
devices that were already-enrolled using the older U2F Javascript API [2].
That feature depends on Firefox supporting the older API’s algorithm for
relaxing the same-origin policy [3] which is not completely implemented in
Firefox [4].

It appears that many U2F JS API-compatible websites do not require the
cross-origin features currently unimplemented in Firefox, but notably the
Google Accounts service does: For historical reasons (being the first U2F
implementor) their FIDO App ID is “www.gstatic.com” [5] for logins to “
google.com” and its subdomains [6]. Interestingly, as the links to
Chromium’s source code in [5] and [6] show, Chrome chooses to hardcode the
approval of this same-origin override rather than complete the
specification’s algorithm for this domain.

As mentioned in the bug linked in [4], I have a variety of reservations
with the U2F Javascript API’s algorithm. I also recognize that Google
Accounts is the largest player in existing U2F device enrollments. The
purpose of the extension feature in [2] is to permit users who already are
using U2F devices to be able to move seamlessly to Web Authentication --
and hopefully also be able to use browsers other than Chrome to do it.

After discussions with appropriate Googlers confirmed that the “
www.gstatic.com” origin used in U2F is being retired as part of their
change-over to Web Authentication, I propose to hard-code support in Gecko
to permit Google Accounts’ cross-origin U2F behavior, the same way as
Chrome has. I propose to do this for a period of 5 years, until 2023, and
to file a bug to remove this code around that date. That would give even
periodically-used U2F-protected Google accounts ample opportunity to
re-enroll their U2F tokens with the new Web Authentication standard and
provide continuity-of-access. The code involved would be a small search
loop, similar to Chrome’s in [6].

If we choose not to do this, Google Accounts users who currently have U2F
enabled will not be able to authenticate using Firefox until their existing
U2F tokens are re-enrolled using Web Authentication -- meaning not only
will Google need to change to the Web Authentication API, they will also
have to prompt users to go back through the enrollment ceremony. This
process is likely to take several years.

Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=webauthn

Spec: https://www.w3.org/TR/webauthn/

Estimated target release: 60

Preference behind which this is implemented:
security.webauth.webauthn

DevTools support:
N/A

Support by other browser engines:
- Blink: In-progress
- Edge: In-progress
- Webkit: No public announcements

Testing:
Mochitests in-tree; https://webauthn.io/; https://webauthn.bin.coffee/;
https://webauthndemo.appspot.com/; Web Platform Tests in-progress


Cheers,
J.C. Jones and Tim Taubert

[1]
https://groups.google.com/d/msg/mozilla.dev.platform/tsevyqfBHLE/lccldWNNBwAJ

[2] https://w3c.github.io/webauthn/#sctn-appid-extension and
https://bugzilla.mozilla.org/show_bug.cgi?id=1406471

[3]
https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-appid-and-facets-v1.2-ps-20170411.html

[4]
https://groups.google.com/d/msg/mozilla.dev.platform/UW6WMmoDzEU/8h7DFOfsBQAJ
and https://bugzilla.mozilla.org/show_bug.cgi?id=1244959

[5]
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/extensions/api/cryptotoken_private/cryptotoken_private_api.cc#30

[6]
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/extensions/api/cryptotoken_private/cryptotoken_private_api.cc#161

[Eric Rescorla]

Five years seems very long to keep this around. 1-2 seems a lot more
appropriate. When is the gstatic migration goingt o be complete?

-Ekr

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[J.C. Jones]

My understanding is that the gstatic migration will take effect as soon as
Google deploys Web Authentication. Re-enrolling devices will start some
unspecified time after that.

They are concerned about Google Accounts that are accessed using a U2F
device very infrequently (once or twice per year) needing multiple
opportunities to re-enroll, hence asking for the long period.

If we choose a shorter period, the worst-case is some of those long-tail
accounts would need to use Chrome to complete the login flow (presumably)
rather than Firefox or Tor Browser. That is probably okay.

So perhaps February 2020 instead?

[Alex Gaynor]

Is it practical to be data driven about this? Either by telemetry on how
frequently this is used in Firefox, or by Google giving us data on how much
of their userbase is migrated? This has the benefit of either a) letting us
remove code sooner, or b) ensuring we're aware that we'd be breaking the
experience for a significant number of users.

Alex

[Joseph Lorenzo Hall]

+1 this will be very welcome for so many Google Accounts and orgs that use
GSuite but love us some Firefox.

I did want to raise another issue... many activists, journalists,
politicians, political campaign staff, election officials, are increasingly
using Google's Advanced Protection Program (which mandates only u2f
two-factor). This has meant a number of us have to have two browsers open
as we literally cannot use those accounts in Firefox. I'm a bit worried
about what will happen if Google APP enrollees have to re-enroll tokens
instead of the seamless harcoded allowance... I'm just not sure what will
happen. APP account recovery is purposefully Very Hard and slow by design
and that could be some serious headaches for people we've been trying to
move to "unphishable credentials".

best and huge fan, Joe

--
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: j...@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871

[Henri Sivonen]

On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones <j...@mozilla.com> wrote:
> I also recognize that Google
> Accounts is the largest player in existing U2F device enrollments.

...

> If we choose not to do this, Google Accounts users who currently have U2F
> enabled will not be able to authenticate using Firefox until their existing
> U2F tokens are re-enrolled using Web Authentication -- meaning not only
> will Google need to change to the Web Authentication API, they will also
> have to prompt users to go back through the enrollment ceremony. This
> process is likely to take several years.

This seems like a necessary practical reason to make a special
accommodation for user's of Google Accounts.

> After discussions with appropriate Googlers confirmed that the “
> www.gstatic.com” origin used in U2F is being retired as part of their
> change-over to Web Authentication, I propose to hard-code support in Gecko
> to permit Google Accounts’ cross-origin U2F behavior, the same way as
> Chrome has. I propose to do this for a period of 5 years, until 2023, and

Given that users may use their current token for many years, why do we
have to set any particular expiration date for this exception? After
implementing the exception in the first place has become a sunk cost,
is there a reason to believe it will have a large ongoing maintenance
burden?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[J.C. Jones]

Henri,

I think there's value in providing an impetus to Google Accounts to migrate
from U2F-style enrolled credentials to Web Authentication-style. That said,
I agree, it shouldn't be an ongoing maintenance burden.

Thanks, all, for the input on this intent-to-ship. I've filed Bug 1436078
<https://bugzilla.mozilla.org/show_bug.cgi?id=1436078> for this work.