Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[J.C. Jones]

In short, no. I believe not implementing the facet algorithm is a feature.
I recommend migrating to Web Authentication as soon as practical.

I will also point to a post on blink-dev from Adam Langely calling for
websites targeting Chrome to migrate to WebAuthn:
https://groups.google.com/a/chromium.org/d/msg/Blink-dev/SdceviqfKJo/zIMMWWoLBgAJ

J.C.

On Wed, May 22, 2019 at 7:05 AM sraman--- via dev-platform <
dev-platform@lists.mozilla.org> wrote:

> Hi all,
>
> Thank you for enabling U2F!  But Duo Security's implementation of U2F is
> dependent on the Trusted Facet functionality, as we need to reliably
> enroll/authenticate a U2F credential across subdomains. Until the trusted
> facet functionality is implemented I don't believe we can enable our users
> to use U2F in Firefox, even though we have a lot of really passionate U2F
> users.
>
> Are there any thoughts about investing some time into enabling this
> functionality, or considering it on your roadmap?
> ___
> 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: Backward-Compatibility FIDO U2F support for Google Accounts

[sraman--- via dev-platform]

Hi all,

Thank you for enabling U2F!  But Duo Security's implementation of U2F is 
dependent on the Trusted Facet functionality, as we need to reliably 
enroll/authenticate a U2F credential across subdomains. Until the trusted facet 
functionality is implemented I don't believe we can enable our users to use U2F 
in Firefox, even though we have a lot of really passionate U2F users.

Are there any thoughts about investing some time into enabling this 
functionality, or considering it on your roadmap? 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Joseph Lorenzo Hall]

Thanks for being flexible here in the face of adversity, big fan of running
trains even if it seems icky in the short term.

On Wed, Mar 27, 2019 at 1:00 PM JC Jones  wrote:

> On Tuesday, March 26, 2019 at 12:50:21 PM UTC-7, Alex Gaynor wrote:
> > Simply flipping the pref, and not including register support seems a bit
> > unfortunate, as it'll leave some websites in a works-sometimes state.
> While
> > some larger sites have UIs and help articles explaining that Firefox
> works
> > for login but not reigstering a key, many will not. If it's possible to
> > include register support in what rides the train, that seems preferable.
>
> I'm sorry to be unclear. I'm intending to include the register support as
> well.
>
> I have filed Bug 1539541 [0] to do this work:
>
> Enable the security.webauth.u2f by default, to ride the trains
>
> Remove the aOp == U2FOperation::Sign check from EvaluateAppID in
> WebAuthnUtil.cpp, permitting the Google override to work for Register as
> well as Sign.
>
> Further discussion is still welcome, either here or on the bug.
>
>
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1539541
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


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

Don't miss out! CDT's Tech Prom is April 10, 2019, at The
Anthem. Please join us: https://cdt.org/annual-dinner/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[JC Jones]

On Tuesday, March 26, 2019 at 12:50:21 PM UTC-7, Alex Gaynor wrote:
> Simply flipping the pref, and not including register support seems a bit
> unfortunate, as it'll leave some websites in a works-sometimes state. While
> some larger sites have UIs and help articles explaining that Firefox works
> for login but not reigstering a key, many will not. If it's possible to
> include register support in what rides the train, that seems preferable.

I'm sorry to be unclear. I'm intending to include the register support as well.

I have filed Bug 1539541 [0] to do this work:

Enable the security.webauth.u2f by default, to ride the trains

Remove the aOp == U2FOperation::Sign check from EvaluateAppID in 
WebAuthnUtil.cpp, permitting the Google override to work for Register as well 
as Sign.

Further discussion is still welcome, either here or on the bug.


[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1539541
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[J.C. Jones]

Hi Philip:

1) Yes
2) I think so -- it's clearly had substantial refactoring in the process of
moving to Web Authentication
3) I think that's the one, but most sites redistribute a much older version
that used to be served by gstatic.com (I can't find it now) archived here:
https://github.com/fido-alliance/google-u2f-ref-code/blob/master/u2f-gae-demo/war/js/u2f-api.js


On Fri, Mar 22, 2019 at 5:34 AM Philip Jägenstedt 
wrote:

> Hi all,
>
> Some naive questions to understand what's happened here.
>
> Is
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
> the
> API that will be added to Firefox?
>
> Is
>
> https://cs.chromium.org/chromium/src/chrome/browser/resources/cryptotoken/enroller.js
> the
> relevant bit of code in Chromium?
>
> Is https://github.com/grantila/u2f-api the mentioned Google-supplied
> polyfill called u2f-api.js?
>
> On Thu, Mar 21, 2019 at 3:08 PM Henri Sivonen 
> wrote:
>
> > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones  wrote:
> > > It appears that if we want full security key support for Google
> > > Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> > > API support from “experimental and behind a pref”
> >
> > I think it's problematic to describe something as "experimental" if
> > it's not on path to getting enabled. "Experimental and behind a pref"
> > sounds like it's on track to getting enabled, so simultaneously 1)
> > sites have a reason to believe they don't need to do anything for
> > Firefox, since for now users can flip a pref and the feature is coming
> > anyway and 2) still the feature doesn't actually work by default for
> > users, and, considering the penalty of using an experimental feature
> > where the experiment fails is getting locked out of an account for
> > this particular feature.
> >
> > So I think it's especially important to move *somewhere* from the
> > "experimental and behind a pref" state: Either to interop with Chrome
> > to the extent required by actual sites (regardless of what's de jure
> > standard) or to clear removal so that the feature doesn't look like
> > sites should just wait for it to get enabled and that the sites expect
> > the user to flip a pref.
> >
> > As a user, I'd prefer the "interop with Chrome" option.
> >
> > > to either “enabled
> > > by default” or “enabled for specific domains by default.” I am
> > > proposing the latter.
> >
> > Why not the former? Won't the latter still make other sites wait in
> > the hope that if they don't change, they'll get onto the list
> > eventually anyway?
> >
> > > First, we only implemented the optional Javascript version of the API,
> > > not the required MessagePort implementation [3]. This is mostly
> > > semantics, because everyone actually uses the JS API via a
> > > Google-supplied polyfill called u2f-api.js.
> >
> > Do I understand correctly that the part that is actually needed for
> > interop is implemented?
> >
> > > As I’ve tried to establish, I’ve had reasons to resist shipping the
> > > FIDO U2F API in Firefox, and I believe those reasons to be valid.
> > > However, a multi-year delay for the largest security key-enabled web
> > > property is, I think, unreasonable to push upon our users. We should
> > > do what’s necessary to enable full security key support on Google
> > > Accounts as quickly as is  practical.
> >
> > This concern seems to apply to other services as well.
> >
> > > I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t
> > > say whether I would welcome adding more domains to it by default; I
> > > think we’re going to have to take them on a case-by-case basis.
> >
> > What user-relevant problem is solved by having to add domains to a
> > list compared to making the feature available to all domains?
> >
> > --
> > Henri Sivonen
> > hsivo...@mozilla.com
> > ___
> > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Alex Gaynor]

On Tue, Mar 26, 2019 at 3:46 PM J.C. Jones  wrote:

> (Sorry for the delay in replying, had a long-weekend of PTO there)
>
> On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen 
> wrote:
>
> > On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones  wrote:
> > > It appears that if we want full security key support for Google
> > > Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> > > API support from “experimental and behind a pref”
> >
> > I think it's problematic to describe something as "experimental" if
> > it's not on path to getting enabled.
>
>  [...]
>
> > So I think it's especially important to move *somewhere* from the
> > "experimental and behind a pref" state: Either to interop with Chrome
> > to the extent required by actual sites (regardless of what's de jure
> > standard) or to clear removal so that the feature doesn't look like
> > sites should just wait for it to get enabled and that the sites expect
> > the user to flip a pref.
> >
>
> To be clear, our FIDO U2F API support is behind a pref since it's 1)
> deprecated in favor of the superior WebAuthn standard, and 2) our
> implementation is bare-bones. I think these points have merit, but not
> enough to justify waiting as long as we have, let alone longer.
>
>
> > As a user, I'd prefer the "interop with Chrome" option.
> >
>
> Okay.
>
>
> > > to either “enabled by default” or “enabled for specific
> > > domains by default.” I am proposing the latter.
> >
> > Why not the former? Won't the latter still make other sites wait in
> > the hope that if they don't change, they'll get onto the list
> > eventually anyway?
> >
>
> It's certainly easier to simply pref-flip the feature on by default. I'm
> not opposed to that, though it leaves Safari as the lone browser that will
> be dragging the ecosystem to move to WebAuthn.
>
> > First, we only implemented the optional Javascript version of the API,
> > > not the required MessagePort implementation [3]. This is mostly
> > > semantics, because everyone actually uses the JS API via a
> > > Google-supplied polyfill called u2f-api.js.
> >
> > Do I understand correctly that the part that is actually needed for
> > interop is implemented?
> >
>
> Basically, yes. (See the caveats in the original message)
>
>
> >
> > > As I’ve tried to establish, I’ve had reasons to resist shipping the
> > > FIDO U2F API in Firefox, and I believe those reasons to be valid.
> > > However, a multi-year delay for the largest security key-enabled web
> > > property is, I think, unreasonable to push upon our users. We should
> > > do what’s necessary to enable full security key support on Google
> > > Accounts as quickly as is  practical.
> >
> > This concern seems to apply to other services as well.
> >
>
>
> > What user-relevant problem is solved by having to add domains to a
> > list compared to making the feature available to all domains?
> >
>
> Last week's abrupt loss of support on Github [0] is a good case in point.
>
> Does anyone here disagree with simply flipping the preference on by default
> to ride the trains in 68?
>
>
Simply flipping the pref, and not including register support seems a bit
unfortunate, as it'll leave some websites in a works-sometimes state. While
some larger sites have UIs and help articles explaining that Firefox works
for login but not reigstering a key, many will not. If it's possible to
include register support in what rides the train, that seems preferable.

It's probably worth flagging that there'll still be some sites which do not
work even with this, since we have a different implementation strategy than
Chrome, and so some feature detection efforts break.

Cheers,
Alex


>
> [0]
>
> https://www.reddit.com/r/firefox/comments/b39eac/github_no_longer_allows_using_security_keys/
> ___
> 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: Backward-Compatibility FIDO U2F support for Google Accounts

[J.C. Jones]

(Sorry for the delay in replying, had a long-weekend of PTO there)

On Thu, Mar 21, 2019 at 7:08 AM Henri Sivonen  wrote:

> On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones  wrote:
> > It appears that if we want full security key support for Google
> > Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> > API support from “experimental and behind a pref”
>
> I think it's problematic to describe something as "experimental" if
> it's not on path to getting enabled.

 [...]

> So I think it's especially important to move *somewhere* from the
> "experimental and behind a pref" state: Either to interop with Chrome
> to the extent required by actual sites (regardless of what's de jure
> standard) or to clear removal so that the feature doesn't look like
> sites should just wait for it to get enabled and that the sites expect
> the user to flip a pref.
>

To be clear, our FIDO U2F API support is behind a pref since it's 1)
deprecated in favor of the superior WebAuthn standard, and 2) our
implementation is bare-bones. I think these points have merit, but not
enough to justify waiting as long as we have, let alone longer.


> As a user, I'd prefer the "interop with Chrome" option.
>

Okay.


> > to either “enabled by default” or “enabled for specific
> > domains by default.” I am proposing the latter.
>
> Why not the former? Won't the latter still make other sites wait in
> the hope that if they don't change, they'll get onto the list
> eventually anyway?
>

It's certainly easier to simply pref-flip the feature on by default. I'm
not opposed to that, though it leaves Safari as the lone browser that will
be dragging the ecosystem to move to WebAuthn.

> First, we only implemented the optional Javascript version of the API,
> > not the required MessagePort implementation [3]. This is mostly
> > semantics, because everyone actually uses the JS API via a
> > Google-supplied polyfill called u2f-api.js.
>
> Do I understand correctly that the part that is actually needed for
> interop is implemented?
>

Basically, yes. (See the caveats in the original message)


>
> > As I’ve tried to establish, I’ve had reasons to resist shipping the
> > FIDO U2F API in Firefox, and I believe those reasons to be valid.
> > However, a multi-year delay for the largest security key-enabled web
> > property is, I think, unreasonable to push upon our users. We should
> > do what’s necessary to enable full security key support on Google
> > Accounts as quickly as is  practical.
>
> This concern seems to apply to other services as well.
>


> What user-relevant problem is solved by having to add domains to a
> list compared to making the feature available to all domains?
>

Last week's abrupt loss of support on Github [0] is a good case in point.

Does anyone here disagree with simply flipping the preference on by default
to ride the trains in 68?


[0]
https://www.reddit.com/r/firefox/comments/b39eac/github_no_longer_allows_using_security_keys/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Philip Jägenstedt]

Hi all,

Some naive questions to understand what's happened here.

Is
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api
the
API that will be added to Firefox?

Is
https://cs.chromium.org/chromium/src/chrome/browser/resources/cryptotoken/enroller.js
the
relevant bit of code in Chromium?

Is https://github.com/grantila/u2f-api the mentioned Google-supplied
polyfill called u2f-api.js?

On Thu, Mar 21, 2019 at 3:08 PM Henri Sivonen  wrote:

> On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones  wrote:
> > It appears that if we want full security key support for Google
> > Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> > API support from “experimental and behind a pref”
>
> I think it's problematic to describe something as "experimental" if
> it's not on path to getting enabled. "Experimental and behind a pref"
> sounds like it's on track to getting enabled, so simultaneously 1)
> sites have a reason to believe they don't need to do anything for
> Firefox, since for now users can flip a pref and the feature is coming
> anyway and 2) still the feature doesn't actually work by default for
> users, and, considering the penalty of using an experimental feature
> where the experiment fails is getting locked out of an account for
> this particular feature.
>
> So I think it's especially important to move *somewhere* from the
> "experimental and behind a pref" state: Either to interop with Chrome
> to the extent required by actual sites (regardless of what's de jure
> standard) or to clear removal so that the feature doesn't look like
> sites should just wait for it to get enabled and that the sites expect
> the user to flip a pref.
>
> As a user, I'd prefer the "interop with Chrome" option.
>
> > to either “enabled
> > by default” or “enabled for specific domains by default.” I am
> > proposing the latter.
>
> Why not the former? Won't the latter still make other sites wait in
> the hope that if they don't change, they'll get onto the list
> eventually anyway?
>
> > First, we only implemented the optional Javascript version of the API,
> > not the required MessagePort implementation [3]. This is mostly
> > semantics, because everyone actually uses the JS API via a
> > Google-supplied polyfill called u2f-api.js.
>
> Do I understand correctly that the part that is actually needed for
> interop is implemented?
>
> > As I’ve tried to establish, I’ve had reasons to resist shipping the
> > FIDO U2F API in Firefox, and I believe those reasons to be valid.
> > However, a multi-year delay for the largest security key-enabled web
> > property is, I think, unreasonable to push upon our users. We should
> > do what’s necessary to enable full security key support on Google
> > Accounts as quickly as is  practical.
>
> This concern seems to apply to other services as well.
>
> > I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t
> > say whether I would welcome adding more domains to it by default; I
> > think we’re going to have to take them on a case-by-case basis.
>
> What user-relevant problem is solved by having to add domains to a
> list compared to making the feature available to all domains?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
> ___
> 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: Backward-Compatibility FIDO U2F support for Google Accounts

[Henri Sivonen]

On Thu, Mar 14, 2019 at 8:12 PM J.C. Jones  wrote:
> It appears that if we want full security key support for Google
> Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> API support from “experimental and behind a pref”

I think it's problematic to describe something as "experimental" if
it's not on path to getting enabled. "Experimental and behind a pref"
sounds like it's on track to getting enabled, so simultaneously 1)
sites have a reason to believe they don't need to do anything for
Firefox, since for now users can flip a pref and the feature is coming
anyway and 2) still the feature doesn't actually work by default for
users, and, considering the penalty of using an experimental feature
where the experiment fails is getting locked out of an account for
this particular feature.

So I think it's especially important to move *somewhere* from the
"experimental and behind a pref" state: Either to interop with Chrome
to the extent required by actual sites (regardless of what's de jure
standard) or to clear removal so that the feature doesn't look like
sites should just wait for it to get enabled and that the sites expect
the user to flip a pref.

As a user, I'd prefer the "interop with Chrome" option.

> to either “enabled
> by default” or “enabled for specific domains by default.” I am
> proposing the latter.

Why not the former? Won't the latter still make other sites wait in
the hope that if they don't change, they'll get onto the list
eventually anyway?

> First, we only implemented the optional Javascript version of the API,
> not the required MessagePort implementation [3]. This is mostly
> semantics, because everyone actually uses the JS API via a
> Google-supplied polyfill called u2f-api.js.

Do I understand correctly that the part that is actually needed for
interop is implemented?

> As I’ve tried to establish, I’ve had reasons to resist shipping the
> FIDO U2F API in Firefox, and I believe those reasons to be valid.
> However, a multi-year delay for the largest security key-enabled web
> property is, I think, unreasonable to push upon our users. We should
> do what’s necessary to enable full security key support on Google
> Accounts as quickly as is  practical.

This concern seems to apply to other services as well.

> I’ve proposed here making the FIDO U2F API whitelist a pref. I can’t
> say whether I would welcome adding more domains to it by default; I
> think we’re going to have to take them on a case-by-case basis.

What user-relevant problem is solved by having to add domains to a
list compared to making the feature available to all domains?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[jonathan--- via dev-platform]

On Thursday, March 14, 2019 at 7:22:21 PM UTC-4, acze...@google.com wrote:
> Hi there,
> 
> Chiming in from Google.  This has nothing to do with our level of motivation 
> (which is high btw).  This has to do with OEM burned-in images on Android 
> devices that have already shipped and the lifecycle of these devices out in 
> the field.  Without going into too many details, in order to not lock users 
> out of their devices, we cannot switch u2f register to webauthn create() 
> until there is sufficient churn in Android devices.  You can expect webauthn 
> get() to come much much sooner, as that is not impacted.
> 
> Again, this is only happening because of how the code that adds accounts is 
> burned into certain devices.  There are not any other websites, that I'm 
> aware of, that are in a similar  unfortunate situation.

Hi Alexei,

Thanks for the info, can you provide some more detail?

1) Is it impossible to update the devices in question or is the OEM just not 
shipping updates?
2) What workarounds are available on Google's side to resolve this issue 
without including this ugly hack in Firefox, and why haven't they been deployed?
3) Why are we just finding about this now, in 2019, long after all of the bits 
for WebAuthn have shipped? It's not like WebAuthn was a surprise on the 
roadmap, we have been steadily moving towards it for many years now in an 
ecosystem that Google created.

Jonathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[aczeskis--- via dev-platform]

Hi there,

Chiming in from Google.  This has nothing to do with our level of motivation 
(which is high btw).  This has to do with OEM burned-in images on Android 
devices that have already shipped and the lifecycle of these devices out in the 
field.  Without going into too many details, in order to not lock users out of 
their devices, we cannot switch u2f register to webauthn create() until there 
is sufficient churn in Android devices.  You can expect webauthn get() to come 
much much sooner, as that is not impacted.

Again, this is only happening because of how the code that adds accounts is 
burned into certain devices.  There are not any other websites, that I'm aware 
of, that are in a similar  unfortunate situation.

And so I'm hoping (and strongly believe) that this move would not encourage 
more usages of u2f (over webauthn).  

Thanks,
-Alexei

On Thursday, March 14, 2019 at 2:48:39 PM UTC-7, Robert O'Callahan wrote:
> On Fri, Mar 15, 2019 at 10:35 AM devsnek 
> wrote:
> 
> > If this is how you feel, encourage Google to fix the problem. This isn't
> > Firefox's fault, Firefox is doing the right thing by supporting
> > standardized APIs instead of "whatever Google uses". It's incredibly
> > frustrating and demoralizing to see web standards being undermined in this
> > way.
> >
> 
> Mozilla people know this and I'm sure they've made every effort to
> "encourage" Google. It's up to you, and whoever else you can organize, to
> exert whatever additional pressure you can on Google (on this and similar
> issues).
> 
> Rob
> -- 
> Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
> mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
> fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
> dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
> hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Robert O'Callahan]

On Fri, Mar 15, 2019 at 10:35 AM devsnek 
wrote:

> If this is how you feel, encourage Google to fix the problem. This isn't
> Firefox's fault, Firefox is doing the right thing by supporting
> standardized APIs instead of "whatever Google uses". It's incredibly
> frustrating and demoralizing to see web standards being undermined in this
> way.
>

Mozilla people know this and I'm sure they've made every effort to
"encourage" Google. It's up to you, and whoever else you can organize, to
exert whatever additional pressure you can on Google (on this and similar
issues).

Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[devsnek]

On Thursday, 14 March 2019 13:12:24 UTC-5, JC Jones  wrote:

> However, a multi-year delay for the largest security key-enabled web
> property is, I think, unreasonable to push upon our users. We should
> do what’s necessary to enable full security key support on Google
> Accounts as quickly as is  practical.

If this is how you feel, encourage Google to fix the problem. This isn't 
Firefox's fault, Firefox is doing the right thing by supporting standardized 
APIs instead of "whatever Google uses". It's incredibly frustrating and 
demoralizing to see web standards being undermined in this way.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Daniel Veditz]

On Thu, Mar 14, 2019 at 11:25 AM Alex Gaynor  wrote:

> one overriding concern: phishing, particularly moderately-sophisticated
> phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a
> scourge.


TOTP was never much defense against phishing, just password compromise
(shoulder surfing, site breaches). In the late 90's AOL support techs were
regularly phished for their RSA-fob tokens by people trying to get into
AOLs systems. WebAuthn is solving a very real and very old problem.

 -Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[Alex Gaynor]

There are a lot of good reasons to oppose this:

- This is a very frustrating _expansion_ of non-standard APIs, more than a
year after we shipped the W3C standard API
- It'll put pressure on other browsers, which were only implementing
webauthn, to also support u2f.js
- It'll prolong the period of having multiple APIs, which I think
contributes to a lot of confusion about the ecosystem
- Once we have the whitelist, there will doubtlessly be other websites who
ask to be placed on it, giving them an excuse to not migrate to webauthn

Having said all of those -- which are real and true -- there's one
overriding concern: phishing, particularly moderately-sophisticated
phishing which can handle forms of 2FA such as TOTP, SMS, or push, is a
scourge. It is brutally effective, and far too cheap to scale. If this is
the price we need to pay to give our users the protections of security
keys, it's worth it. Further, support by default in more browsers will
hopefully be a good thing for ecosystem wide security key adoption.

I desperately hope some combination of Google Accounts, Android, and Chrome
have a strategy for migrating Google Accounts to webauthn before all these
older Androids cycle out. But in the meantime, I don't think it's fair that
that block our users from phishing resilient authenticators. Thanks for
putting this together JS.

Alex

On Thu, Mar 14, 2019 at 2:12 PM J.C. Jones  wrote:

> Web Authentication (WebAuthn) is our best technical response to
> phishing, which is why we’ve championed it as a technology. All major
> browsers either support it already, or have their support in-progress,
> yet adoption by websites has been slow. The deprecated Javascript API
> that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to
> Chromium-based browsers.
>
>
> # tl;dr #
>
> To make security keys work with Google Accounts in the near future, I
> propose enabling our FIDO U2F API for google.com domains, controlled
> by a whitelist preference. Waiting on Google Accounts to fully support
> Web Authentication will probably take too long, since it’s Android
> deployments which are holding them up.
>
>
> # Background #
>
> More than a year ago, I proposed here an interim solution to permit
> Google Accounts to use existing FIDO U2F API credentials in Firefox
> [1] which was implemented in Bug 1436078. We agreed then to implement
> a hard-coded permission for Google Accounts when utilizing FIDO U2F
> API credential support, whether that was via Web Authentication’s
> backward compatibility extension, or via Firefox’s FIDO U2F API
> support hidden behind the “security.webauth.u2f” preference.
>
> We’ve recently learned that Google Accounts has slipped their schedule
> for using Web Authentication to register new credentials. This delay
> is attributed to security key support on Android being, for most
> devices, non-upgradable. WebAuthn is backwards-compatible with
> credentials produced by the FIDO U2F API. However, WebAuthn-produced
> credentials cannot be used with the FIDO U2F API. Because of that,
> credentials created using WebAuthn will never be usable on the
> majority of FIDO U2F-only Android devices currently in circulation.
>
> Due to this issue, there has been an unclear timeline communicated to
> me for when Google Accounts will support registering security keys
> using Web Authentication.
>
>
> # Proposal #
>
> It appears that if we want full security key support for Google
> Accounts in Firefox in the near term, we need to graduate our FIDO U2F
> API support from “experimental and behind a pref” to either “enabled
> by default” or “enabled for specific domains by default.” I am
> proposing the latter.
>
>
> ## Thorny issues in enabling our FIDO U2F API implementation ##
>
> This is not as simple a decision as it might appear. Certainly we want
> to encourage adoption of Web Authentication rather than the FIDO U2F
> API. There have already been sad cases of well-known web properties
> implementing the deprecated standard after we shipped WebAuthn [2].
> There’s also the matter that we haven’t built-out the whole of the
> FIDO U2F API.
>
> Firefox’s implementation of the FIDO U2F API is deliberately incomplete:
>
> First, we only implemented the optional Javascript version of the API,
> not the required MessagePort implementation [3]. This is mostly
> semantics, because everyone actually uses the JS API via a
> Google-supplied polyfill called u2f-api.js. But the specification is
> the specification.
>
> Second, we do not perform the “Trusted Facet List” portions of the
> “Determining if a Caller's FacetID is Authorized for an AppID”
> algorithm [4] from the specification (we stop at step 3). It seems:
> under-specified [5]; of dubious security/

Intent-to-Ship: Backward-Compatibility FIDO U2F support for Google Accounts

[J.C. Jones]

Web Authentication (WebAuthn) is our best technical response to
phishing, which is why we’ve championed it as a technology. All major
browsers either support it already, or have their support in-progress,
yet adoption by websites has been slow. The deprecated Javascript API
that WebAuthn replaces, the FIDO U2F API [0], is mostly confined to
Chromium-based browsers.


# tl;dr #

To make security keys work with Google Accounts in the near future, I
propose enabling our FIDO U2F API for google.com domains, controlled
by a whitelist preference. Waiting on Google Accounts to fully support
Web Authentication will probably take too long, since it’s Android
deployments which are holding them up.


# Background #

More than a year ago, I proposed here an interim solution to permit
Google Accounts to use existing FIDO U2F API credentials in Firefox
[1] which was implemented in Bug 1436078. We agreed then to implement
a hard-coded permission for Google Accounts when utilizing FIDO U2F
API credential support, whether that was via Web Authentication’s
backward compatibility extension, or via Firefox’s FIDO U2F API
support hidden behind the “security.webauth.u2f” preference.

We’ve recently learned that Google Accounts has slipped their schedule
for using Web Authentication to register new credentials. This delay
is attributed to security key support on Android being, for most
devices, non-upgradable. WebAuthn is backwards-compatible with
credentials produced by the FIDO U2F API. However, WebAuthn-produced
credentials cannot be used with the FIDO U2F API. Because of that,
credentials created using WebAuthn will never be usable on the
majority of FIDO U2F-only Android devices currently in circulation.

Due to this issue, there has been an unclear timeline communicated to
me for when Google Accounts will support registering security keys
using Web Authentication.


# Proposal #

It appears that if we want full security key support for Google
Accounts in Firefox in the near term, we need to graduate our FIDO U2F
API support from “experimental and behind a pref” to either “enabled
by default” or “enabled for specific domains by default.” I am
proposing the latter.


## Thorny issues in enabling our FIDO U2F API implementation ##

This is not as simple a decision as it might appear. Certainly we want
to encourage adoption of Web Authentication rather than the FIDO U2F
API. There have already been sad cases of well-known web properties
implementing the deprecated standard after we shipped WebAuthn [2].
There’s also the matter that we haven’t built-out the whole of the
FIDO U2F API.

Firefox’s implementation of the FIDO U2F API is deliberately incomplete:

First, we only implemented the optional Javascript version of the API,
not the required MessagePort implementation [3]. This is mostly
semantics, because everyone actually uses the JS API via a
Google-supplied polyfill called u2f-api.js. But the specification is
the specification.

Second, we do not perform the “Trusted Facet List” portions of the
“Determining if a Caller's FacetID is Authorized for an AppID”
algorithm [4] from the specification (we stop at step 3). It seems:
under-specified [5]; of dubious security/privacy advantage [6]; and
it’s rarely necessary [7].

I don’t intend to invest the engineering time to fix the above issues
(neither coding nor spec-wrangling). The anti-phishing future is Web
Authentication, and we should only care about getting Firefox users to
that future.


# Enabling the whole FIDO U2F API for Google Accounts #

Conventional wisdom says that the largest installed base of security
keys in-use remains with Google Accounts, whether via GSuite or public
accounts. It appears that the only way we get Firefox users of Google
Accounts fully able to use security keys is to enable FIDO U2F API
support so that said users can enroll via FIDO U2F API, and then
authenticate via … well, either. We will have to trust that Google
will roll out authentication-via-WebAuthn quickly for the sake of the
standard moving forward.

This also would solve a longstanding issue where users of Tor Browser
can’t enroll in Google Advanced Protection, despite the clear
advantages.


## What this looks like in code ##

First, I would change the existing security.webauth.u2f pref from
being enforced via WebIDL annotation to in-code checks.

Next, I propose to add a new pref:

pref("security.webauth.u2f_enabled_domains", “google.com“);

This would be a list of domain names that would be matched against the
caller, specifically: If one of the listed domains is a registrable
domain suffix of or is equal to [8] caller’s origin’s effective
domain, we’d enable the FIDO U2F API for that domain.

Finally, I would remove the “aOp == U2FOperation::Sign” check from
EvaluateAppID in WebAuthnUtil.cpp, permitting the Google override to
work for Register as well as Sign.


# Concluding thoughts #

As I’ve tried to establish, I’ve had reasons to resist shipping the
FIDO U2F

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
<https://bugzilla.mozilla.org/show_bug.cgi?id=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 W

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

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

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

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

Re: u2f

[J.C. Jones]

OK, that seems to jive with the Fedora bug that needed u2f-hidraw-policy:

https://bugzilla.redhat.com/show_bug.cgi?id=1513968

Given that, ibhidapi-hidraw0 might be what's needed on Debian, but I
haven't tested it yet.

I've filed Bug 1434277
<https://bugzilla.mozilla.org/show_bug.cgi?id=1434277> to collect
information on Linux dependencies for the Firefox 60 release notes. Let's
take the analysis there for anyone up for helping us pin this down.

Thanks!
J.C.

On Mon, Jan 29, 2018 at 4:25 PM, Kurt Roeckx  wrote:

> On Mon, Jan 29, 2018 at 09:36:15AM -0700, J.C. Jones wrote:
> > The only big U2F property I am familiar with that our support doesn't
> > function for is Google Accounts, but I'm sure there are others. (It'd be
> > interesting to get a list. I'll take that to a different thread, though)
>
> I've spend some time trying to figure out some of the problems.
>
> u2f-host pointed out that it couldn't find any U2F device. strace
> showed it tried to open /dev/hidraw* and I needed to give myself
> write access to that file. After fixing that most things started
> to work. It seems that chromium also stopped working and also
> needed that permission change.
>
> I was under the impression that
> /lib/udev/rules.d/70-debian-uaccess.rules (part of the udev
> package) should have fixed those permissions for me, and that that
> used to work correctly. In stable I do get the correct
> permissions.
>
> The only other site I can't get working is facebook.
>
> > Kurt - So the webauthn support isn't working on Linux for you? The only
> > dependency is libudev, but there may be a hid profile somewhere needed.
> At
> > least one person on IRC reported that it didn't work on arch until
> > installing pcscd- but it was clearly something in the dependency tree,
> not
> > pcscd itself. If you find the answer, let me know... We need to nail that
> > down for the release notes.
>
> I already had pcscd installed.
>
>
> Kurt
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[Kurt Roeckx]

On Mon, Jan 29, 2018 at 09:36:15AM -0700, J.C. Jones wrote:
> The only big U2F property I am familiar with that our support doesn't
> function for is Google Accounts, but I'm sure there are others. (It'd be
> interesting to get a list. I'll take that to a different thread, though)

I've spend some time trying to figure out some of the problems.

u2f-host pointed out that it couldn't find any U2F device. strace
showed it tried to open /dev/hidraw* and I needed to give myself 
write access to that file. After fixing that most things started
to work. It seems that chromium also stopped working and also
needed that permission change.

I was under the impression that
/lib/udev/rules.d/70-debian-uaccess.rules (part of the udev
package) should have fixed those permissions for me, and that that
used to work correctly. In stable I do get the correct
permissions.

The only other site I can't get working is facebook.

