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

[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
 for this work.

On Fri, Feb 2, 2018 at 1:20 AM, Henri Sivonen  wrote:

> On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones  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
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Henri Sivonen]

On Tue, Jan 30, 2018 at 6:49 PM, J.C. Jones  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
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[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

On Tue, Jan 30, 2018 at 1:20 PM, J.C. Jones  wrote:

> 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?
>
> On Tue, Jan 30, 2018 at 11:12 AM, Eric Rescorla  wrote:
>
> >
> >
> > On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones  wrote:
> >
> >> 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
> >>
> >
> > 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
> >
> >
> >> 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:
> >> - B

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

[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

On Tue, Jan 30, 2018 at 1:20 PM, J.C. Jones  wrote:

> 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?
>
> On Tue, Jan 30, 2018 at 11:12 AM, Eric Rescorla  wrote:
>
> >
> >
> > On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones  wrote:
> >
> >> 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
> >>
> >
> > 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
> >
> >
> >> 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/tsevyqf
> >> BHLE/lccldWNNBwAJ
> >>
> >> [2] https://w3c.github.io/webauthn/#sctn-appid-ext

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

[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?

On Tue, Jan 30, 2018 at 11:12 AM, Eric Rescorla  wrote:

>
>
> On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones  wrote:
>
>> 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
>>
>
> 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
>
>
>> 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/tsevyqf
>> BHLE/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/UW6WMmo
>> DzEU/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/cryptotoke
>> n_private_api.cc#30
>>
>> [6]
>> https://chromium.googlesource.com/chromium/src.git/+/master/
>> chrome/browser/extensions/api/cryptotoken_private/cry

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

[Eric Rescorla]

On Tue, Jan 30, 2018 at 8:49 AM, J.C. Jones  wrote:

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

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


> 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
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform