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

[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

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

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

[Jonas Sicking]

Oh well. Bummer.

/ Jonas

[ryan....@gmail.com]

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/+/d60fcd7caafaffff7046da693fe2c3206ab5cf20%5E%21/#F9

[Richard Barnes]

On Wed, Dec 2, 2015 at 12:25 AM, <ryan....@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?
>

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/+/d60fcd7caafaffff7046da693fe2c3206ab5cf20%5E%21/#F9

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

[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

[fredlet...@gmail.com]

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 behalf but this should be a rational requirements there).
This is the only way to provide a full anti-phishing solution.

By the way, thanx for all the work and recent contributions to this
subject ! FIDO U2F rules ! Mozilla/Firefox Rules ! Let's make them rule
together :)

Regards
--
Frédéric

[Eric Rescorla]

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

On Wed, Dec 2, 2015 at 8:22 AM, <fredlet...@gmail.com> 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

[Robert O'Callahan]

On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla <e...@rtfm.com> 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 <iframe> 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

[Frederik Braun]

On 02.12.2015 18:53, Robert O'Callahan wrote:
> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla <e...@rtfm.com> 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 <iframe> 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 <input type="file">.

[Eric Rescorla]

On Wed, Dec 2, 2015 at 9:53 AM, Robert O'Callahan <rob...@ocallahan.org>

wrote:

> On Wed, Dec 2, 2015 at 9:37 AM, Eric Rescorla <e...@rtfm.com> 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 <iframe> 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

[Ehsan Akhgari]

On 2015-12-02 9:48 AM, Richard Barnes wrote:
> On Wed, Dec 2, 2015 at 12:25 AM, <ryan....@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 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

[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

[smaug]

On 12/02/2015 07:25 AM, ryan....@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. "

[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. "



>

[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 :)

[Eric Rescorla]

On Wed, Dec 2, 2015 at 1:11 PM, Frederic Martin <fredlet...@gmail.com>
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

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

[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

[Frederic Martin]

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.

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

[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

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

[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. :)

[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

[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

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

[hill...@gmail.com]

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

[Frederic Martin]

On Tuesday, December 8, 2015 at 8:49:30 PM UTC+1, hill...@gmail.com wrote:
> I'm no longer directly involved with the FIDO Alliance, so I can't speak to the FIDO 2.0 timelines

Hi Brad, thanx for all your previous great work! :)

[...]

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

Amen. I fully agree.

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

If Firefox users expect using FIDO U2F devices to protect their Google related accounts (GMail, Youtube, Google Drive...), it could be difficult to explain Firefox is not accepted on these services IF Google have Channel ID support as a requirement. (I did not test if other deployed server/services are using Channel ID...). Mozilla Foundation should probably discuss this directly with Google, to know if Channel ID support is a real requirement.

By the way, SMS codes, OTP/TOTP and all those stupid authentication methods are vulnerable to simple MITM / Phishing attacks. FIDO U2F is supposed to solve that kind of vulnerabilities. If you remove the non-mandatory Channel ID protection from FIDO U2F authentication architecture, you make FIDO U2F vulnerable again to that kind of no-brain-needed attack... so, whatever Google position can be, I am still recommending to implement Channel ID protection inside Firefox.

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

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.

[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 <fredlet...@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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[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 :)

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

[Eric Rescorla]

On Fri, Feb 5, 2016 at 3:22 PM, Fred Le Tamanoir <fredlet...@gmail.com>
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

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

[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

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

[Eric Rescorla]

On Mon, Feb 8, 2016 at 10:13 PM, Frederic Martin <fredlet...@gmail.com>
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

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

I am hardly following you on this... I probably missed something. Perhaps I underestimated a side effect of TLS Channel ID. How can it used to have enhanced user/browser fingerprint or shady DRM related features ?

AFAIK, Google is simply using this added protection on their servers. For now, I kind of approve this added protection mechanism, but -like I said- perhaps I am forgetting something bad here. On the client side, I can still fully follow how TLS Channel ID is used inside my browser...

I don't know if Google servers will allow FIDO Clients/browsers to use their authentication servers if not compatible with this added protection, that's all. IMHO, it is an added value but if you just want to know if Firefox users would be discriminated without implementing TLS Channel ID, you'd rather ask Google team now to avoid bad surprise... then you'll be be able to decide with this information in mind.

At the end, you can still chose to be incompatible with their services. Or Google can chose to forget TLS Channel ID... Whatever :) I wanted to know if you already knew about Google position (Of course I will try to ask them too now...) and what was your/Mozilla dev team own position on TLS Channel ID (I am still confused on that point anyway...)

Please keep in mind that I am -and many other secure web application architect/dev- very positively excited that Firefox will support FIDO U2F. This will bring enhanced security for online authentication but for many many other derived and hacked/tweaked applications. Whatever your choice will be regarding TLS Channel ID.

[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