> Kurt - So the webauthn support isn't working on Linux for you? The only
> dependency is libudev, but there may be a hid profile somewhere needed. At
> least one person on IRC reported that it didn't work on arch until
> installing pcscd- but it was clearly something in the dependency tree, not
> pcscd itself. If you find the answer, let me know... We need to nail that
> down for the release notes.

I already had pcscd installed.


Kurt

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[greyhorseman]

On Sunday, January 28, 2018 at 3:03:54 PM UTC-5, Daniel Veditz wrote:
> On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman wrote:
> 
> > so we're talking 2 full releases and maybe 6-7 months? Am I at at least
> > close to correct.
> >
> 
> If your question was truly "allow ME to use my ubikeys?" (emphasis mine)
> then you can do that since Firefox 57, by changing some internal prefs.
> https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/
> 
> If you question was more the "support this standard fully" part that's a
> trick question. U2F is not a standard and even members of the group that
> pushed it have implemented some things incompatibly (due to ambiguities in
> the spec). The actual standard that grew out of it, Web Authentication,
> seems pretty stable but it's not official yet.  The published "Working
> Draft (https://www.w3.org/TR/webauthn/) was updated in December, and the
> Editors Draft has updates even more recent.
> 
> This spec flux also means that the answer to the first possible question
> varies because different sites have implemented U2F based on different
> versions of the spec so Firefox may not work even though both site and
> browser nominally support it.
> 
> -Dan Veditz

Thanks Dan,
I've done the hack in Firefox and it sill doesn't work. And I sure can't ask 
Google to help me totally stop using their browser which I'd like to do. But 
that said there are still a couple sites that I could use it on but I think 
they probably can't help - too small?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[J.C. Jones]

Our U2F support is incomplete, due to complexities with and ambiguities
related to the algorithm U2F uses to bypass the single-origin security
policy. I chose not to spend the time to implement that in favor of Web
Authentication.

The only big U2F property I am familiar with that our support doesn't
function for is Google Accounts, but I'm sure there are others. (It'd be
interesting to get a list. I'll take that to a different thread, though)

Kurt - So the webauthn support isn't working on Linux for you? The only
dependency is libudev, but there may be a hid profile somewhere needed. At
least one person on IRC reported that it didn't work on arch until
installing pcscd- but it was clearly something in the dependency tree, not
pcscd itself. If you find the answer, let me know... We need to nail that
down for the release notes.

Thanks,
J.C.



On Jan 29, 2018 3:45 AM, "Kurt Roeckx"  wrote:

On 28/01/2018 21:03, Daniel Veditz wrote:

> On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman  wrote:
>
> so we're talking 2 full releases and maybe 6-7 months? Am I at at least
>> close to correct.
>>
>>
> If your question was truly "allow ME to use my ubikeys?" (emphasis mine)
> then you can do that since Firefox 57, by changing some internal prefs.
> https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-
> firefox-quantum/
>

I've tried this in 57 at that time and 58 this weekend on Linux without
getting it to work. So for sites I need to log in that support U2F I
currently need to use either the ESR version with the plugin or chromium.


Kurt

___
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: u2f

[Kurt Roeckx]

On 28/01/2018 21:03, Daniel Veditz wrote:

On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman  wrote:


so we're talking 2 full releases and maybe 6-7 months? Am I at at least
close to correct.



If your question was truly "allow ME to use my ubikeys?" (emphasis mine)
then you can do that since Firefox 57, by changing some internal prefs.
https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/


I've tried this in 57 at that time and 58 this weekend on Linux without 
getting it to work. So for sites I need to log in that support U2F I 
currently need to use either the ESR version with the plugin or chromium.



Kurt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[Daniel Veditz]

On Sat, Jan 27, 2018 at 6:35 PM, greyhorseman  wrote:

> so we're talking 2 full releases and maybe 6-7 months? Am I at at least
> close to correct.
>

If your question was truly "allow ME to use my ubikeys?" (emphasis mine)
then you can do that since Firefox 57, by changing some internal prefs.
https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/

If you question was more the "support this standard fully" part that's a
trick question. U2F is not a standard and even members of the group that
pushed it have implemented some things incompatibly (due to ambiguities in
the spec). The actual standard that grew out of it, Web Authentication,
seems pretty stable but it's not official yet.  The published "Working
Draft (https://www.w3.org/TR/webauthn/) was updated in December, and the
Editors Draft has updates even more recent.

This spec flux also means that the answer to the first possible question
varies because different sites have implemented U2F based on different
versions of the spec so Firefox may not work even though both site and
browser nominally support it.

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[Boris Zbarsky]

On 1/27/18 9:35 PM, greyhorseman wrote:

so we're talking 2 full releases and maybe 6-7 months? Am I at at least close 
to correct.


According to , Firefox 
60 should shop in about 3.5 months if nothing weird happens.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[greyhorseman]

On Friday, January 26, 2018 at 9:34:19 PM UTC-5, Daniel Veditz wrote:
> On Fri, Jan 26, 2018 at 6:06 PM, greyhorseman  wrote:
> 
> > question is when, if ever, Firefox is going to support this standard fully
> > and allow me to use my ubikeys?
> >
> 
> https://hacks.mozilla.org/2018/01/using-hardware-token-based-2fa-with-the-webauthn-api/
Thanks for the link.

so we're talking 2 full releases and maybe 6-7 months? Am I at at least close 
to correct.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: u2f

[Daniel Veditz]

On Fri, Jan 26, 2018 at 6:06 PM, greyhorseman  wrote:

> question is when, if ever, Firefox is going to support this standard fully
> and allow me to use my ubikeys?
>

https://hacks.mozilla.org/2018/01/using-hardware-token-based-2fa-with-the-webauthn-api/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

u2f

[greyhorseman]

question is when, if ever, Firefox is going to support this standard fully and 
allow me to use my ubikeys?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

By the way, I just got informed (from Google) that TLS Channel ID, even if 
activated on Google servers (including appspot), is only enforced for few users 
for now (even If I am not sure how they do that :) )

So Firefox users should not be blocked for that reason :)

They seem to agree you probably should focus on "the updated specification, the 
Token Binding one. Since that has a better chance of getting approved in the 
IETF"
https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04

So great news. Please consider looking the new Token Binding specifications...

Thanx again for all your great work.
--
Frédéric



On Monday, February 8, 2016 at 11:36:38 PM UTC+1, Eric Rescorla wrote:
> On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin 
> wrote:
> 
> > Hi,
> >
> > thanx for the answer.
> >
> > Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a
> > few days ago on FIDO DEV forum):
> >
> > "the new spec that replaces ChannelID is called "Token Binding", and is in
> > the process of being standardized by the IETF (
> > https://datatracker.ietf.org/wg/tokbind/documents/).
> >
> > It turns out that as far as FIDO is concerned, a Token Binding key or a
> > ChannelID key are really the same thing: it's a public key that will be
> > included in the client data and signed by the Authenticator. So while
> > you're correct in pointing out that it's a bit weird that FIDO should
> > reference a non-standard, other than changing a few words here and there I
> > don't expect any changes to the FIDO specs once the Token Binding drafts
> > have become standards."
> >
> > Source :
> > https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ
> >
> 
> I'm not following how this is responsive to my point, which isn't about the
> text
> in FIDO but rather about what actually goes into Firefox. From that
> perspective,
> what Dirk says is correct, namely that the FIDO interface to Token Binding
> and Channel ID are very similar. However, we have to implement one or the
> other or both in TLS, and I don't see a lot of value in doing both.
> 
> 
> I am still concerned about Mozilla Foundation deciding not to implement
> > this protection inside Firefox for two main reasons.
> >
> > 1) From a security architect perspective. This is an official
> > recommendation that makes sens to prevent MITM attacks. FIDO U2F was
> > created to minimize/eliminate that kind of risk. This would rather be a
> > more secure decision to fully implement the best options. (I am working for
> > a FIDO U2F device manufacturer and that's what we did on our side).
> 
> 
> I don't understand this point. The manufacturer doesn't implement token
> binding:
> it's in the browser stack.
> 
> 
> 2) Firefox users could be discriminated out of servers implementing this
> > protection. Even if this is mostly/only the case on Google authentication
> > servers now, this would already make a difference. I am not a Google fan
> > boy -and I am working with other online services to integrate FIDO U2F
> > technology- but protecting their services accounts is often what everyone
> > is thinking about now when discussing FIDO U2F (protecting Gmail, Gdrive,
> > Youtube, or whatever Google related accounts). Did you speak with Google
> > team guys to know if they will let Firefox be compatible with their FIDO
> > U2F second factor option even without ChannelID protection on the client
> > side?
> 
> 
> Well, I see Ryan Sleevi responded below, but no, I haven't validated this
> one way
> or the other with Google. With that said, I would be somewhat disappointed
> if
> Google required Token Binding with U2F, given that they don't require it
> without
> U2F. It's certainly not consistent with previous claims -- or the
> underlying design
> of FIDO -- to say that token binding is required for FOD to add value.
> 
> 
> 
> > (this would mean that they'll accept to lower their security to make it
> > compatible to Mozilla/Firefox implementation...
> 
> 
> Not really. See above.
> 
> 
> They can decide that, even if questionable...)
> >
> 
> Well, it's worth noting that while they are different mechanisms, U2F +
> pinning offers
> much of the MITM protection that Token Binding provides, and Firefox already
> pins Google services.
> 
> -Ekr
> 
> 
> --
> > Fred
> >
> > On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> > > On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir
> > 

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

On Monday, February 8, 2016 at 10:54:36 PM UTC+1, Ryan Sleevi wrote:
> On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
> >
> > 1) From a security architect perspective. This is an official 
> > recommendation that makes sens to prevent MITM attacks. FIDO U2F was 
> > created to minimize/eliminate that kind of risk.
> 
> U2F itself addresses phishing. Token Binding (attempts) to address
> MITM, but it's worth noting that they are separate problems with
> separate solutions. U2F / FIDO are still able to handedly address the
> former problem, without requiring treatment of the latter - it merely
> establishes how they can be used cooperatively, but that's not
> intrinsically necessary, nor necessarily wise.

Regarding "Addressing phishing", we all know this is a claim that can be 
supported very badly :) I heard so many times SMS codes and/or (T)OTP were 
supposed to cover that. Of course not. We both know that. Oh My.
http://www.neowave.fr/pleaseno/SMS_OTP_TOTP_QRCODE_SSL_ARE_NOT_SOLUTIONS.pdf

I really do support the simplified PKI design behind FIDO U2F (I am used to 
more standard and more complex to deploy PKI based token...) and I believe FIDO 
U2F is a great way to fight phishing attacks... but FIDO U2F security was 
designed to rely partially on SSL security since the server is identified 
through its hashed domain name... and users are supposed to be confident with 
this domain name through SSL server certificates. That's why... while I agree 
that fighting phishing and MITM may be different problems with different 
solutions, even the official FIDO U2F specifications makes it clear that TLS 
Channel ID is a recommended Security Measure linked to U2F architecture.
Search "[SM-12]" inside 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
I don't say there is a magical solution when mixing decentralized PKI and 
"pyramidal" PKI and there is no true server to device mutual authentication, 
SSL/TLS is used at this level (FIDO U2F Client/browser is still in charge of 
server authentication), SSL/TLS security is really linked to U2F regarding to 
MITM attacks conter measure.

> > 2) Firefox users could be discriminated out of servers implementing this 
> > protection.
> 
> Hopefully, you can likely recognize why this represents a very
> troubling problem of Token Binding - it enables service providers
> greater control to discriminate against users, reducing user freedom
> and the role of the browser as the user's agent.

Oh, there are already tons of way to discriminate browsers :)
Here it is just trying to push security recommendations to the max.
FIDO U2F technically even allow servers to discriminate token manufacturers. It 
goes both way and I am not even sure it is a real problem...
For now, the real problem is that FIDO U2F is the most secure way for users to 
authenticate directly to Google, Dropbox or GitHub services... and Firefox 
users (like myself) are already discriminated out of this security 
level/option. GitHub server authentication do not use TLS Channel ID (that's 
why we can already use firefox with the FIDO U2F Firefox addon from Pawel 
Chmielowski). For now, you can make your firefox trying to impersonate Chrome, 
it won't pass Google servers TLS Channel ID.

> While I think there's no disagreement that 'hostile' MITM is bad,
> there are plenty of cases where users intentionally and actively MITM
> themselves, for purposes that range from 'clearly legitimate' to
> 'questionable, but it's the user's call". In the case of "clearly
> legitimate", consider the work of security researchers and developers
> who wish to MITM themselves or their applications, in order to
> determine what data is leaking out. Any solution that actively
> prohibits this can end up undermining user's security.
> 
> If you think this is academic, consider that many service providers
> consider it a form of DRM to employ - that is, preventing MITM - and
> as such, represent's a loss of user privilege. What if your favourite
> sites all required you to do this, or other forms of protection (such
> as hardware-attested token binding keys that reveal unique
> identifiers). While the idea is that token binding keys can be
> rotated, we've certainly seen sites, particularly video providers, use
> every available fingerprinting mechanism they can in order to restrict
> how and on which devices a user accesses a given service - I doubt we
> would want to see or encourage more of that.
> 
> I think it's important to consider the harmful effects that Token
> Binding will have, and not just the positive. And that's why it's
> worthwhile to keep it under consideration, rather than co

Re: Intent to implement and ship: FIDO U2F API

[Eric Rescorla]

On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin 
wrote:

> Hi,
>
> thanx for the answer.
>
> Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a
> few days ago on FIDO DEV forum):
>
> "the new spec that replaces ChannelID is called "Token Binding", and is in
> the process of being standardized by the IETF (
> https://datatracker.ietf.org/wg/tokbind/documents/).
>
> It turns out that as far as FIDO is concerned, a Token Binding key or a
> ChannelID key are really the same thing: it's a public key that will be
> included in the client data and signed by the Authenticator. So while
> you're correct in pointing out that it's a bit weird that FIDO should
> reference a non-standard, other than changing a few words here and there I
> don't expect any changes to the FIDO specs once the Token Binding drafts
> have become standards."
>
> Source :
> https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ
>

I'm not following how this is responsive to my point, which isn't about the
text
in FIDO but rather about what actually goes into Firefox. From that
perspective,
what Dirk says is correct, namely that the FIDO interface to Token Binding
and Channel ID are very similar. However, we have to implement one or the
other or both in TLS, and I don't see a lot of value in doing both.


I am still concerned about Mozilla Foundation deciding not to implement
> this protection inside Firefox for two main reasons.
>
> 1) From a security architect perspective. This is an official
> recommendation that makes sens to prevent MITM attacks. FIDO U2F was
> created to minimize/eliminate that kind of risk. This would rather be a
> more secure decision to fully implement the best options. (I am working for
> a FIDO U2F device manufacturer and that's what we did on our side).


I don't understand this point. The manufacturer doesn't implement token
binding:
it's in the browser stack.


2) Firefox users could be discriminated out of servers implementing this
> protection. Even if this is mostly/only the case on Google authentication
> servers now, this would already make a difference. I am not a Google fan
> boy -and I am working with other online services to integrate FIDO U2F
> technology- but protecting their services accounts is often what everyone
> is thinking about now when discussing FIDO U2F (protecting Gmail, Gdrive,
> Youtube, or whatever Google related accounts). Did you speak with Google
> team guys to know if they will let Firefox be compatible with their FIDO
> U2F second factor option even without ChannelID protection on the client
> side?


Well, I see Ryan Sleevi responded below, but no, I haven't validated this
one way
or the other with Google. With that said, I would be somewhat disappointed
if
Google required Token Binding with U2F, given that they don't require it
without
U2F. It's certainly not consistent with previous claims -- or the
underlying design
of FIDO -- to say that token binding is required for FOD to add value.



> (this would mean that they'll accept to lower their security to make it
> compatible to Mozilla/Firefox implementation...


Not really. See above.


They can decide that, even if questionable...)
>

Well, it's worth noting that while they are different mechanisms, U2F +
pinning offers
much of the MITM protection that Token Binding provides, and Firefox already
pins Google services.

-Ekr


--
> Fred
>
> On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> > On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir
> > wrote:
> >
> > > Hi,
> > >
> > > Great news about you making progress on this !
> > >
> > > Since I read here and there that you are working with Firefox & Chrome
> U2F
> > > support consistency in mind, what's your take on TLS Channel ID (Token
> > > Binding) support inside Firefox ?
> > >
> > > It is a recommended feature for FIDO U2F client (Firefox here) inside
> > > official specifications for additional protection against MITM
> attacks...
> > > and it is implemented on Google authentication servers (and on Chrome
> > > client side of course). I don't know if Google team will make it
> mandatory
> > > for non-Chrome browsers to be compatible with their own authentication
> > > servers but anyway, I think this is an important issue to be
> discussed...
> > >
> >
> > See:
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ
> >
> > We're not likely to implement Channel ID, but we probably will implement
> > Token Binding
> &g

Re: Intent to implement and ship: FIDO U2F API

[Ryan Sleevi]

On Mon, Feb 8, 2016 at 1:13 PM, Frederic Martin wrote:
>
> 1) From a security architect perspective. This is an official recommendation 
> that makes sens to prevent MITM attacks. FIDO U2F was created to 
> minimize/eliminate that kind of risk.

U2F itself addresses phishing. Token Binding (attempts) to address
MITM, but it's worth noting that they are separate problems with
separate solutions. U2F / FIDO are still able to handedly address the
former problem, without requiring treatment of the latter - it merely
establishes how they can be used cooperatively, but that's not
intrinsically necessary, nor necessarily wise.

> 2) Firefox users could be discriminated out of servers implementing this 
> protection.

Hopefully, you can likely recognize why this represents a very
troubling problem of Token Binding - it enables service providers
greater control to discriminate against users, reducing user freedom
and the role of the browser as the user's agent.

While I think there's no disagreement that 'hostile' MITM is bad,
there are plenty of cases where users intentionally and actively MITM
themselves, for purposes that range from 'clearly legitimate' to
'questionable, but it's the user's call". In the case of "clearly
legitimate", consider the work of security researchers and developers
who wish to MITM themselves or their applications, in order to
determine what data is leaking out. Any solution that actively
prohibits this can end up undermining user's security.

If you think this is academic, consider that many service providers
consider it a form of DRM to employ - that is, preventing MITM - and
as such, represent's a loss of user privilege. What if your favourite
sites all required you to do this, or other forms of protection (such
as hardware-attested token binding keys that reveal unique
identifiers). While the idea is that token binding keys can be
rotated, we've certainly seen sites, particularly video providers, use
every available fingerprinting mechanism they can in order to restrict
how and on which devices a user accesses a given service - I doubt we
would want to see or encourage more of that.

I think it's important to consider the harmful effects that Token
Binding will have, and not just the positive. And that's why it's
worthwhile to keep it under consideration, rather than commit. It is
truly unfortunate that Chrome decided to launch this feature, without
public discussion or review, and without concern for the implications
of the ecosystem such as the one you raise - providers like Google
using it to block out other browsers.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

Hi,

thanx for the answer.

Quoting Dirk Balfanz (one of the TLS Channel ID specifications author, a few 
days ago on FIDO DEV forum):

"the new spec that replaces ChannelID is called "Token Binding", and is in the 
process of being standardized by the IETF 
(https://datatracker.ietf.org/wg/tokbind/documents/).

It turns out that as far as FIDO is concerned, a Token Binding key or a 
ChannelID key are really the same thing: it's a public key that will be 
included in the client data and signed by the Authenticator. So while you're 
correct in pointing out that it's a bit weird that FIDO should reference a 
non-standard, other than changing a few words here and there I don't expect any 
changes to the FIDO specs once the Token Binding drafts have become standards."

Source : 
https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/hn_T6pKS0wU/aEO29oIeEAAJ

I am still concerned about Mozilla Foundation deciding not to implement this 
protection inside Firefox for two main reasons.

1) From a security architect perspective. This is an official recommendation 
that makes sens to prevent MITM attacks. FIDO U2F was created to 
minimize/eliminate that kind of risk. This would rather be a more secure 
decision to fully implement the best options. (I am working for a FIDO U2F 
device manufacturer and that's what we did on our side). I know this protection 
could sound like a oh-not-again-Google initiative, but it is rather efficient 
and it is not very complex to implement (it is mostly about returning a TLS 
related Channel ID public key used by the browser to communicate with the 
server...) and is very close of future "Token Binding" thing.

2) Firefox users could be discriminated out of servers implementing this 
protection. Even if this is mostly/only the case on Google authentication 
servers now, this would already make a difference. I am not a Google fan boy 
-and I am working with other online services to integrate FIDO U2F technology- 
but protecting their services accounts is often what everyone is thinking about 
now when discussing FIDO U2F (protecting Gmail, Gdrive, Youtube, or whatever 
Google related accounts). Did you speak with Google team guys to know if they 
will let Firefox be compatible with their FIDO U2F second factor option even 
without ChannelID protection on the client side? (this would mean that they'll 
accept to lower their security to make it compatible to Mozilla/Firefox 
implementation... They can decide that, even if questionable...)

Regards
--
Fred

On Monday, February 8, 2016 at 5:28:37 PM UTC+1, Eric Rescorla wrote:
> On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir 
> wrote:
> 
> > Hi,
> >
> > Great news about you making progress on this !
> >
> > Since I read here and there that you are working with Firefox & Chrome U2F
> > support consistency in mind, what's your take on TLS Channel ID (Token
> > Binding) support inside Firefox ?
> >
> > It is a recommended feature for FIDO U2F client (Firefox here) inside
> > official specifications for additional protection against MITM attacks...
> > and it is implemented on Google authentication servers (and on Chrome
> > client side of course). I don't know if Google team will make it mandatory
> > for non-Chrome browsers to be compatible with their own authentication
> > servers but anyway, I think this is an important issue to be discussed...
> >
> 
> See:
> https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ
> 
> We're not likely to implement Channel ID, but we probably will implement
> Token Binding
> when it seems sufficiently stable
> 
> -Ekr
> 
> 
> 
> >
> > ...and my personal point: we need this :)
> >
> > On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:
> >
> > > All,
> > >
> > > We're making progress on implementing FIDO U2F in Firefox. The effort is
> > > split into a number of bugs at present. First, a quick rundown of where
> > we
> > > are:
> > >
> > > * The tracking bug for U2F support is Bug 1065729.
> > > * Bug 1198330 is to implement USB HID support in Firefox.
> > > * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> > > bug's code is in review.
> > > * Bug 1244959 completes the AppId/FacetId algorithm.
> > > * Bug 1245527 implements the state machines (USBToken) between the JS API
> > > and the USB HID support.
> > > * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> > > integration and developer testing.
> > >
> > > A couple of notes/clarifications about how we're planning to build U2F
> > > support:
> > >

Re: Intent to implement and ship: FIDO U2F API

[Eric Rescorla]

On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir 
wrote:

> Hi,
>
> Great news about you making progress on this !
>
> Since I read here and there that you are working with Firefox & Chrome U2F
> support consistency in mind, what's your take on TLS Channel ID (Token
> Binding) support inside Firefox ?
>
> It is a recommended feature for FIDO U2F client (Firefox here) inside
> official specifications for additional protection against MITM attacks...
> and it is implemented on Google authentication servers (and on Chrome
> client side of course). I don't know if Google team will make it mandatory
> for non-Chrome browsers to be compatible with their own authentication
> servers but anyway, I think this is an important issue to be discussed...
>

See:
https://groups.google.com/d/msg/mozilla.dev.platform/IVGEJnQW3Uo/o9WzWgEqCwAJ

We're not likely to implement Channel ID, but we probably will implement
Token Binding
when it seems sufficiently stable

-Ekr



>
> ...and my personal point: we need this :)
>
> On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:
>
> > All,
> >
> > We're making progress on implementing FIDO U2F in Firefox. The effort is
> > split into a number of bugs at present. First, a quick rundown of where
> we
> > are:
> >
> > * The tracking bug for U2F support is Bug 1065729.
> > * Bug 1198330 is to implement USB HID support in Firefox.
> > * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> > bug’s code is in review.
> > * Bug 1244959 completes the AppId/FacetId algorithm.
> > * Bug 1245527 implements the state machines (USBToken) between the JS API
> > and the USB HID support.
> > * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> > integration and developer testing.
> >
> > A couple of notes/clarifications about how we’re planning to build U2F
> > support:
> >
> > * The `window.u2f` API endpoint will only be available to code loaded
> from
> > secure origins, in keeping with our policy for new features [1]. (This is
> > also consistent with U2F support that is built into recent versions of
> > Google Chrome.)
> > * We are implementing the high-level JavaScript API version 1.1. The
> > specification for v1.1 is not yet published, but is already implemented
> in
> > recent versions of Chromium [2].
> > * For the time being, U2F support will be gated behind preferences and
> > disabled by default.
> >
> > [1]
> >
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> > [2]
> >
> https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js
> >
> > - J.C.
> >
> >
> > On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin <
> fredletaman...@gmail.com
> > > wrote:
> >
> >> <http://w3c.github.io/websec/web-authentication-charter>Nearly two
> >> months since that post...
> >> Any news on this ?
> >>
> >> a) on Mozilla Foundation joining FIDO Alliance?
> >> b) on FIDO U2F implementation inside Firefox Core?
> >>
> >> Thanx.
> >> ___
> >> 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Fred Le Tamanoir]

Hi,

Great news about you making progress on this !

Since I read here and there that you are working with Firefox & Chrome U2F
support consistency in mind, what's your take on TLS Channel ID (Token
Binding) support inside Firefox ?

It is a recommended feature for FIDO U2F client (Firefox here) inside
official specifications for additional protection against MITM attacks...
and it is implemented on Google authentication servers (and on Chrome
client side of course). I don't know if Google team will make it mandatory
for non-Chrome browsers to be compatible with their own authentication
servers but anyway, I think this is an important issue to be discussed...

...and my personal point: we need this :)

On Thu, Feb 4, 2016 at 10:49 PM, J.C. Jones  wrote:

> All,
>
> We're making progress on implementing FIDO U2F in Firefox. The effort is
> split into a number of bugs at present. First, a quick rundown of where we
> are:
>
> * The tracking bug for U2F support is Bug 1065729.
> * Bug 1198330 is to implement USB HID support in Firefox.
> * Bug 1231681 implements the WebIDL and the outline of the JS API. This
> bug’s code is in review.
> * Bug 1244959 completes the AppId/FacetId algorithm.
> * Bug 1245527 implements the state machines (USBToken) between the JS API
> and the USB HID support.
> * Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
> integration and developer testing.
>
> A couple of notes/clarifications about how we’re planning to build U2F
> support:
>
> * The `window.u2f` API endpoint will only be available to code loaded from
> secure origins, in keeping with our policy for new features [1]. (This is
> also consistent with U2F support that is built into recent versions of
> Google Chrome.)
> * We are implementing the high-level JavaScript API version 1.1. The
> specification for v1.1 is not yet published, but is already implemented in
> recent versions of Chromium [2].
> * For the time being, U2F support will be gated behind preferences and
> disabled by default.
>
> [1]
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> [2]
> https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js
>
> - J.C.
>
>
> On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin  > wrote:
>
>> <http://w3c.github.io/websec/web-authentication-charter>Nearly two
>> months since that post...
>> Any news on this ?
>>
>> a) on Mozilla Foundation joining FIDO Alliance?
>> b) on FIDO U2F implementation inside Firefox Core?
>>
>> Thanx.
>> ___
>> 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 implement and ship: FIDO U2F API

[J.C. Jones]

All,

We're making progress on implementing FIDO U2F in Firefox. The effort is
split into a number of bugs at present. First, a quick rundown of where we
are:

* The tracking bug for U2F support is Bug 1065729.
* Bug 1198330 is to implement USB HID support in Firefox.
* Bug 1231681 implements the WebIDL and the outline of the JS API. This
bug’s code is in review.
* Bug 1244959 completes the AppId/FacetId algorithm.
* Bug 1245527 implements the state machines (USBToken) between the JS API
and the USB HID support.
* Bug 1244960 expands an NSS-based U2F token (NSSToken) for expanded
integration and developer testing.

A couple of notes/clarifications about how we’re planning to build U2F
support:

* The `window.u2f` API endpoint will only be available to code loaded from
secure origins, in keeping with our policy for new features [1]. (This is
also consistent with U2F support that is built into recent versions of
Google Chrome.)
* We are implementing the high-level JavaScript API version 1.1. The
specification for v1.1 is not yet published, but is already implemented in
recent versions of Chromium [2].
* For the time being, U2F support will be gated behind preferences and
disabled by default.

[1]
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
[2]
https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/resources/cryptotoken/webrequest.js

- J.C.


On Wed, Jan 27, 2016 at 2:44 AM, Frederic Martin 
wrote:

> <http://w3c.github.io/websec/web-authentication-charter>Nearly two months
> since that post...
> Any news on this ?
>
> a) on Mozilla Foundation joining FIDO Alliance?
> b) on FIDO U2F implementation inside Firefox Core?
>
> Thanx.
> ___
> 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 implement and ship: FIDO U2F API

[Frederic Martin]

On Wednesday, December 2, 2015 at 2:23:28 AM UTC+1, Richard Barnes wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1].  Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
> Work has begun in the W3C to create open standards using FIDO as a starting
> point. We are proposing to implement the FIDO U2F API in Firefox in its
> current form and then track the evolving W3C standard.
> 
> Background: The FIDO Alliance has been developing a standard for
> hardware-based user authentication known as "Universal Two-Factor" or U2F
> [2].  This standard allows a website to verify that a user is in possession
> of a specific device by having the device sign a challenge with a private
> key that is held on the hardware device.  The browser's role is mainly (1)
> to route messages between the website and the token, and (2) to add the
> origin of the website to the message signed by the token (so that the
> signature is bound to the site).
> 
> Several major websites now support U2F for authentication, including Google
> [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> for U2F support in Gecko [6].  The W3C has  begun the process of forming a
> "WebAuthentication" working group that will work on a standard for enhanced
> authentication using FIDO as a starting point [7].
> 
> Proposed: To implement the high-level U2F API described in the FIDO JS API
> specification, with support for the USB HID token interface.
> 
> Please send comments on this proposal to the list no later than Monday,
> December 14, 2015.
> 
> -
> 
> Personally, I have some reservations about implementing this, but I still
> think it's worth doing, given the clear need for something to augment
> passwords.
> 
> It's unfortunate that the initial FIDO standards were developed in a closed
> group, but there is good momentum building toward making FIDO more open.  I
> have some specific concerns about the U2F API itself, but they're
> relatively minor.  For example, the whole system is highly vertically
> integrated, so if we want to change any part of it (e.g., to use a curve
> other than P-256 for signatures), we'll need to build a whole new API.  But
> these are issues that can be addressed in the W3C process.
> 
> We will continue to work on making standards for secure authentication more
> open.  In the meantime, U2F is what's here now, and there's demonstrated
> developer interest, so it makes sense for us to work on implementing it.
> 
> Thanks,
> --Richard
> 
> [1] https://fidoalliance.org/
> [2] https://fidoalliance.org/specifications/download/
> [3] https://support.google.com/accounts/answer/6103523?hl=en
> [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> [5]
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> [7] http://w3c.github.io/websec/web-authentication-charter

Nearly two months since that post...
Any news on this ?

a) on Mozilla Foundation joining FIDO Alliance?
b) on FIDO U2F implementation inside Firefox Core?

Thanx.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[hillbrad]

I'm no longer directly involved with the FIDO Alliance, so I can't speak to the 
FIDO 2.0 timelines, but my general experience there plus at the W3C tells me 
that it will some time before the new APIs stabilize.  I hope that this won't 
dissuade Mozilla from beginning work on implementing U2F more-or-less 
immediately.

1) Much of the work involved is in building the USB transports (the crypto is 
rather simple) and that code will likely be highly reusable for 2.0 APIs.

2) There is a growing set of services adopting U2F today, a robust and 
competitive market for the hardware, and Firefox support would be a important 
contributor to "critical mass" for the FIDO approach, regardless of the 
particular version.  A privacy-friendly, strong and origin-bound authentication 
mechanism, based on open protocols, with hardware chosen by the user, seems to 
fit very well within the general values and vision of Mozilla.  I think it is 
valuable to give it momentum at a time when alternative approaches that don't 
respect user privacy or the web security model in the same way are being 
heavily pushed.

3) I think it would be OK to leave out Channel ID support as the approach is 
clearly being deprecated and it represents only a tiny fraction of the value 
provided by U2F.

cheers,

Brad Hill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[smaug]

On 12/04/2015 06:56 PM, smaug wrote:

Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api

"provide a namespace object u2f of the following interface" doesn't mean 
anything, so either there is supposed to be an instance of u2f interface
somewhere (in Window object?), but feels odd to expose interface called u2f and 
having u2f as a property of Window.
Perhaps the idea there is that the interface has only static methods?
Then register() and sign() should be marked as static and there wouldn't be an 
instance of u2f, but one would just call those static methods
on the u2f interface.



But whether that is compatible with Chrome - no idea.





(Nit, the convention is that interfaces start with a capital letter. For some 
odd reason 'u2f' doesn't follow that.)



-Olli



On 12/02/2015 11:20 PM, smaug wrote:

On 12/02/2015 03:23 AM, Richard Barnes wrote:

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.


As I said in the other email,
I don't understand how this could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is 
made available to RP web pages, as this is (for now) implementation and
browser dependent. "





Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter







___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[smaug]

Looks like the spec could be made implementable by fixing
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html#high-level-javascript-api

"provide a namespace object u2f of the following interface" doesn't mean 
anything, so either there is supposed to be an instance of u2f interface
somewhere (in Window object?), but feels odd to expose interface called u2f and 
having u2f as a property of Window.
Perhaps the idea there is that the interface has only static methods?
Then register() and sign() should be marked as static and there wouldn't be an 
instance of u2f, but one would just call those static methods
on the u2f interface.



(Nit, the convention is that interfaces start with a capital letter. For some 
odd reason 'u2f' doesn't follow that.)



-Olli



On 12/02/2015 11:20 PM, smaug wrote:

On 12/02/2015 03:23 AM, Richard Barnes wrote:

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.


As I said in the other email,
I don't understand how this could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is 
made available to RP web pages, as this is (for now) implementation and
browser dependent. "





Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[smaug]

On 12/02/2015 11:37 PM, Frederic Martin wrote:

As I said in the other email,
I don't understand how this could be implemented when the spec has left the 
>key piece undefined, as far as I see.


You are completely right ! For now, FIDO 2 is currently being written (far far 
far from finished) and can't be implemented, so let's focus on existing 
solutions with existing specifications and existing products (the ones that 
work with google/gmail, github, dropbox and many federated identity portals.

FIDO U2F specifications are complete for USB/HID devices & desktop browsers.


Can you show me how a web page gets access to some API entry point? I haven't 
seen any spec defining how
the relevant MessagePort or some u2f object can be accessed.
To me the spec looks very much incomplete, in the sense that based on it one 
can't create
interoperable implementations.


-Olli




Additional information (copy/paste from a previous post of mine above
with small updates):

- FIDO 2.0 will not replace FIDO U2F
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be)
- FIDO U2F is already here and here to stay. It is a great WORKING
   solution: a secure second factor for strong web authentication
   through a simple HID based API.
- There is already plenty of FIDO U2F related source code available
   to help people building great solutions (Chromium client source code,
   Google JS library source code and different Java/PHP/Go/etc. server code)
- Nearly all FIDO U2F products have really secure architectures
   (i.e. nearly every products are using secure elements / smart cards
   components, even if not mandatory, that's great)
- FIDO U2F over NFC and BLE specifications are currently being
   finalized, so there will be flexibility to cover mobile platforms.
- FIDO 2.0 W3c submission have no real details regarding technical
   implementation because FIDO 2 is only for now a very confusing draft
   with strange (*cough*) directions, so do not put too many hopes
   into FIDO 2.0 (that's really not important for now)

=> So let's focus on U2F :)



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

Le jeudi 3 décembre 2015 01:28:51 UTC+1, Justin Dolske a écrit :
> On 12/2/15 6:48 AM, Richard Barnes wrote:
> 
> > My initial intent was to propose implementing [1], then implementing [2]
> > when it's ready.  After all, there's a lot in common, and as you say, >the 
> > W3C version will be much nicer.
> 
> This seems like like a strange path to take. Why implement both?

(already discussed but let's summarize)

There are plenty of existing U2F source code, online services and hardware 
products already available for U2F, unluckily only support by Chrome for now. 
U2F specifications are finalized. Nobody knows when FIDO2 will be ready. FIDO2 
is a different approach and will not be compatible with U2F. It doesn't mean 
FIDO U2F support will be dropped (they can completely coexist). U2F reaches its 
goal as a great secure simple second factor. Please read specifications, it is 
nice and simple. It works. Great. Already.

>  From elsewhere in the thread, it sounds like v.1 is basically importing 
> a defacto-standard (?), in which case I'd wonder how realistic is it to 
> implement a different version later and actually get sites to switch to >it.
> 
> I'd also wonder just how far off v.2 is... It is something that's likely 
> to get to a final spec in a reasonable timeframe (and should we just 
> wait for that), or is it so far off in la-la land that it's not actually 
> likely to ever be implemented by anyone? Somewhere in between?
> 
> Would the v.1 implementation be deprecated by the v.2 implementation, or 
> do both need to be carried around forever?

So nobody knows when it will be ready. It will, for sure. That's all. It won't 
make U2F deprecated. U2F use case is not even cover by FIDO2. FIDO U2F and 
FIDO2 can nicely coexist. Let's not wait please and deal with existing products 
and services. :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

> That said, I think we're in violent agreement that the specs are far, far, 
> far from finished - and I'm unclear whether we're in agreement that one is 
> under active development, while the other is a technological dead end which, 
> through a series of unfortunate events, happened to have been launched beyond 
> the scope of a few limited sites.

Oh believe me, U2F is not ready to die. 
U2F is a great second factor solution, whatever ongoing FIDO 2 discussion.

> > Are you following the Fido Alliance on going work? 
> 
> To an extent my sanity permits, yes.
> 
> > Please focus on existing full specifications with existing services and 
> > products : FIDO U2F.
> 
> The problem is that U2F represents a dead-end of sorts. It, along with FIDO 
> UAF, tried to provision high-level APIs for two very disjoint use cases. The 
> FIDO 2.0 work tries to embrace the extensiblewebmanifesto portion by 
> providing the common low-level primitives shared by UAF/U2F, so that 
> appropriate high level APIs can be built atop the low-level communication 
> mechanism.

Perhaps when FIDO 2 will be reality, and it is far from being a reality, this 
discussion will make more sens. Why discouraging existing services and products 
support ? Perhaps FIDO U2F won't evolve a lot but it serves a purpose and 
reached its goal. FIDO 2 is also a very disjoint branch from UAF and U2F, and 
it seems to follow a strange way by promoting smartphone based application, 
marginalizing again the use of secure elements, unknown pairing, and so on... 
There are now many existing FIDO U2F solutions that are pushing for FIDO based 
solutions. Let's welcome Mozilla inside the Alliance and let Mozilla deal with 
existing actors, please... (insert a begging smiley here).


> Yes, there are sites that support and use the U2F high-level API, and yes, 
> unfortunately Chrome ships a built-in extension that is automatically granted 
> sufficient privileges to polyfill that high-level API atop our 
> (extension-only) USB HID API, allowing the extension to inject into sites and 
> transparently add support 'as if' it was implemented through the standard 
> Chrome feature process, but unfortunately bypassing it, and thus suffering 
> many of the known issues with implementing and shipping specs before 
> consensus - such as ossification due to premature deployment.
> 
> However, the U2F API inherently is something that will be replaced in the 
> future - it will presumably be supplanted with the FIDO 2.0 API low-level 
> primitives, for which there can then be 'many' high-level polyfill APIs 
> implemented through support libraries independent of the UA, perhaps 'some' 
> of which will be standardized, as such extensiblewebmanifesto-y things go.

Wow, I won't follow you on this path :) If Google had strange ways to reach the 
goal, now it is working, and no, FIDO2 will not replace U2F. The second factor 
(authent after user+pass) is not even a part of FIDO 2. And compatibility is 
not even discussed. So if Mozilla waits (for an unknown period of time) and 
implements FIDO 2 (that will have its problems too...), this won't help people 
with their FIDO U2F based products and services.

> This was captured by threads like 
> https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/zvS9BM8HXLQ/4GmJaSTTSN4J
>  and such.

I know, I am the same Fred there :)

> I think we'd also all agree that supporting a "U2F 1.0 API, U2F 1.1 API, UAF 
> 1.0 API, and FIDO 2.0 API" all within a browser is also... non-ideal. That's 
> why I was trying to get clarification about both the short- and long-term 
> commitments of the Firefox folks, while we try to get things clarified on the 
> Chrome side.

Thanx for all the information, I hope you'll understand that we just want to 
enjoy the Mozilla announcement to support FIDO, please let them cover U2F. I 
don't see any kind of problem for them to cover FIDO 2 later when available and 
even support them side by side.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Justin Dolske]

On 12/2/15 6:48 AM, Richard Barnes wrote:


My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.


This seems like like a strange path to take. Why implement both?

From elsewhere in the thread, it sounds like v.1 is basically importing 
a defacto-standard (?), in which case I'd wonder how realistic is it to 
implement a different version later and actually get sites to switch to it.


I'd also wonder just how far off v.2 is... It is something that's likely 
to get to a final spec in a reasonable timeframe (and should we just 
wait for that), or is it so far off in la-la land that it's not actually 
likely to ever be implemented by anyone? Somewhere in between?


Would the v.1 implementation be deprecated by the v.2 implementation, or 
do both need to be carried around forever?


Justin
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Ryan Sleevi]

On Wednesday, December 2, 2015 at 3:08:44 PM UTC-8, Frederic Martin wrote:
> Sorry, but I don't understand why you are denying the evidence, anyone 
> at Fido alliance will confirm that even non-public FIDO 2 drafts are far
> far far from finished. Regarding the glimpse that was published in W3c 
> website, this is even more flagrant.

So, apologies that I misunderstood your bone of contention with the 2.0 part, 
which Boris clarified.

That said, I think we're in violent agreement that the specs are far, far, far 
from finished - and I'm unclear whether we're in agreement that one is under 
active development, while the other is a technological dead end which, through 
a series of unfortunate events, happened to have been launched beyond the scope 
of a few limited sites.

> Are you following the Fido Alliance on going work? there are tons of 
> things that are currently discussed without even an agenda. And I don't even 
> speak about the authenticator side, there is no information/specifications at 
> all for that.

To an extent my sanity permits, yes.

> Please focus on existing full specifications with existing services and 
> products : FIDO U2F.

The problem is that U2F represents a dead-end of sorts. It, along with FIDO 
UAF, tried to provision high-level APIs for two very disjoint use cases. The 
FIDO 2.0 work tries to embrace the extensiblewebmanifesto portion by providing 
the common low-level primitives shared by UAF/U2F, so that appropriate high 
level APIs can be built atop the low-level communication mechanism.

Yes, there are sites that support and use the U2F high-level API, and yes, 
unfortunately Chrome ships a built-in extension that is automatically granted 
sufficient privileges to polyfill that high-level API atop our (extension-only) 
USB HID API, allowing the extension to inject into sites and transparently add 
support 'as if' it was implemented through the standard Chrome feature process, 
but unfortunately bypassing it, and thus suffering many of the known issues 
with implementing and shipping specs before consensus - such as ossification 
due to premature deployment.

However, the U2F API inherently is something that will be replaced in the 
future - it will presumably be supplanted with the FIDO 2.0 API low-level 
primitives, for which there can then be 'many' high-level polyfill APIs 
implemented through support libraries independent of the UA, perhaps 'some' of 
which will be standardized, as such extensiblewebmanifesto-y things go.

This was captured by threads like 
https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/zvS9BM8HXLQ/4GmJaSTTSN4J
 and such.

I think we'd also all agree that supporting a "U2F 1.0 API, U2F 1.1 API, UAF 
1.0 API, and FIDO 2.0 API" all within a browser is also... non-ideal. That's 
why I was trying to get clarification about both the short- and long-term 
commitments of the Firefox folks, while we try to get things clarified on the 
Chrome side.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

Le mercredi 2 décembre 2015 23:43:00 UTC+1, Ryan Sleevi a écrit :
> On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> > I don't understand how 1) could be implemented when the spec has left the 
> > key piece undefined, as far as I see.
> > As the spec puts it "This specification does not describe how such a port 
> > is made available to RP web pages, as this is (for now) implementation and 
> > browser dependent. "
> 
> Um, that's fairly standard for specs.
> 
> The spec defines the interface, as well as the observable behaviours
> of that interface. How that interface is implemented is up to the UA.
> 
> For example, Chrome "implements" the interface by allowing extensions
> to inject JS into pages, and allowing said JS to communicate back to
> the extension ( see https://developer.chrome.com/extensions/messaging
> ). A future, 'native' implementation in Chrome could, rather than
> using extension, directly expose the IDL via the navigator interface,
> which then exposes a JS MessagePort that fulfills the contract.
> 
> The text you cite is by no means proof of an 'incomplete' spec -
> rather, it's standard spec sauce, the same way that, say, WebGL
> doesn't say "You must use NVidia driver 3.0 or later, and only on
> Intel machines" - it says "This is the API of WebGL - you can
> implement it however you wish, so long as you abide by this contract"

Sorry, but I don't understand why you are denying the evidence, anyone 
at Fido alliance will confirm that even non-public FIDO 2 drafts are far
far far from finished. Regarding the glimpse that was published in W3c website, 
this is even more flagrant.

Are you following the Fido Alliance on going work? there are tons of 
things that are currently discussed without even an agenda. And I don't even 
speak about the authenticator side, there is no information/specifications at 
all for that.

Please focus on existing full specifications with existing services and 
products : FIDO U2F.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F APIU

[Boris Zbarsky]

On 12/2/15 5:42 PM, Ryan Sleevi wrote:

On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:

I don't understand how 1) could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is 
made available to RP web pages, as this is (for now) implementation and
browser dependent. "


Um, that's fairly standard for specs.


It's not standard for web specs, in the sense that web specs aim to have 
interoperable behavior in terms of what's exposed to pages.


That means not just defining how objects behave once you have your hands 
on them but also defining how to get your hands on them.  The 
alternative is things like when pages were creating XMLHttpRequest 
objects via constructors in some browsers and ActiveX gunk in others: no 
one is happy with that.


Now I know you know all this, so I'm assuming you simply misunderstood 
Olli's objection... but if that's not what's going on, I would like to 
understand what your line of reasoning is here.



The spec defines the interface, as well as the observable behaviours
of that interface. How that interface is implemented is up to the UA.


The "interface" for a typical web spec includes "how do I, as a web 
author, get the objects this spec is defining".



For example, Chrome "implements" the interface by allowing extensions
to inject JS into pages, and allowing said JS to communicate back to
the extension ( see https://developer.chrome.com/extensions/messaging
). A future, 'native' implementation in Chrome could, rather than
using extension, directly expose the IDL via the navigator interface,
which then exposes a JS MessagePort that fulfills the contract.


Here's my question.  From the point of view of a web author, do these 
look like the same interface?  That is, are injections adding members to 
navigator?



The text you cite is by no means proof of an 'incomplete' spec


It sure sounds like it is to me.


rather, it's standard spec sauce, the same way that, say, WebGL
doesn't say "You must use NVidia driver 3.0 or later, and only on
Intel machines" - it says "This is the API of WebGL - you can
implement it however you wish, so long as you abide by this contract"


The API of WebGL also says that the way you get hold of a 
WebGLRenderingContext is via a getContext() call on an 
HTMLCanvasElement, with certain arguments.  Without that part, the WebGL 
spec would in fact be "incomplete".


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Ryan Sleevi]

On Wednesday, December 2, 2015 at 1:17:46 PM UTC-8, smaug wrote:
> I don't understand how 1) could be implemented when the spec has left the key 
> piece undefined, as far as I see.
> As the spec puts it "This specification does not describe how such a port is 
> made available to RP web pages, as this is (for now) implementation and 
> browser dependent. "

Um, that's fairly standard for specs.

The spec defines the interface, as well as the observable behaviours
of that interface. How that interface is implemented is up to the UA.

For example, Chrome "implements" the interface by allowing extensions
to inject JS into pages, and allowing said JS to communicate back to
the extension ( see https://developer.chrome.com/extensions/messaging
). A future, 'native' implementation in Chrome could, rather than
using extension, directly expose the IDL via the navigator interface,
which then exposes a JS MessagePort that fulfills the contract.

The text you cite is by no means proof of an 'incomplete' spec -
rather, it's standard spec sauce, the same way that, say, WebGL
doesn't say "You must use NVidia driver 3.0 or later, and only on
Intel machines" - it says "This is the API of WebGL - you can
implement it however you wish, so long as you abide by this contract"
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Eric Rescorla]

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin 
wrote:

> > > There are probably other questions Mozilla Core Team should ask to
> > > themselves :
> > >
> > > - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> > > (This allows web services to communicate with HID devices - i.e.
> > > that's how some cryptocurrencies hardware wallets are using HID
> > > Chrome interface)
> > >
> >
> > Are you thinking of something like WebUSB?
> > (https://reillyeon.github.io/webusb/)? This is something we've looked at
> > a bit but we're still trying to wrap our heads around the security
> > implications.
>
> No. I am thinking about something like:
> https://developer.chrome.com/apps/hid
> but that's outside the pure FIDO U2F scope: it is a reminder that Chrome
> already allows wep pages/JS to communicate with HID non-U2F device and
> that Mozilla will have to chose on their side if the HID API will be
> restricted to U2F usage or not.


I believe the plan is to have that be the case for now.


>
> > - Have TLS Channel ID Binding support. (Oh, this is really important)
> > > When you'll check FIDO U2F specifications, you'll see that TLS Channel
> > > ID Binding is an important part of the security against attacks like
> > > SSL Proxy and similar MITM attacks. This part is not mandatory. But
> > > Google servers are using this and Chrome supports it. So... please
> > > REALLY consider implementing it: it will bring higher security and
> > > probably will give a chance too in the future to be accepted as a
> > > supported browser on Google servers (I am not from Google so I can't
> > > speak on their behalf but this should be a rational requirements
> there).
> > > This is the only way to provide a full anti-phishing solution.
> > >
> >
> > My understanding is that Channel ID is being superseded by token binding
> > (https://datatracker.ietf.org/wg/tokbind/charter/), so if we do
> > something in this area, it's more likely we would do token binding
> > than channel ID,
> > I expect.
>
> Hi, I don't think this is exactly something that you can freely chose...
> As you read FIDO U2F specifications, you'll see that added security is
> provided by TLS channel binding.
>
> Search "Channel Binding" inside
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-glossary.html
> and again here
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html


I know what Channel Bindings are, but they're different from Channel ID
(though Channel ID *uses* Channel Bindings). But as I said, Channel ID
is Google-specific sauce. The IETF token binding working group
(https://datatracker.ietf.org/wg/tokbind/charter/) is standardizing the
next generation of this technology. Given that, my instinct is to wait
for the standard.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

>As I said in the other email, 
>I don't understand how this could be implemented when the spec has left the 
>>key piece undefined, as far as I see. 

You are completely right ! For now, FIDO 2 is currently being written (far far 
far from finished) and can't be implemented, so let's focus on existing 
solutions with existing specifications and existing products (the ones that 
work with google/gmail, github, dropbox and many federated identity portals. 

FIDO U2F specifications are complete for USB/HID devices & desktop browsers. 

Additional information (copy/paste from a previous post of mine above
with small updates):

- FIDO 2.0 will not replace FIDO U2F 
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0 
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be) 
- FIDO U2F is already here and here to stay. It is a great WORKING 
  solution: a secure second factor for strong web authentication 
  through a simple HID based API. 
- There is already plenty of FIDO U2F related source code available 
  to help people building great solutions (Chromium client source code, 
  Google JS library source code and different Java/PHP/Go/etc. server code) 
- Nearly all FIDO U2F products have really secure architectures 
  (i.e. nearly every products are using secure elements / smart cards 
  components, even if not mandatory, that's great) 
- FIDO U2F over NFC and BLE specifications are currently being 
  finalized, so there will be flexibility to cover mobile platforms. 
- FIDO 2.0 W3c submission have no real details regarding technical 
  implementation because FIDO 2 is only for now a very confusing draft 
  with strange (*cough*) directions, so do not put too many hopes 
  into FIDO 2.0 (that's really not important for now) 

=> So let's focus on U2F :)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Frederic Martin]

Le lundi 9 novembre 2015 18:29:20 UTC+1, Michael Schwartz (m...@gluu.org) a 
écrit :
> Hi guys... if you need a FIDO U2F server to test against, the Gluu Server has 
> endpoints built in. Its really easy to deploy on Ubuntu / Centos: 
> http://www.gluu.org/docs/admin-guide/deployment/
> 
> Also, I recorded a geeky video on how to test FIDO U2F: 
> http://gluu.co/fido-u2f
> 
> Basically, check enable, change the default authn mechanism... and you're 
> done. Its really easy.
> 
> - Mike

Hi, you did an amazing work with Gluu (insert bowing smiley here).

FIDO U2F kind of recommends to use TLS Channel binding as a protection against 
SSL proxy and other MITM attacks. Chrome FIDO U2F client part is compatible 
with this but it can only be used if the server side is implemented, do Gluu 
support that ?

Search "Channel Binding" inside 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-glossary.html
 
and again here 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html
 

That's a great -nearly perfect- existing solution, and IMHO Firefox should 
probably implement this feature too for better security and for better 
compatibility with servers that are implementing the server side (like google 
servers). 

http://tools.ietf.org/html/draft-balfanz-tls-channelid-01 
http://www.ietf.org/rfc/rfc5056.txt 
http://www.ietf.org/rfc/rfc5929.txt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[smaug]

On 12/02/2015 03:23 AM, Richard Barnes wrote:

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.


As I said in the other email,
I don't understand how this could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and 
browser dependent. "






Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[smaug]

On 12/02/2015 07:25 AM, ryan.sle...@gmail.com wrote:

On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:

Oh well. Bummer.

/ Jonas


If it cheers you up any, the 2.0 API that replaces the U2F API uses promises - 
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that Firefox 
implement the 'old and deprecated' U2F API [1], or the 'fresh and new
and hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped this for 
google.com, and only for HTTPS, and that we were committed to the
W3C member submission as the path forward, but as I was working to back up a 
citation to this, I found out that we submarine-launched the API in
Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to Implement / 
Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that Chrome put Firefox in this 
position of "old and busted" and "new hotness",
with "damned either way" as the result. I'm trying to find out more about this, 
as well as Chrome and Chromium's future commitments regarding this
API.

That said, knowing full well that the FIDO Alliance intends the W3C member 
submission to the path forward, could you provide greater clarity: 1)
What it is you intend to implement? 2) If you intend to implement [1], whether 
or not you'll unship that if/as/when [2] progresses?

I don't understand how 1) could be implemented when the spec has left the key 
piece undefined, as far as I see.
As the spec puts it "This specification does not describe how such a port is made available to RP web pages, as this is (for now) implementation and 
browser dependent. "





[1] 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
 [2]
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/ [3]
https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederic Martin]

> > There are probably other questions Mozilla Core Team should ask to
> > themselves :
> >
> > - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> > (This allows web services to communicate with HID devices - i.e.
> > that's how some cryptocurrencies hardware wallets are using HID
> > Chrome interface)
> >
> 
> Are you thinking of something like WebUSB?
> (https://reillyeon.github.io/webusb/)? This is something we've looked at
> a bit but we're still trying to wrap our heads around the security
> implications.

No. I am thinking about something like:
https://developer.chrome.com/apps/hid
but that's outside the pure FIDO U2F scope: it is a reminder that Chrome 
already allows wep pages/JS to communicate with HID non-U2F device and 
that Mozilla will have to chose on their side if the HID API will be 
restricted to U2F usage or not. 

> - Have TLS Channel ID Binding support. (Oh, this is really important)
> > When you'll check FIDO U2F specifications, you'll see that TLS Channel
> > ID Binding is an important part of the security against attacks like
> > SSL Proxy and similar MITM attacks. This part is not mandatory. But
> > Google servers are using this and Chrome supports it. So... please
> > REALLY consider implementing it: it will bring higher security and
> > probably will give a chance too in the future to be accepted as a
> > supported browser on Google servers (I am not from Google so I can't
> > speak on their behalf but this should be a rational requirements there).
> > This is the only way to provide a full anti-phishing solution.
> >
> 
> My understanding is that Channel ID is being superseded by token binding
> (https://datatracker.ietf.org/wg/tokbind/charter/), so if we do 
> something in this area, it's more likely we would do token binding 
> than channel ID,
> I expect.

Hi, I don't think this is exactly something that you can freely chose...
As you read FIDO U2F specifications, you'll see that added security is provided 
by TLS channel binding.

Search "Channel Binding" inside
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-glossary.html
and again here
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-security-ref.html

That's a great -nearly perfect- existing solution, and IMHO Firefox should 
probably implement this feature for better security and for better 
compatibility with servers that are implementing the server side (like google 
servers). 

http://tools.ietf.org/html/draft-balfanz-tls-channelid-01
http://www.ietf.org/rfc/rfc5056.txt
http://www.ietf.org/rfc/rfc5929.txt
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Ehsan Akhgari]

On 2015-12-02 9:48 AM, Richard Barnes wrote:

On Wed, Dec 2, 2015 at 12:25 AM,  wrote:


On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:

Oh well. Bummer.

/ Jonas


If it cheers you up any, the 2.0 API that replaces the U2F API uses
promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that
Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh and
new and hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped
this for google.com, and only for HTTPS, and that we were committed to
the W3C member submission as the path forward, but as I was working to back
up a citation to this, I found out that we submarine-launched the API in
Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to
Implement / Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that
Chrome put Firefox in this position of "old and busted" and "new hotness",
with "damned either way" as the result. I'm trying to find out more about
this, as well as Chrome and Chromium's future commitments regarding this
API.


That would be awesome, thanks, Ryan!

Do you mind also checking to see if this feature has an associated use 
counter in Chrome, and if so, how widely it's being used?



That said, knowing full well that the FIDO Alliance intends the W3C member
submission to the path forward, could you provide greater clarity:
1) What it is you intend to implement?



My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.




2) If you intend to implement [1], whether or not you'll unship that
if/as/when [2] progresses?



I think we would treat this just like we treat other early-stage things
that get shipped, gradually turning it off when the real thing shows up.


We usually keep such features on Nightly and Aurora and don't let them 
ride the trains all the way to release.  However in this particular 
case, I'm not sure if doing that would make sense if we end up deciding 
on not shipping the old API at all.


Given the Chrome situation, and that Edge seems to be working on 
implementing the new version of the API 
<https://dev.windows.com/en-us/microsoft-edge/platform/status/fido20webapis>, 
perhaps we should wait to see if Chrome compat requires us to implement 
the v1 of the API, and if not, skip it?


Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Eric Rescorla]

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan 
wrote:

> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:
>
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>> implications.
>>
>
> Where are we discussing that?
>

Richard and I have discussed it privately and had some offline interactions
with the authors. IIRC I made some comments on one of the bugs and on
some mailing list a while ago.



> I'd really like to see WebUSB with USB device IDs are bound to specific
> origins (through a registry for legacy devices and through the USB protocol
> extensions defined in that spec) so that vendors can host apps that access
> their devices --- and so that vendor pages in an  can define and
> vend "safe" APIs to any third-party application.
>

This seems to be roughly the API contemplated by the WebUSB spec.
To be honest, I'm not very excited about that design. Having a system
where the only people who can talk to USB device X are the manufacturers
and the browser is just a conduit for that interaction doesn't really seem
that
great for the Open Web.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Frederik Braun]

On 02.12.2015 18:53, Robert O'Callahan wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:
> 
>> Are you thinking of something like WebUSB?
>> (https://reillyeon.github.io/webusb/)? This is something we've looked at
>> a bit but we're still trying to wrap our heads around the security
>> implications.
>>
> 
> Where are we discussing that? I'd really like to see WebUSB with USB device
> IDs are bound to specific origins (through a registry for legacy devices
> and through the USB protocol extensions defined in that spec) so that
> vendors can host apps that access their devices --- and so that vendor
> pages in an  can define and vend "safe" APIs to any third-party
> application. We'd finally have decentralized extensibility for Web APIs to
> hardware.
> 
> Rob
> 

This is an interesting architecture.
I was originally thinking about allowing to list all possible devices
*and* preventing fingerprinting through a chrome dialog that mediates
between content and the user: The user chooses which device(s) to expose
to the specific website they are on. Similar to .
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Robert O'Callahan]

On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla  wrote:

> Are you thinking of something like WebUSB?
> (https://reillyeon.github.io/webusb/)? This is something we've looked at
> a bit but we're still trying to wrap our heads around the security
> implications.
>

Where are we discussing that? I'd really like to see WebUSB with USB device
IDs are bound to specific origins (through a registry for legacy devices
and through the USB protocol extensions defined in that spec) so that
vendors can host apps that access their devices --- and so that vendor
pages in an  can define and vend "safe" APIs to any third-party
application. We'd finally have decentralized extensibility for Web APIs to
hardware.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Eric Rescorla]

Hi Freddie, glad to see people so excited about it.

On Wed, Dec 2, 2015 at 8:22 AM,  wrote:
>
> So, let's forget about 2 for now, it is not a real thing... and
> well.. let's forget it. (If you read both specs you should see
> real differences and problems...)
>
> There are probably other questions Mozilla Core Team should ask to
> themselves :
>
> - Having a greater/larger HID Support, outside the FIDO U2F scope ?
> (This allows web services to communicate with HID devices - i.e.
> that's how some cryptocurrencies hardware wallets are using HID
> Chrome interface)
>

Are you thinking of something like WebUSB?
(https://reillyeon.github.io/webusb/)? This is something we've looked at
a bit but we're still trying to wrap our heads around the security
implications.


- Have TLS Channel ID Binding support. (Oh, this is really important)
> When you'll check FIDO U2F specifications, you'll see that TLS Channel
> ID Binding is an important part of the security against attacks like
> SSL Proxy and similar MITM attacks. This part is not mandatory. But
> Google servers are using this and Chrome supports it. So... please
> REALLY consider implementing it: it will bring higher security and
> probably will give a chance too in the future to be accepted as a
> supported browser on Google servers (I am not from Google so I can't
> speak on their behalf but this should be a rational requirements there).
> This is the only way to provide a full anti-phishing solution.
>

My understanding is that Channel ID is being superseded by token binding
(https://datatracker.ietf.org/wg/tokbind/charter/), so if we do something in
this area, it's more likely we would do token binding than channel ID,
I expect.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[fredletamanoir]

Hi All, great news !

TL;DR version:
--

I love U2F, I love Firefox
FIDO U2F is here to stay. 
FIDO 2.0 do not exist and will not replace U2F.
FIDO U2F is really great.
Please implement FIDO U2F.
Please please please implement TLS Channel ID Binding support
(important part of FIDO U2F specifications, but not mandatory)
Please consider larger HID support (as in Chrome).

Full version:
-

As you may know, we are several people to push for Firefox FIDO U2F 
support (https://bugzilla.mozilla.org/show_bug.cgi?id=1065729)
I joined the Bounty source initiative and was following the recent 
Firefox U2F support made through the small firefox extension...
(it works even if there is no TLS Channel ID Binding protection,
see below about that)

I am a Mozilla supporter for many many years and I work as a security 
architect inside a small company manufacturing FIDO U2F USB products...
so this is the kind of discussion I was dreaming of :)

> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
> Richard, it would help if you could clarify - are you proposing that 
> Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh
> and new and hoping to be standards track' W3C member submission API [2].

Let's be clear with some real information here:
- FIDO 2.0 will not replace FIDO U2F
- There will probably not be any kind of FIDO U2F 2.0 inside FIDO 2.0
- FIDO 2.0 has no goal to be compatible with FIDO U2F (and won't be)
- FIDO U2F is already here and here to stay. It is a great WORKING 
  solution: a secure second factor for strong web authentication 
  through a simple HID based API.
- There is alrady plenty of FIDO U2F related source code available
  to help people building great solutions (Chromium client source code,
  Google JS library source code and different Java/PHP server code)
- Nearly all FIDO U2F products have really secure architectures
  (for example, nearly every products are using secure elements /
   smart cards components, even if not mandatory, that's great)
- FIDO U2F over NFC and BLE specifications are currently being
  finalized, so there will be flexibility to cover mobile platforms.
- FIDO 2.0 W3c submission have no real details regarding technical
  implementation because FIDO 2 is only for now a very confusing draft 
  and there are lots of pressure to forget desktop based authentication, 
  to forget to use hardware with secure elements and several other 
  strange things you'll have to discover by yourself... Please do
  not put too many hopes into FIDO 2.0 (that's really not important)

> I originally wanted to reply with 'good news' [...] 
> [...] put Firefox in this position of "old and busted" and 
> "new hotness", with "damned either way" as the result. I'm trying to 
> find out more about this, as well as Chrome and Chromium's future 
> commitments regarding this API.

So, U2F is not old and busted, U2F is working and kicks ass :)
Google contributions to the specs and the Alliance were amazing.
And this is a real open standard, with real standard crypto.

- More and more services are directly adopting U2F.
- Federated Identity providers / web SSO solutions are adopting it.
- Firefox MUST adopt it :)

> That said, knowing full well that the FIDO Alliance intends the W3C 
> member submission to the path forward, could you provide greater clarity:
> 1) What it is you intend to implement?
> 2) If you intend to implement [1], whether or not you'll unship that 
> if/as/when [2] progresses?
> 
> [1] 
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
> [2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

So, let's forget about 2 for now, it is not a real thing... and
well.. let's forget it. (If you read both specs you should see
real differences and problems...)

There are probably other questions Mozilla Core Team should ask to
themselves :

- Having a greater/larger HID Support, outside the FIDO U2F scope ?
(This allows web services to communicate with HID devices - i.e. 
that's how some cryptocurrencies hardware wallets are using HID 
Chrome interface)

- Have TLS Channel ID Binding support. (Oh, this is really important)
When you'll check FIDO U2F specifications, you'll see that TLS Channel
ID Binding is an important part of the security against attacks like
SSL Proxy and similar MITM attacks. This part is not mandatory. But 
Google servers are using this and Chrome supports it. So... please 
REALLY consider implementing it: it will bring higher security and 
probably will give a chance too in the future to be accepted as a 
supported browser on Google servers (I am not from Google so I can't 
speak on their be

Re: Intent to implement and ship: FIDO U2F API

[Mike Taylor]

On 12/2/15 8:53 AM, Ms2ger wrote:

I don't remember what the current conventional wisdom about
prefixing is, but I would be open to shipping with a prefix if
people thought that would ease pain in the eventual transition.


No. Nonononononononono.


This is the conventional wisdom. Prefixes end up causing pain.

--
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/02/2015 03:48 PM, Richard Barnes wrote:
> I think we would treat this just like we treat other early-stage
> things that get shipped, gradually turning it off when the real
> thing shows up.

That would mean only shipping it on Nightly and maybe Aurora for now.

> I don't remember what the current conventional wisdom about
> prefixing is, but I would be open to shipping with a prefix if
> people thought that would ease pain in the eventual transition.

No. Nonononononononono.

Ms2ger
-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJWXwXcAAoJEOXgvIL+s8n2ZwIH/2XJbkWFfG57Bvsum1EIREVz
bSbRXE3eLsUyYtOIWhT8NX3PWuvqFH8/xmkvTGq57CwHxVQiHT6Su+voLG7qLNpK
pInNX475lLK/oj81mHvRAlymlC3MjVHWp53UeAz1fTW3i66ez0YT/vZtD2iA5YMo
iOcIL6VhSXFUHI8yWwFJIcQ/p60pwRBOEA9IJIIAJJk84xf9tEakNbqM1pQwFesW
ROyL7ZFOxLH/oGWCPWxoYfM/btfEqcYDC4FuEsd4SIruyD8liGJ3SMLnXkt7y9k8
8RcfqfUKjlhbE2fzzOf0ooNokpmzhxk2flEzNX8Y/bWl8glMKsbs0Dy89re8tTw=
=Z0LB
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Richard Barnes]

On Wed, Dec 2, 2015 at 12:25 AM,  wrote:

> On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> > Oh well. Bummer.
> >
> > / Jonas
>
> If it cheers you up any, the 2.0 API that replaces the U2F API uses
> promises - http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
>
> Richard, it would help if you could clarify - are you proposing that
> Firefox implement the 'old and deprecated' U2F API [1], or the 'fresh and
> new and hoping to be standards track' W3C member submission API [2].
>
> I originally wanted to reply with 'good news' that Chrome only shipped
> this for google.com, and only for HTTPS, and that we were committed to
> the W3C member submission as the path forward, but as I was working to back
> up a citation to this, I found out that we submarine-launched the API in
> Chrome 40 [3], for all HTTP and HTTPS origins, without an Intent to
> Implement / Intent to Ship.
>
> So, speaking solely on my behalf and not that of my employer, sorry that
> Chrome put Firefox in this position of "old and busted" and "new hotness",
> with "damned either way" as the result. I'm trying to find out more about
> this, as well as Chrome and Chromium's future commitments regarding this
> API.
>
> That said, knowing full well that the FIDO Alliance intends the W3C member
> submission to the path forward, could you provide greater clarity:
> 1) What it is you intend to implement?
>

My initial intent was to propose implementing [1], then implementing [2]
when it's ready.  After all, there's a lot in common, and as you say, the
W3C version will be much nicer.



> 2) If you intend to implement [1], whether or not you'll unship that
> if/as/when [2] progresses?
>

I think we would treat this just like we treat other early-stage things
that get shipped, gradually turning it off when the real thing shows up.

I don't remember what the current conventional wisdom about prefixing is,
but I would be open to shipping with a prefix if people thought that would
ease pain in the eventual transition.

--Richard



> [1]
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
> [2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
> [3]
> https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9
> ___
> 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 implement and ship: FIDO U2F API

[ryan . sleevi]

On Tuesday, December 1, 2015 at 6:04:30 PM UTC-8, Jonas Sicking wrote:
> Oh well. Bummer.
> 
> / Jonas

If it cheers you up any, the 2.0 API that replaces the U2F API uses promises - 
http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/

Richard, it would help if you could clarify - are you proposing that Firefox 
implement the 'old and deprecated' U2F API [1], or the 'fresh and new and 
hoping to be standards track' W3C member submission API [2].

I originally wanted to reply with 'good news' that Chrome only shipped this for 
google.com, and only for HTTPS, and that we were committed to the W3C member 
submission as the path forward, but as I was working to back up a citation to 
this, I found out that we submarine-launched the API in Chrome 40 [3], for all 
HTTP and HTTPS origins, without an Intent to Implement / Intent to Ship.

So, speaking solely on my behalf and not that of my employer, sorry that Chrome 
put Firefox in this position of "old and busted" and "new hotness", with 
"damned either way" as the result. I'm trying to find out more about this, as 
well as Chrome and Chromium's future commitments regarding this API.

That said, knowing full well that the FIDO Alliance intends the W3C member 
submission to the path forward, could you provide greater clarity:
1) What it is you intend to implement?
2) If you intend to implement [1], whether or not you'll unship that if/as/when 
[2] progresses?

[1] 
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html
[2] http://www.w3.org/Submission/2015/SUBM-fido-web-api-20151120/
[3] 
https://chromium.googlesource.com/chromium/src/+/d60fcd7caafa7046da693fe2c3206ab5cf20%5E%21/#F9
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: FIDO U2F API

[Jonas Sicking]

Oh well. Bummer.

/ Jonas

On Tue, Dec 1, 2015 at 5:36 PM, Richard Barnes  wrote:
> It's my understanding that U2F qua U2F is considered pretty much baked by
> the developer community, and there's already code written to it.  But these
> concerns will be great for the W3C group and the successor API.  I've got a
> similar list started related to crypto and future-proofing.
>
>
> On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:
>>
>> Any chance that the API can be made a little more JS friendly? First
>> thing that stands out is the use of success/error callbacks rather
>> than the use of Promises.
>>
>> Also the use of numeric codes, rather than string values, is a pattern
>> that the web has generally moved away from.
>>
>> / Jonas
>>
>> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
>> wrote:
>> > The FIDO Alliance has been developing standards for hardware-based
>> > authentication of users by websites [1].  Their work is getting
>> > significant
>> > traction, so the Mozilla Foundation has decided to join the FIDO
>> > Alliance.
>> > Work has begun in the W3C to create open standards using FIDO as a
>> > starting
>> > point. We are proposing to implement the FIDO U2F API in Firefox in its
>> > current form and then track the evolving W3C standard.
>> >
>> > Background: The FIDO Alliance has been developing a standard for
>> > hardware-based user authentication known as “Universal Two-Factor” or
>> > U2F
>> > [2].  This standard allows a website to verify that a user is in
>> > possession
>> > of a specific device by having the device sign a challenge with a
>> > private
>> > key that is held on the hardware device.  The browser’s role is mainly
>> > (1)
>> > to route messages between the website and the token, and (2) to add the
>> > origin of the website to the message signed by the token (so that the
>> > signature is bound to the site).
>> >
>> > Several major websites now support U2F for authentication, including
>> > Google
>> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
>> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
>> > a
>> > “WebAuthentication” working group that will work on a standard for
>> > enhanced
>> > authentication using FIDO as a starting point [7].
>> >
>> > Proposed: To implement the high-level U2F API described in the FIDO JS
>> > API
>> > specification, with support for the USB HID token interface.
>> >
>> > Please send comments on this proposal to the list no later than Monday,
>> > December 14, 2015.
>> >
>> > -
>> >
>> > Personally, I have some reservations about implementing this, but I
>> > still
>> > think it’s worth doing, given the clear need for something to augment
>> > passwords.
>> >
>> > It’s unfortunate that the initial FIDO standards were developed in a
>> > closed
>> > group, but there is good momentum building toward making FIDO more open.
>> > I
>> > have some specific concerns about the U2F API itself, but they’re
>> > relatively minor.  For example, the whole system is highly vertically
>> > integrated, so if we want to change any part of it (e.g., to use a curve
>> > other than P-256 for signatures), we’ll need to build a whole new API.
>> > But
>> > these are issues that can be addressed in the W3C process.
>> >
>> > We will continue to work on making standards for secure authentication
>> > more
>> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
>> > developer interest, so it makes sense for us to work on implementing it.
>> >
>> > Thanks,
>> > --Richard
>> >
>> > [1] https://fidoalliance.org/
>> > [2] https://fidoalliance.org/specifications/download/
>> > [3] https://support.google.com/accounts/answer/6103523?hl=en
>> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
>> > [5]
>> >
>> > https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
>> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
>> > [7] http://w3c.github.io/websec/web-authentication-charter
>> > ___
>> > 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 implement and ship: FIDO U2F API

[Richard Barnes]

It's my understanding that U2F qua U2F is considered pretty much baked by
the developer community, and there's already code written to it.  But these
concerns will be great for the W3C group and the successor API.  I've got a
similar list started related to crypto and future-proofing.


On Tue, Dec 1, 2015 at 8:29 PM, Jonas Sicking  wrote:

> Any chance that the API can be made a little more JS friendly? First
> thing that stands out is the use of success/error callbacks rather
> than the use of Promises.
>
> Also the use of numeric codes, rather than string values, is a pattern
> that the web has generally moved away from.
>
> / Jonas
>
> On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes 
> wrote:
> > The FIDO Alliance has been developing standards for hardware-based
> > authentication of users by websites [1].  Their work is getting
> significant
> > traction, so the Mozilla Foundation has decided to join the FIDO
> Alliance.
> > Work has begun in the W3C to create open standards using FIDO as a
> starting
> > point. We are proposing to implement the FIDO U2F API in Firefox in its
> > current form and then track the evolving W3C standard.
> >
> > Background: The FIDO Alliance has been developing a standard for
> > hardware-based user authentication known as “Universal Two-Factor” or U2F
> > [2].  This standard allows a website to verify that a user is in
> possession
> > of a specific device by having the device sign a challenge with a private
> > key that is held on the hardware device.  The browser’s role is mainly
> (1)
> > to route messages between the website and the token, and (2) to add the
> > origin of the website to the message signed by the token (so that the
> > signature is bound to the site).
> >
> > Several major websites now support U2F for authentication, including
> Google
> > [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> > for U2F support in Gecko [6].  The W3C has  begun the process of forming
> a
> > “WebAuthentication” working group that will work on a standard for
> enhanced
> > authentication using FIDO as a starting point [7].
> >
> > Proposed: To implement the high-level U2F API described in the FIDO JS
> API
> > specification, with support for the USB HID token interface.
> >
> > Please send comments on this proposal to the list no later than Monday,
> > December 14, 2015.
> >
> > -
> >
> > Personally, I have some reservations about implementing this, but I still
> > think it’s worth doing, given the clear need for something to augment
> > passwords.
> >
> > It’s unfortunate that the initial FIDO standards were developed in a
> closed
> > group, but there is good momentum building toward making FIDO more
> open.  I
> > have some specific concerns about the U2F API itself, but they’re
> > relatively minor.  For example, the whole system is highly vertically
> > integrated, so if we want to change any part of it (e.g., to use a curve
> > other than P-256 for signatures), we’ll need to build a whole new API.
> But
> > these are issues that can be addressed in the W3C process.
> >
> > We will continue to work on making standards for secure authentication
> more
> > open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> > developer interest, so it makes sense for us to work on implementing it.
> >
> > Thanks,
> > --Richard
> >
> > [1] https://fidoalliance.org/
> > [2] https://fidoalliance.org/specifications/download/
> > [3] https://support.google.com/accounts/answer/6103523?hl=en
> > [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> > [5]
> >
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> > [7] http://w3c.github.io/websec/web-authentication-charter
> > ___
> > 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 implement and ship: FIDO U2F API

[Jonas Sicking]

Any chance that the API can be made a little more JS friendly? First
thing that stands out is the use of success/error callbacks rather
than the use of Promises.

Also the use of numeric codes, rather than string values, is a pattern
that the web has generally moved away from.

/ Jonas

On Tue, Dec 1, 2015 at 5:23 PM, Richard Barnes  wrote:
> The FIDO Alliance has been developing standards for hardware-based
> authentication of users by websites [1].  Their work is getting significant
> traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
> Work has begun in the W3C to create open standards using FIDO as a starting
> point. We are proposing to implement the FIDO U2F API in Firefox in its
> current form and then track the evolving W3C standard.
>
> Background: The FIDO Alliance has been developing a standard for
> hardware-based user authentication known as “Universal Two-Factor” or U2F
> [2].  This standard allows a website to verify that a user is in possession
> of a specific device by having the device sign a challenge with a private
> key that is held on the hardware device.  The browser’s role is mainly (1)
> to route messages between the website and the token, and (2) to add the
> origin of the website to the message signed by the token (so that the
> signature is bound to the site).
>
> Several major websites now support U2F for authentication, including Google
> [3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
> for U2F support in Gecko [6].  The W3C has  begun the process of forming a
> “WebAuthentication” working group that will work on a standard for enhanced
> authentication using FIDO as a starting point [7].
>
> Proposed: To implement the high-level U2F API described in the FIDO JS API
> specification, with support for the USB HID token interface.
>
> Please send comments on this proposal to the list no later than Monday,
> December 14, 2015.
>
> -
>
> Personally, I have some reservations about implementing this, but I still
> think it’s worth doing, given the clear need for something to augment
> passwords.
>
> It’s unfortunate that the initial FIDO standards were developed in a closed
> group, but there is good momentum building toward making FIDO more open.  I
> have some specific concerns about the U2F API itself, but they’re
> relatively minor.  For example, the whole system is highly vertically
> integrated, so if we want to change any part of it (e.g., to use a curve
> other than P-256 for signatures), we’ll need to build a whole new API.  But
> these are issues that can be addressed in the W3C process.
>
> We will continue to work on making standards for secure authentication more
> open.  In the meantime, U2F is what’s here now, and there’s demonstrated
> developer interest, so it makes sense for us to work on implementing it.
>
> Thanks,
> --Richard
>
> [1] https://fidoalliance.org/
> [2] https://fidoalliance.org/specifications/download/
> [3] https://support.google.com/accounts/answer/6103523?hl=en
> [4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
> [5]
> https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
> [6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> [7] http://w3c.github.io/websec/web-authentication-charter
> ___
> 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

Intent to implement and ship: FIDO U2F API

[Richard Barnes]

The FIDO Alliance has been developing standards for hardware-based
authentication of users by websites [1].  Their work is getting significant
traction, so the Mozilla Foundation has decided to join the FIDO Alliance.
Work has begun in the W3C to create open standards using FIDO as a starting
point. We are proposing to implement the FIDO U2F API in Firefox in its
current form and then track the evolving W3C standard.

Background: The FIDO Alliance has been developing a standard for
hardware-based user authentication known as “Universal Two-Factor” or U2F
[2].  This standard allows a website to verify that a user is in possession
of a specific device by having the device sign a challenge with a private
key that is held on the hardware device.  The browser’s role is mainly (1)
to route messages between the website and the token, and (2) to add the
origin of the website to the message signed by the token (so that the
signature is bound to the site).

Several major websites now support U2F for authentication, including Google
[3], Dropbox [4], and Github [5].  Axel Nennker has filed a Bugzilla bug
for U2F support in Gecko [6].  The W3C has  begun the process of forming a
“WebAuthentication” working group that will work on a standard for enhanced
authentication using FIDO as a starting point [7].

Proposed: To implement the high-level U2F API described in the FIDO JS API
specification, with support for the USB HID token interface.

Please send comments on this proposal to the list no later than Monday,
December 14, 2015.

-

Personally, I have some reservations about implementing this, but I still
think it’s worth doing, given the clear need for something to augment
passwords.

It’s unfortunate that the initial FIDO standards were developed in a closed
group, but there is good momentum building toward making FIDO more open.  I
have some specific concerns about the U2F API itself, but they’re
relatively minor.  For example, the whole system is highly vertically
integrated, so if we want to change any part of it (e.g., to use a curve
other than P-256 for signatures), we’ll need to build a whole new API.  But
these are issues that can be addressed in the W3C process.

We will continue to work on making standards for secure authentication more
open.  In the meantime, U2F is what’s here now, and there’s demonstrated
developer interest, so it makes sense for us to work on implementing it.

Thanks,
--Richard

[1] https://fidoalliance.org/
[2] https://fidoalliance.org/specifications/download/
[3] https://support.google.com/accounts/answer/6103523?hl=en
[4] https://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/
[5]
https://github.com/blog/2071-github-supports-universal-2nd-factor-authentication
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
[7] http://w3c.github.io/websec/web-authentication-charter
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[smaug]

On 11/28/2015 11:36 AM, Anne van Kesteren wrote:

On Sat, Nov 28, 2015 at 9:09 AM, Ian Young  wrote:

Maybe a
Mozillian could drop in and give us an explanation of how the W3C
process influences what gets implemented and when?


Well, it doesn't really, many things are standardized by the W3C that
are a poor fit for browsers. What gets implemented depends on what we
think is good for the web, competitive pressure, and available
resources. Having said that, many Mozillians believe this particular
technology is good for the web and there is some competitive pressure,
so it's mostly a question of resources. If you have funds or browser
engineering chops, patches welcome.





It is also about having a good spec to implement. As far as I see, the current 
spec is more like a
initial draft.
Stuff like
"obtain U2F MessagePort in a browser specific manner" don't sound good.
So far I haven't found a spec which defines how to get access to U2F 
MessagePort or some
u2f object which has register() etc methods.

But perhaps I'm not looking at the right specs.




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[smaug]

On 11/28/2015 11:36 AM, Anne van Kesteren wrote:

On Sat, Nov 28, 2015 at 9:09 AM, Ian Young  wrote:

Maybe a
Mozillian could drop in and give us an explanation of how the W3C
process influences what gets implemented and when?


Well, it doesn't really, many things are standardized by the W3C that
are a poor fit for browsers. What gets implemented depends on what we
think is good for the web, competitive pressure, and available
resources. Having said that, many Mozillians believe this particular
technology is good for the web and there is some competitive pressure,
so it's mostly a question of resources. If you have funds or browser
engineering chops, patches welcome.





It is also about having a good spec to implement. As far as I see, the current 
spec is more like a
initial draft.
Stuff like
"obtain U2F MessagePort in a browser specific manner" don't sound good.
So far I haven't found a spec which defines how to get access to U2F 
MessagePort or some
u2f object which has register() etc methods.

But perhaps I'm not looking at the right specs.




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Anne van Kesteren]

On Sat, Nov 28, 2015 at 9:09 AM, Ian Young  wrote:
> Maybe a
> Mozillian could drop in and give us an explanation of how the W3C
> process influences what gets implemented and when?

Well, it doesn't really, many things are standardized by the W3C that
are a poor fit for browsers. What gets implemented depends on what we
think is good for the web, competitive pressure, and available
resources. Having said that, many Mozillians believe this particular
technology is good for the web and there is some competitive pressure,
so it's mostly a question of resources. If you have funds or browser
engineering chops, patches welcome.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Ian Young]

FIDO has now submitted the U2F Web API to the W3C[1]. I know this only
makes it a *proposed* standard, but I would hope having it on this track
would be enough to bump it up a bit in Mozilla's priorities. Maybe a
Mozillian could drop in and give us an explanation of how the W3C
process influences what gets implemented and when?


Links:

  1. 
https://fidoalliance.org/fido-alliance-announces-FIDO-authentication-poised-for-continued-growth-as-alliance-submits-FIDO-2.0-web-API-to-W3C/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Gervase Markham]

On 18/11/15 19:26, phow...@ccvschools.com wrote:
> This is definitely an important feature, but I'm not holding my
> breath.  I have had a lot of experience with Mozilla over the years
> and I really doubt anything will materialize in the near future.

Feeling particularly entitled today, are we?

>From the look of the bug, it seems like patches are certainly being
accepted.

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[phowell]

On Thursday, November 5, 2015 at 1:18:44 AM UTC-7, Jeroen Hoek wrote:
> In December 2014 the first public release of the Fido alliance's
> Universal 2nd Factor (U2F) specification was published. The idea behind
> this open specification is to provide a secure two-factor authentication
> method with affordable hardware keys and a friendly UX.
> 
> If I buy a hardware key that implements Fido U2F today, I can use it to
> log on to Google's GMail and Github. It is possible to use the same
> hardware key with any web service offering Fido U2F support, by design.
> The specification allows for three methods of communication: USB, NFC,
> and Bluetooth Low Energy (BLE).
> 
> For Fido U2F to work, a browser implementing this technology is required.
> 
> 
> There is an issue about Fido U2F support in Firefox:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
> 
> Unfortunately, this issue appears to receive no priority from Mozilla.
> Reading the comments in this issue, it appears that despite the
> attractiveness of the Fido U2F specification, developers see support in
> Firefox as a deal-breaker. Personally, I feel that a security technology
> such as this needs at least one free software browser to support it to
> provide a viable alternative.
> 
> Judging from the bounty placed on this Firefox issue (currently
> exceeding 1000 USD), there appears to be a fairly strong community
> desire to see this feature implemented. Commenters on the issue are,
> however, worried about the (perceived lack of) priority afforded to this
> issue.
> 
> Developers participating in the issue recommended we post questions
> about the prioritizing of this issue to the mozilla.dev.platform mailing
> list. My apologies if this is not the place to discuss this issue.
> 
> --
> 
> Is Fido U2F a technology that Mozilla can endorse and support?
> 
> Could this technology be considered for inclusion in Firefox?
> 
> --
> 
> Some background on this technology for those who are unfamiliar with it:
> 
> The full Fido U2F specifications are available for download here:
> 
> https://fidoalliance.org/specifications/overview/
> https://fidoalliance.org/specifications/download/
> 
> Specifically, the U2F overview may be interesting if you want a more
> in-depth architectural overiew:
> 
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html
> 
> 
> Google announced support for Fido U2F a year ago, in October 2014, and
> Chrome currently implements the Fido U2F standard:
> 
> https://googleonlinesecurity.blogspot.nl/2014/10/strengthening-2-step-verification-with.html
> 
> 
> Microsoft is backing this standard as well:
> 
> https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/
> 
> 
> Yubico is one of the driving forces behind the Fido specifications from
> the manufacturers side. They produce USB and NFC hardware tokens that
> can be used with open security standards such as OATH-HOTP and
> OATH-TOTP. Their recent line-up includes Fido U2F support as well:
> 
> https://www.yubico.com/products/yubikey-hardware/
> 
> Yubico on Fido U2F:
> 
> https://www.yubico.com/applications/fido/
> 
> Yubico is not the only manufacturer -- other Fido-certified keys can be
> found on Amazon -- but they do appear to have a leading edge.
> 
> 
> I am personally interested in Fido U2F from a professional standpoint.
> The possibility to provide affordable two-factor authentication either
> through USB, NFC, or BLE is appealing, and my employer is considering
> opting for this standard to secure the health care software services we
> provide -- cross-browser support is, however, a requirement.
> 
> I am not affiliated with the Fido alliance or its backers.
> 
> --
> Kind regards,
> 
> Jeroen Hoek

This is definitely an important feature, but I'm not holding my breath.  I have 
had a lot of experience with Mozilla over the years and I really doubt anything 
will materialize in the near future.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Michael Schwartz (m...@gluu.org)]

Hi guys... if you need a FIDO U2F server to test against, the Gluu Server has 
endpoints built in. Its really easy to deploy on Ubuntu / Centos: 
http://www.gluu.org/docs/admin-guide/deployment/

Also, I recorded a geeky video on how to test FIDO U2F: http://gluu.co/fido-u2f

Basically, check enable, change the default authn mechanism... and you're done. 
Its really easy.

- Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Frederik Braun]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

There is an experimental add-on being worked on that tries bring U2F
support to Firefox. The source code is at
<https://github.com/prefiks/u2f4moz>, but it has not yet gone through
the Add-on review process.



Btw, the most important thing about the bug is comment 62
(https://bugzilla.mozilla.org/show_bug.cgi?id=1065729#c62).

To quickly summarize what Richard said:

Yes, nobody within the Mozilla corporation is officially assigned to
work on this.
The abstraction level of the API is not very interoperable with all
kinds of second factors that are not compliant with FIDO U2F, which is
a bit unfortunate.
We will allow third-party contributions and would suggest implementing
an USB HID API, which would be arguably more useful for any kind of
second factor implementation to sit on top.
Part of this is being worked on in
https://bugzilla.mozilla.org/show_bug.cgi?id=1198330, it seems?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWOxnyAAoJEOwSh5wL+fW4+UsIAMrSDpMgHZn7I0bBM1p6CmA/
+KU6rkyydV2FV3/cdDql/Z9xJLL2SJrclnIGuPfUIVbGdm+cO0zxVW/9ZUbk3u/E
7XfHV34ZvizPrNbsMpMu3z8O2a+M0UNH3PxbT8huvU1V2eCxlduPkpieO7uegbmE
kH9GX31wk+mCMGItkCdu4NIaBjLKv2xNeXyzZjMmOxRSgH3clKGyumiz+K6tj1FJ
yTjRLkCSP2mADopDQTQPxF6/DAV/INj/2uHNOA1jhd6gBiv46j3PaYf23iUGoPQt
y1OwQClwCsOvXHhxYotLLlHfb1dDgFO33b4bQGGqgwfIMYiWDvDTucFzezSesRQ=
=3zWK
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fido U2F, two-factor authentication support

[Joseph Lorenzo Hall]

+1

I would love love love to have U2F in Firefox.

(Also, Dropbox supports it too, just as a data point:
http://blogs.dropbox.com/dropbox/2015/08/u2f-security-keys/ )

On Thu, Nov 5, 2015 at 5:18 PM, Jeroen Hoek  wrote:
> In December 2014 the first public release of the Fido alliance's
> Universal 2nd Factor (U2F) specification was published. The idea behind
> this open specification is to provide a secure two-factor authentication
> method with affordable hardware keys and a friendly UX.
>
> If I buy a hardware key that implements Fido U2F today, I can use it to
> log on to Google's GMail and Github. It is possible to use the same
> hardware key with any web service offering Fido U2F support, by design.
> The specification allows for three methods of communication: USB, NFC,
> and Bluetooth Low Energy (BLE).
>
> For Fido U2F to work, a browser implementing this technology is required.
>
>
> There is an issue about Fido U2F support in Firefox:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1065729
>
> Unfortunately, this issue appears to receive no priority from Mozilla.
> Reading the comments in this issue, it appears that despite the
> attractiveness of the Fido U2F specification, developers see support in
> Firefox as a deal-breaker. Personally, I feel that a security technology
> such as this needs at least one free software browser to support it to
> provide a viable alternative.
>
> Judging from the bounty placed on this Firefox issue (currently
> exceeding 1000 USD), there appears to be a fairly strong community
> desire to see this feature implemented. Commenters on the issue are,
> however, worried about the (perceived lack of) priority afforded to this
> issue.
>
> Developers participating in the issue recommended we post questions
> about the prioritizing of this issue to the mozilla.dev.platform mailing
> list. My apologies if this is not the place to discuss this issue.
>
> --
>
> Is Fido U2F a technology that Mozilla can endorse and support?
>
> Could this technology be considered for inclusion in Firefox?
>
> --
>
> Some background on this technology for those who are unfamiliar with it:
>
> The full Fido U2F specifications are available for download here:
>
> https://fidoalliance.org/specifications/overview/
> https://fidoalliance.org/specifications/download/
>
> Specifically, the U2F overview may be interesting if you want a more
> in-depth architectural overiew:
>
> https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html
>
>
> Google announced support for Fido U2F a year ago, in October 2014, and
> Chrome currently implements the Fido U2F standard:
>
> https://googleonlinesecurity.blogspot.nl/2014/10/strengthening-2-step-verification-with.html
>
>
> Microsoft is backing this standard as well:
>
> https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/
>
>
> Yubico is one of the driving forces behind the Fido specifications from
> the manufacturers side. They produce USB and NFC hardware tokens that
> can be used with open security standards such as OATH-HOTP and
> OATH-TOTP. Their recent line-up includes Fido U2F support as well:
>
> https://www.yubico.com/products/yubikey-hardware/
>
> Yubico on Fido U2F:
>
> https://www.yubico.com/applications/fido/
>
> Yubico is not the only manufacturer — other Fido-certified keys can be
> found on Amazon — but they do appear to have a leading edge.
>
>
> I am personally interested in Fido U2F from a professional standpoint.
> The possibility to provide affordable two-factor authentication either
> through USB, NFC, or BLE is appealing, and my employer is considering
> opting for this standard to secure the health care software services we
> provide — cross-browser support is, however, a requirement.
>
> I am not affiliated with the Fido alliance or its backers.
>
> --
> Kind regards,
>
> Jeroen Hoek
>
> Lable
> ✉ jeroen.h...@lable.nl
> GPG: 44D4 1D39 535A 1F9A 9509  92C5 A7A8 B913 D40D D022
>
> http://lable.nl — KvK № 55984037 — BTW № NL8519.32.411.B.01
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
j...@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fido U2F, two-factor authentication support

[Jeroen Hoek]

In December 2014 the first public release of the Fido alliance's
Universal 2nd Factor (U2F) specification was published. The idea behind
this open specification is to provide a secure two-factor authentication
method with affordable hardware keys and a friendly UX.

If I buy a hardware key that implements Fido U2F today, I can use it to
log on to Google's GMail and Github. It is possible to use the same
hardware key with any web service offering Fido U2F support, by design.
The specification allows for three methods of communication: USB, NFC,
and Bluetooth Low Energy (BLE).

For Fido U2F to work, a browser implementing this technology is required.


There is an issue about Fido U2F support in Firefox:

https://bugzilla.mozilla.org/show_bug.cgi?id=1065729

Unfortunately, this issue appears to receive no priority from Mozilla.
Reading the comments in this issue, it appears that despite the
attractiveness of the Fido U2F specification, developers see support in
Firefox as a deal-breaker. Personally, I feel that a security technology
such as this needs at least one free software browser to support it to
provide a viable alternative.

Judging from the bounty placed on this Firefox issue (currently
exceeding 1000 USD), there appears to be a fairly strong community
desire to see this feature implemented. Commenters on the issue are,
however, worried about the (perceived lack of) priority afforded to this
issue.

Developers participating in the issue recommended we post questions
about the prioritizing of this issue to the mozilla.dev.platform mailing
list. My apologies if this is not the place to discuss this issue.

--

Is Fido U2F a technology that Mozilla can endorse and support?

Could this technology be considered for inclusion in Firefox?

--

Some background on this technology for those who are unfamiliar with it:

The full Fido U2F specifications are available for download here:

https://fidoalliance.org/specifications/overview/
https://fidoalliance.org/specifications/download/

Specifically, the U2F overview may be interesting if you want a more
in-depth architectural overiew:

https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-overview.html


Google announced support for Fido U2F a year ago, in October 2014, and
Chrome currently implements the Fido U2F standard:

https://googleonlinesecurity.blogspot.nl/2014/10/strengthening-2-step-verification-with.html


Microsoft is backing this standard as well:

https://blogs.windows.com/business/2015/02/13/microsoft-announces-fido-support-coming-to-windows-10/


Yubico is one of the driving forces behind the Fido specifications from
the manufacturers side. They produce USB and NFC hardware tokens that
can be used with open security standards such as OATH-HOTP and
OATH-TOTP. Their recent line-up includes Fido U2F support as well:

https://www.yubico.com/products/yubikey-hardware/

Yubico on Fido U2F:

https://www.yubico.com/applications/fido/

Yubico is not the only manufacturer — other Fido-certified keys can be
found on Amazon — but they do appear to have a leading edge.


I am personally interested in Fido U2F from a professional standpoint.
The possibility to provide affordable two-factor authentication either
through USB, NFC, or BLE is appealing, and my employer is considering
opting for this standard to secure the health care software services we
provide — cross-browser support is, however, a requirement.

I am not affiliated with the Fido alliance or its backers.

--
Kind regards,

Jeroen Hoek

Lable
✉ jeroen.h...@lable.nl
GPG: 44D4 1D39 535A 1F9A 9509  92C5 A7A8 B913 D40D D022

http://lable.nl — KvK № 55984037 — BTW № NL8519.32.411.B.01



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform