Re: Enabled CRLite in Nightly

[J.C. Jones]

About 10 times a year, the update will be a new filter, which is going to
be about 5-6 MB, which might be more an issue.

Also, CRLite depends on the metadata for Intermediate Preloading, which is
several megabytes of certificates -- but those change very, very rarely, so
once populated they won't be downloaded again.

Perhaps we should go ahead and experiment with these two features in Fenix
Nightly.

J.C.

On Tue, Nov 17, 2020 at 12:19 AM Henri Sivonen  wrote:

> On Fri, Nov 13, 2020 at 6:19 AM J.C. Jones  wrote:
> > Not yet, no. Neither this nor Intermediate Preloading (which CRLite
> depends
> > on) are enabled in Fenix yet, as we have outstanding bugs about "only
> > download this stuff when on WiFi + Power" and "that, but configurable."
>
> If the delta updates are averaging 66 KB, do we really need to avoid
> the updates over cellular data even when that's assumed to be metered?
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabled CRLite in Nightly

[J.C. Jones]

Aha, I knew I left something out.

Not yet, no. Neither this nor Intermediate Preloading (which CRLite depends
on) are enabled in Fenix yet, as we have outstanding bugs about "only
download this stuff when on WiFi + Power" and "that, but configurable."

But yes, both CRLite and Intermediate Preloading will be, one day, a boon
to the Fenix architecture, too.

J.C.

On Thu, Nov 12, 2020 at 4:30 PM asf...@mozilla.com 
wrote:

> That's great to hear!
>
> Does that include Firefox Nightly for Android too?
>
> On Wednesday, November 11, 2020 at 4:15:17 PM UTC-8, Martin Thomson wrote:
> > Great news JC.
> >
> > I've been watching this with interest. It's one of those rare cases
> > where we get a win-win-win. Faster page loads, better security
> > through more reliable revocation information, and better privacy.
> >
> > It's taken a lot of effort, but it's definitely worth it.
> > On Thu, Nov 12, 2020 at 8:08 AM J.C. Jones  wrote:
> > >
> > > CRLite ships compressed revocation information for the public Web to
> > > Firefox users, four times a day. We have a blogpost series on CRLite
> at the
> > > Security Blog <https://blog.mozilla.org/security/tag/crlite/> (with
> another
> > > post coming later this month), there’s additional information at
> Github
> > > <https://github.com/mozilla/crlite>, and for the Gecko-side, a
> meta-bug
> > > <https://bugzilla.mozilla.org/show_bug.cgi?id=crlite>.
> > >
> > > We’ve been collecting telemetry on how much CRLite can speed up first
> TLS
> > > connections
> > > <
> https://blog.mozilla.org/security/2020/01/21/crlite-part-3-speeding-up-secure-browsing/>
>
> > > all year. Since August, we’ve been publishing the datasets
> consistently
> > > four times per day, with “stashes” (delta updates) averaging about 66
> kB. (
> > >
> https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters
> > > )
> > >
> > > If you’d like to poke around inside the filter data, see
> > >
> https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter
> > >
> > > Nightly is now preferring CRLite <https://github.com/mozilla/crlite>
> for
> > > revocation information, meaning fresh TLS connections will skip OCSP
> when
> > > CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
> > > “Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
> > > telemetry: it’s mostly expected to speed up the outliers in the graph,
> > > since revocation checks get cached, and it is likely to have the
> largest
> > > effects for Firefox users with slower network connections.
> > >
> > > We don’t expect breakage from this change, as we’ve grown fairly
> confident
> > > in the dataset, but this is going to remain in Nightly for now.
> > >
> > > After this speed-up testing, our likely next step is to add telemetry
> to
> > > compare live OCSP results against CRLite’s results for
> outlier-accuracy
> > > (encountering revocations is rare, so care is needed). We’ll
> ultimately run
> > > both the accuracy and the speedup tests in early Beta as well.
> > >
> > > We’ll develop Release-path plans based on early Beta testing and
> telemetry.
> > >
> > > For more information, come see us in #crlite in Slack or #crlite:
> mozilla.org
> > > on Matrix
> > > <
> https://matrix.to/#/!zSwoVqWeXUHRiaIFvk:mozilla.org?via=mozilla.org&via=matrix.org>
>
> > > .
> > >
> > > - J.C. on behalf of Mozilla Crypto Engineering
> > > ___
> > > dev-platform mailing list
> > > dev-pl...@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

Enabled CRLite in Nightly

[J.C. Jones]

CRLite ships compressed revocation information for the public Web to
Firefox users, four times a day. We have a blogpost series on CRLite at the
Security Blog  (with another
post coming later this month), there’s additional information at Github
, and for the Gecko-side, a meta-bug
.

We’ve been collecting telemetry on how much CRLite can speed up first TLS
connections

all year. Since August, we’ve been publishing the datasets consistently
four times per day, with “stashes” (delta updates) averaging about 66 kB. (
https://github.com/mozilla/crlite/wiki#how-can-i-access-statistics-about-the-available-filters
)

If you’d like to poke around inside the filter data, see
https://github.com/mozilla/crlite/wiki#how-can-i-query-my-crlite-filter

Nightly is now preferring CRLite  for
revocation information, meaning fresh TLS connections will skip OCSP when
CRLite can substitute. (e.g., we set security.pki.crlite_mode to 2,
“Enforce”). We expect to see improvement in the SSL_TIME_UNTIL_READY
telemetry: it’s mostly expected to speed up the outliers in the graph,
since revocation checks get cached, and it is likely to have the largest
effects for Firefox users with slower network connections.

We don’t expect breakage from this change, as we’ve grown fairly confident
in the dataset, but this is going to remain in Nightly for now.

After this speed-up testing, our likely next step is to add telemetry to
compare live OCSP results against CRLite’s results for outlier-accuracy
(encountering revocations is rare, so care is needed). We’ll ultimately run
both the accuracy and the speedup tests in early Beta as well.

We’ll develop Release-path plans based on early Beta testing and telemetry.

For more information, come see us in #crlite in Slack or #crlite:mozilla.org
on Matrix

.

- J.C. on behalf of Mozilla Crypto Engineering
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web Authentication Working Group

[J.C. Jones]

The additional time for the WebAuthn working group is overall good and
worth supporting. The bulk of the additional work to be done is focused on
improving the ergonomics of the existing Level 1 spec, both for developers
and for individuals using the capabilities within their lives.


On Wed, Sep 18, 2019 at 9:48 AM L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   Web Authentication Working Group
>   https://www.w3.org/2019/08/webauthn-proposed-charter.html
>   https://lists.w3.org/Archives/Public/public-new-work/2019Sep/0001.html
>
> The differences from the previous charter are:
>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2017%2F08%2Fweb-authentication-charter.html&doc2=https%3A%2F%2Fwww.w3.org%2F2019%2F08%2Fwebauthn-proposed-charter.html
>
> Mozilla has the opportunity to send comments or objections through
> Monday, September 30.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
> ___
> 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]

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

Intent-to-Unship: DH algorithm support for WebCrypto

[J.C. Jones]

Our WebCrypto implementation supports using DH as an algorithm in
generateKey, which is not one of the recognized algorithms in the
published specification [0]. It doesn't even appear on MDN [2].

I intend to remove it from Firefox. However, before I do that, I am
landing telemetry [1] to determine whether it’s seeing use, at least
among our Nightly population. Given the relatively small sample, if we
get very low usage, that tells us nothing. However, if we do see
significant usage, we’ll have to be more careful in our plans.

My guess, since DH support is Firefox-only, is that after gathering
telemetry in the 68 cycle, we will unship in 69, unless further
information from Beta 68 causes us to revise course. I’ll plan to
update this thread as we learn more.

[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1539578
[2] https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey
___
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

[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: Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

That's a good argument for us never "optimizing" it to avoid re-downloading
already-known certs. Just download the whole set once, everywhere - the
bandwidth savings are limited.

On Fri, Mar 15, 2019 at 9:19 AM Tom Ritter  wrote:

> On Thu, Mar 14, 2019 at 3:26 PM Nicholas Alexander
>  wrote:
> > J.C. -- I don't think this answers Tom's question, but perhaps it does.
> In that case I'll ask what I think is the same question:
>
> Actually, what I was worried about was Mozilla being able to track
> users based on what the client sends.
>
> "I've got 100-200, send me some more"
> "I've got 100-300, send me some more"
> and so on
>
> It sounds like The client says something more like "Send me 200-300",
> "Send me 300-400".  Which is not _that_ much different, but it
> slightly better I think...
>
> -tom
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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 API in Firefox, 

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

Nicholas,

Mozilla's root program mandates all members disclose all intermediates via
the Common CA Database <https://ccadb.org/>. That database has enough
metadata to determine which CA certificates chain to roots in our program.
The CCADB exports a list on-demand <https://ccadb.org/resources> of all
intermediates that are disclosed and in our program (Note, the
Mozilla-speciifc one isn't linked there, contact me off-list if you want
access). As part of our CRLite server-side code, we're packaging up that
list of intermediates regularly and update Kinto. Obviously they don't
change quickly. :)

By policy, Firefox users should not encounter any undisclosed intermediate
CAs that are trusted via a root in our root program. In principal, we could
eventually use this functionality to affirm that.

Cheers!
J.C.



On Thu, Mar 14, 2019 at 8:26 AM Nicholas Alexander 
wrote:

>
>
> On Wed, Mar 13, 2019 at 2:23 PM J.C. Jones  wrote:
>
>> Tom,
>>
>> Kinto provides the whole list of metadata to clients as soon as it syncs
>> [1].  The metadata uses the Kinto attachment
>> <https://github.com/Kinto/kinto-attachment> mechanism to store the
>> DER-encoded certificate for separate download.
>>
>> Firefox maintains a "local field" boolean in the dataset to of whether a
>> given metadata entry's certificate attachment has been downloaded or not,
>> toggling as each one is pulled. Currently we don't deduplicate with the
>> local NSS Cert DB, the inserts that are already there will fail and emit
>> telemetry -- the amount of data saved didn't seem worth it for the
>> experimental phase.
>>
>
> J.C. -- I don't think this answers Tom's question, but perhaps it does.
> In that case I'll ask what I think is the same question:
>
> How is the set of certificates that _might_ be pushed to clients
> determined?  In some way we must determine a set of relevant intermediate
> certificates: how do we determine that set?  Is it that the set of
> intermediates for every CA that we trust is known?
>
> Nick
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

Tom,

Kinto provides the whole list of metadata to clients as soon as it syncs
[1].  The metadata uses the Kinto attachment
<https://github.com/Kinto/kinto-attachment> mechanism to store the
DER-encoded certificate for separate download.

Firefox maintains a "local field" boolean in the dataset to of whether a
given metadata entry's certificate attachment has been downloaded or not,
toggling as each one is pulled. Currently we don't deduplicate with the
local NSS Cert DB, the inserts that are already there will fail and emit
telemetry -- the amount of data saved didn't seem worth it for the
experimental phase.

Thanks!

[1]
https://settings.prod.mozaws.net/v1/buckets/security-state/collections/intermediates/records

On Wed, Mar 13, 2019 at 10:22 AM Tom Ritter  wrote:

> How does kinto know which certificates you yet need to download?
>
> On Fri, Mar 8, 2019, 3:29 PM J.C. Jones  wrote:
>
>> # tl;dr #
>>
>> At the end of February I enabled Intermediate CA Preloading for all
>> desktop Nightly users to begin gathering telemetry. This means all
>> intermediate CAs disclosed to Mozilla will be pre-loaded into
>> profiles, so the common secure website misconfiguration of forgetting
>> this certificate won’t stop Firefox users. It has other benefits, too,
>> but for those read on.
>>
>>
>>
>>
>> In Bug 1404934 we've added support to download the Intermediate
>> Certificate Authorities that have been disclosed to the Mozilla CA
>> Root Program from Kinto in the background during normal Firefox
>> operation. I turned this on for all desktop nightly users a bit more
>> than a week ago, prompting Nightly users to download 100 intermediate
>> CA certs into their profile each day. I do not have a timeline at
>> present for this to ride the trains.
>>
>>
>> # What it does #
>>
>> Websites using encryption should provide two digital PKI certificates
>> [0] when connecting to clients: One for the website itself, and one
>> for the intermediate CA that produced the website's digital
>> certificate. Sometimes, websites are set up incorrectly.
>>
>>
>> When other browsers encounter this case, they use AIA-chasing, a
>> mechanism where the user's browser then, in the background, connects
>> to the CA and downloads the certificate during the TLS handshake.
>>
>> ## Performance benefit ##
>>
>> Preloading the intermediate CA data avoids the just-in-time network
>> fetch, which delays the connection.
>>
>> ## Privacy ##
>>
>> Avoiding the network fetch is also a privacy improvement, as it
>> doesn't disclose your browsing pattern to the certificate authority
>> that issued the misconfigured website's certificate.
>>
>> It's also helpful because it's possible to "fingerprint" a user by a
>> website carefully analyzing what other websites load or do not load
>> due to which intermediate CAs have been "seen" by a user [1].
>> Preloading ensures that all users have "seen" all the same
>> intermediate CAs.
>>
>> ## Protection ##
>>
>> The Mozilla CA program requires all members to disclose unconstrained
>> intermediate CAs before using them, as a safety measure. However,
>> there is not currently a way to technically enforce that. Intermediate
>> Preloading could eventually be used to perform that enforcement, by
>> only trusting intermediate CAs which were disclosed already. This
>> protects against a scenario where a compromised CA is coerced into
>> producing an undisclosed secret intermediate CA, which is then used to
>> attack people on the Internet.
>>
>>
>> ## Future usefulness ##
>>
>> The experimental CRLite concept [2] (aiming to replace OCSP) requires
>> a mapping of Intermediate CAs to an “enrollment status” flag. Since we
>> need to enumerate the Intermediate CAs for that future functionality,
>> actually preloading their data is a rational extension.
>>
>>
>> # How it works #
>>
>> Intermediate Preloading fetches ~100 intermediate certificate
>> authorities' certificates once a day during the Kinto main update [3],
>> and loads them into your profile, as if you had visited a site that
>> used that intermediate. At 100 per day, summing to between 300-500 kB,
>> it will take approximately three weeks for a Firefox profile to
>> preload all intermediates [4]. We will likely increase the rate after
>> the initial experiments.
>>
>> The certificate data is loaded into the NSS Certificate Database, as
>> is done for normal web 

Intermediate CA Preloading is enabled for desktop Nightly users

[J.C. Jones]

# tl;dr #

At the end of February I enabled Intermediate CA Preloading for all
desktop Nightly users to begin gathering telemetry. This means all
intermediate CAs disclosed to Mozilla will be pre-loaded into
profiles, so the common secure website misconfiguration of forgetting
this certificate won’t stop Firefox users. It has other benefits, too,
but for those read on.




In Bug 1404934 we've added support to download the Intermediate
Certificate Authorities that have been disclosed to the Mozilla CA
Root Program from Kinto in the background during normal Firefox
operation. I turned this on for all desktop nightly users a bit more
than a week ago, prompting Nightly users to download 100 intermediate
CA certs into their profile each day. I do not have a timeline at
present for this to ride the trains.


# What it does #

Websites using encryption should provide two digital PKI certificates
[0] when connecting to clients: One for the website itself, and one
for the intermediate CA that produced the website's digital
certificate. Sometimes, websites are set up incorrectly.


When other browsers encounter this case, they use AIA-chasing, a
mechanism where the user's browser then, in the background, connects
to the CA and downloads the certificate during the TLS handshake.

## Performance benefit ##

Preloading the intermediate CA data avoids the just-in-time network
fetch, which delays the connection.

## Privacy ##

Avoiding the network fetch is also a privacy improvement, as it
doesn't disclose your browsing pattern to the certificate authority
that issued the misconfigured website's certificate.

It's also helpful because it's possible to "fingerprint" a user by a
website carefully analyzing what other websites load or do not load
due to which intermediate CAs have been "seen" by a user [1].
Preloading ensures that all users have "seen" all the same
intermediate CAs.

## Protection ##

The Mozilla CA program requires all members to disclose unconstrained
intermediate CAs before using them, as a safety measure. However,
there is not currently a way to technically enforce that. Intermediate
Preloading could eventually be used to perform that enforcement, by
only trusting intermediate CAs which were disclosed already. This
protects against a scenario where a compromised CA is coerced into
producing an undisclosed secret intermediate CA, which is then used to
attack people on the Internet.


## Future usefulness ##

The experimental CRLite concept [2] (aiming to replace OCSP) requires
a mapping of Intermediate CAs to an “enrollment status” flag. Since we
need to enumerate the Intermediate CAs for that future functionality,
actually preloading their data is a rational extension.


# How it works #

Intermediate Preloading fetches ~100 intermediate certificate
authorities' certificates once a day during the Kinto main update [3],
and loads them into your profile, as if you had visited a site that
used that intermediate. At 100 per day, summing to between 300-500 kB,
it will take approximately three weeks for a Firefox profile to
preload all intermediates [4]. We will likely increase the rate after
the initial experiments.

The certificate data is loaded into the NSS Certificate Database, as
is done for normal web browsing. In the future, we will use the faster
Rust "rkv" database, in Bug 1530545.

Currently preloading is only enabled for desktop users on Nightly. We
will want to (A) restrict the download to be only over WiFi and maybe
plugged in, and (B) switch to the faster database before enabling on
mobile. (Bug 1520297)


# What we expect #

Intermediate Preloading should reduce the number of
SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which
is our most common secure connection error. It will also remove the
tracking vector (above, Privacy), and give us a path to enforce CA
disclosure.


# Things to keep in mind #

Right now, these certificates go into the NSS Certificate Database,
and are visible in / totally overcrowding the Certificate Manager (Go
To about:preferences#privacy , View Certificates.., Authorities tab).
That’ll change when this moves to rkv.

This is potentially a bunch of data, approximately 3 megabytes of
binary, but it’s data that changes only very slowly.


# Telemetry #

Telemetry for Intermediate Preloading is available in the histograms:

  "INTERMEDIATE_PRELOADING_ERRORS"
  "INTERMEDIATE_PRELOADING_UPDATE_TIME_MS"

and the scalars:

  "security.intermediate_preloading_num_pending"
  "security.intermediate_preloading_num_preloaded"

... which show how many of the ~2300 intermediates have been loaded,
per profile.

# More info #

Well, maybe. ;) There's a wiki page about this which can be used to
help explain the same things as are in this post. Otherwise, send your
questions to me, Mark Goodwin, or Dana Keeler.

https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading

:: Footnotes::

[0] The WebPKI generally has one root CA certificate, one inte

Re: W3C Proposed Recommendation: Web Authentication

[J.C. Jones]

Out of all multi-factor authentication solutions I know of, Web
Authentication is our best technical response to the scourge of phishing.
Tying public-key cryptography into web logins, it dramatically raises the
bar for phishing: From a simple confusable website and replay attack, to an
HTTPS network man-in-the-middle. In practice, Web Authentication forces
adversaries to move to attack account recovery methods, which often have
stronger controls than a standard login.

The specification is large
, with many backward
compatibility pieces that Firefox is likely to never need to implement. The
compatibility pieces are useful for providing the installed base of
existing FIDO or TCG devices a path forward. The core website functions
aren't so complex; Duo's explainer is very good, at https://webauthn.guide/
. There's also forward-extensibility, leading toward a password-less future
built on digital signatures rather than disclosing shared secrets.

Web Authentication is now supported by Edge, Firefox, and Chrome. Safari
support is experimental.

Websites have been slower to pick it up. Major sites I now of: For the
United States, https://login.gov/ uses it -- so as an example applying for
the Global Entry traveler program will exercise a Web Authentication
security key, if you choose. Dropbox

has also supported Web Authentication since Firefox 60 shipped.

Most other major properties have indicated they'll support Web
Authentication sooner or later. Try it out at at https://webauthn.io/,
https://webauthndemo.appspot.com/, https://demo.yubico.com/webauthn/, or
even the lowly https://webauthn.bin.coffee/.

I encourage Mozilla to support advancement of Web Authentication to a
Recommendation, and its end-goal of a phishing-free future. (Or at least, a
much-reduced prevalence.  Really, I just wanted to write and imagine
'phishing-free.' Can you blame me?)

Cheers,
J.C.
[n.b., I'm an editor on this spec...]



On Thu, Jan 31, 2019 at 5:58 PM L. David Baron  wrote:

> A W3C Proposed Recommendation is available for the membership of
> W3C (including Mozilla) to vote on, before it proceeds to the final
> stage of being a W3C Recomendation:
>
>   Web Authentication
>   https://www.w3.org/TR/webauthn/
>   Deadline for responses: Thursday, February 14, 2019
>
> If there are comments you think Mozilla should send as part of the
> review, please say so in this thread.  Ideally, such comments should
> link to github issues filed against the specification.  (I'd note,
> however, that there have been previous opportunities to make
> comments, so it's somewhat bad form to bring up fundamental issues
> for the first time at this stage.)
>
> Given that we implement this specification, one of the editors works
> for us, and have been supporting this work for a while, I'm assuming
> we should support this advancement as well...
>
> -David
>
> --
> 𝄞   L. David Baron http://dbaron.org/   𝄂
> 𝄢   Mozilla  https://www.mozilla.org/   𝄂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
> ___
> 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: Moving reviews to Phabricator

[J.C. Jones]

The NSS team still uplifts from https://hg.mozilla.org/projects/nss/ into
m-c 
a few times per week (or as needed) using inbound
.
That's mostly a function of those uplifts being r=me, as they already were
reviewed in the NSS repo.

There's nothing technically stopping me from using Phabricator for those
uplifts; they'd just need an additional (perfunctory) review sign-off.



On Fri, Feb 8, 2019 at 7:08 AM Andreas Tolfsen  wrote:

> Also sprach Kim Moir:
>
> > Requiring Phabricator for code reviews will allow us to improve
> > code quality by running linters and static analysis tools automatically
> > on patches.  It will also allow us to simplify and standardize our
> > engineering workflow by reducing the number of request queues that
> > developers are expected to monitor.
>
> Are there any firm plans to also reduce the number of integration
> queues?
>
> With this change, which products/teams are still relying on r+/r-
> and inbound?
>
> Whilst I don’t have first hand experience, Phabricator has been
> known to struggle with large patches, such as the result of upgrading
> cargo dependencies under third_party/rust.  Was a bug ever filed
> on this?
>
> ___
> 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

[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

[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

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

[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: Intent to Ship: Web Authentication

[J.C. Jones]

On Wed, Dec 6, 2017 at 10:24 AM, James Graham 
wrote:

> Are the web-platform-tests going to be done before we ship?
>

I hope so, though as-of-now no one from Mozilla is contributing to the
web-platform-tests [1]. Originally some FIDO Alliance-associated folk were
going to take the lead on them, but I've not been tracking it.


> For my information, what was missing from wpt that meant you had to write
> mochitests? (I don't doubt that there are good reasons, it's just
> understanding what they are helps shape future work).
>

I think most everything except the tests for tab-switch and maybe some of
the more exotic cross-origin behaviors can move to web-platform-tests, and
I hope that our existing mochitest logic can be mostly ported over there.
The only reason for not doing these as web-platform-tests to begin with was
cross-company communication inefficiencies. I fully expect this to be
remedied in 2018.

[1] https://github.com/w3c/web-platform-tests/tree/master/webauthn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: Web Authentication

[J.C. Jones]

Summary: Support public key cryptographic authentication devices
through Web Authentication.

Web Authentication is backward compatible with FIDO U2F second-factor
tokens, and also supports more advanced capabilities in future FIDO
2.0 devices. We intend to ship support for USB-connected FIDO U2F
devices initially, with other transports and FIDO 2.0 device support
to follow in 2018.

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

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

(Note that the latest working draft,
https://www.w3.org/TR/2017/WD-webauthn-20171205/, is considered by the
WG to be feature complete, and no more normative changes are
anticipated.)

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 [1]
- Edge: In-progress [2]
- Webkit: No public announcements

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


Cheers,
J.C. Jones and Tim Taubert

[1] https://www.chromestatus.com/feature/5669923372138496
[2] https://msdn.microsoft.com/en-us/library/mt697638(v=vs.85).aspx
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[J.C. Jones]

Tom,

We're making progress on supporting the USB U2F HID token attestation
format; before the actual U2F/HID code starts appearing in-tree, there's
had to be some refactoring to handle things in a proper asynchronous way --
which is nearing review.

I'm working on that USB U2F support for OSX right now; Linux support is
also looking pretty OK, and we're planning to get Windows this quarter, too.

Independently, we're waiting on updating our Web Authentication
implementation from the WD-02 version currently in-tree, expecting a
significant refactor to happen aligning the way you use Web Authentication
with the W3C Credential Management specification. There's ongoing
discussion [1] and currently one pull request [2] to do that. That's
primarily why we haven't moved forward to the WD-04 draft yet - and we're
working on the HID support.

That said, we're still planning on exposing the USB U2F security key-type
devices only through the W3C Web Authentication API by default -- the older
FIDO U2F API that is currently hidden behind the `security.webauth.u2f`
preference [3] we're currently planning to keep hidden. It doesn't
implement the "Low-level MessagePort API", which makes a some sites that
depend on Chrome's u2f-api.js behave oddly.


[1] https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0162.html
[2] https://github.com/w3c/webauthn/pull/384
[3] (and also the `security.webauth.u2f_enable_softtoken` preference, since
there's no USB support in-tree yet)

Cheers,
J.C.

On Tue, Apr 11, 2017 at 5:05 AM, Tom Schuster  wrote:

> So what's our status with regards to implementing FIDO u2f? I really would
> like to use my security key natively in Firefox.
>
> Best,
> Tom
>
> On Sat, Dec 3, 2016 at 5:47 AM, Anders Rundgren <
> anders.rundgren@gmail.com> wrote:
>
> > On Friday, December 2, 2016 at 10:27:30 PM UTC+1, JC Jones wrote:
> > > Anders,
> > >
> > > The first target I'm working on is Desktop, though I've plans in 2017
> to
> > > support WebAuthn on Android and iOS [1], too. WebAuthn already has
> > > definitions suitable for Android's Key Attestation [2] and SafetyNet
> > > formats [3], so they'll need implementations that tie into the
> > > dom::WebAuthentication class.
> >
> > That's great news!
> >
> > Regards,
> > Anders
> >
> > >
> > > Cheers,
> > > J.C.
> > >
> > > [1] https://wiki.mozilla.org/Security/CryptoEngineering#
> > Web_Authentication
> > > [2] https://w3c.github.io/webauthn/#android-key-attestation
> > > [3] https://w3c.github.io/webauthn/#android-safetynet-attestation
> > >
> > > On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
> > > anders.rundgren@gmail.com> wrote:
> > >
> > > > On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren
> > wrote:
> > > > > It is a pity that external tokens have become the
> > > > > focus when the majority will rather rely on embedded
> > > > > security solutions which nowadays is a standard feature
> > > > > in Android and Windows platforms.
> > > >
> > > > Slight clarification to the above: The IoT folks pretty much build
> > 100% on
> > > > embedded security with car-keys as an obvious exception.
> > > >
> > > > On mobile I would say that over 99% of all existing security
> solutions
> > > > based on cryptographic keys are relying on embedded (or "App level")
> > keys
> > > > with Apple Pay as the most advanced example.
> > > >
> > > > That is, the token vendors and security folks do not represent the
> > actual
> > > > market comprising of end-users and service providers.
> > > >
> > > > Maybe this is a project primarily targeting the desktop?
> > > > ___
> > > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Web Authentication

[J.C. Jones]

Anders,

The first target I'm working on is Desktop, though I've plans in 2017 to
support WebAuthn on Android and iOS [1], too. WebAuthn already has
definitions suitable for Android's Key Attestation [2] and SafetyNet
formats [3], so they'll need implementations that tie into the
dom::WebAuthentication class.

Cheers,
J.C.

[1] https://wiki.mozilla.org/Security/CryptoEngineering#Web_Authentication
[2] https://w3c.github.io/webauthn/#android-key-attestation
[3] https://w3c.github.io/webauthn/#android-safetynet-attestation

On Wed, Nov 30, 2016 at 10:54 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:

> On Wednesday, November 30, 2016 at 5:42:30 PM UTC+1, Anders Rundgren wrote:
> > It is a pity that external tokens have become the
> > focus when the majority will rather rely on embedded
> > security solutions which nowadays is a standard feature
> > in Android and Windows platforms.
>
> Slight clarification to the above: The IoT folks pretty much build 100% on
> embedded security with car-keys as an obvious exception.
>
> On mobile I would say that over 99% of all existing security solutions
> based on cryptographic keys are relying on embedded (or "App level") keys
> with Apple Pay as the most advanced example.
>
> That is, the token vendors and security folks do not represent the actual
> market comprising of end-users and service providers.
>
> Maybe this is a project primarily targeting the desktop?
> ___
> 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

Fwd: Intent to implement and ship: Web Authentication

[J.C. Jones]

Apologies, this got caught in a filter. Re-sending for posterity on the
list.
-- Forwarded message --
From: J.C. Jones
Date: Tue, Nov 15, 2016 at 12:01 PM
Subject: Re: Intent to implement and ship: Web Authentication
To: berniepa...@gmail.com
Cc: dev-platform@lists.mozilla.org


Hey Bernie,

That's one possibility, but I expect WebAuthn to support the U2F
attestation payloads in its MakeCredential and GetAssertion calls, and then
Firefox will implement the U2F HID protocol initially rather than jumping
to CTAP v1.1.

Cheers,
J.C.

On Mon, Nov 14, 2016 at 6:08 PM,  wrote:

> Le lundi 14 novembre 2016 22:41:37 UTC+1, berni...@gmail.com a écrit :
> > Le lundi 14 novembre 2016 18:34:11 UTC+1, JC Jones a écrit :
> > > Bernie,
> > >
> > > You're right that the current WD does not contain the "U2F HID token"
> > > attestation format, but the WG is _intending_ to add it [1] -- and
> support
> > > for such devices -- in Working Draft 4 [2] as soon as a larger
> in-document
> > > refactor is complete.
> > >
> > > I won't guarantee success at this point, but I believe it likely that
> > > WebAuthn will ultimately support most fielded U2F HID-compliant
> devices.
> > >
> > > [1] https://github.com/w3c/webauthn/issues/214
> > > [2] https://github.com/w3c/webauthn/milestone/8
> > >
> > > Cheers!
> > > J.C.
> > >
> > >
> > >
> > > On Sun, Nov 13, 2016 at 4:36 PM, Bernie wrote:
> > >
> > > > Le vendredi 11 novembre 2016 22:18:58 UTC+1, JC Jones a écrit :
> > > > > The W3C Web Authentication Working Group [1] was formed to produce
> a
> > > > > browser-facing standard for using strong, cryptographic scoped
> > > > credentials
> > > > > to authenticate to web applications in an un-phishable way. The
> Working
> > > > > Group began working from specifications produced by the FIDO
> Alliance,
> > > > but
> > > > > through the W3C process ensured there was a web-focus to the final
> > > > result.
> > > > >
> > > > > We have been tracking the Web Authentication standard since last
> year’s
> > > > > FIDO U2F announcement [2],  and we believe Web Authentication
> provides a
> > > > > valuable augmentation to web application security in an inclusive
> way. We
> > > > > are proposing to implement the current draft specification for Web
> > > > > Authentication [3], and then track the evolution through to its
> final
> > > > > Recommendation state.
> > > > >
> > > > > Background: The Mozilla Foundation joined the FIDO Alliance to
> support
> > > > the
> > > > > work of providing augmented security to user logins across the
> Web. We
> > > > > encouraged FIDO to evolve their browser specifications within the
> W3C, to
> > > > > enable larger community involvement than simply Alliance members.
> This
> > > > > specification is a result of that wider effort.
> > > > >
> > > > > Web Authentication defines a way to use credentials from a secure
> element
> > > > > to authenticate to web applications using public key cryptography.
> As
> > > > with
> > > > > FIDO U2F, the browser’s role is mainly to provide the interface
> between
> > > > the
> > > > > secure element (such as a USB dongle) and the web application, and
> to
> > > > > enforce a scoped security model to bind the resulting attestation
> to the
> > > > > specific web application.
> > > > >
> > > > > Web Authentication support is currently in development for
> Microsoft Edge
> > > > > [4] [5]. Google Chrome’s support is also in-development.  Several
> > > > websites
> > > > > have deployed support for U2F, the predecessor to WebAuthn,
> including
> > > > > Gmail, Dropbox, and Github. Additionally, there are many U2F
> devices in
> > > > use
> > > > > today which will function with the Web Authentication API.
> > > > >
> > > > > Proposed: To implement the Web Authentication API, with support
> for the
> > > > USB
> > > > > U2F HID token attestation format.
> > > > >
> > > > > Please send comments on this proposal to the list no later than 21
> > > > November
> > > > > 2016.
> > > > >
>

Re: Intent to implement and ship: Web Authentication

[J.C. Jones]

Bernie,

You're right that the current WD does not contain the "U2F HID token"
attestation format, but the WG is _intending_ to add it [1] -- and support
for such devices -- in Working Draft 4 [2] as soon as a larger in-document
refactor is complete.

I won't guarantee success at this point, but I believe it likely that
WebAuthn will ultimately support most fielded U2F HID-compliant devices.

[1] https://github.com/w3c/webauthn/issues/214
[2] https://github.com/w3c/webauthn/milestone/8

Cheers!
J.C.



On Sun, Nov 13, 2016 at 4:36 PM,  wrote:

> Le vendredi 11 novembre 2016 22:18:58 UTC+1, JC Jones a écrit :
> > The W3C Web Authentication Working Group [1] was formed to produce a
> > browser-facing standard for using strong, cryptographic scoped
> credentials
> > to authenticate to web applications in an un-phishable way. The Working
> > Group began working from specifications produced by the FIDO Alliance,
> but
> > through the W3C process ensured there was a web-focus to the final
> result.
> >
> > We have been tracking the Web Authentication standard since last year’s
> > FIDO U2F announcement [2],  and we believe Web Authentication provides a
> > valuable augmentation to web application security in an inclusive way. We
> > are proposing to implement the current draft specification for Web
> > Authentication [3], and then track the evolution through to its final
> > Recommendation state.
> >
> > Background: The Mozilla Foundation joined the FIDO Alliance to support
> the
> > work of providing augmented security to user logins across the Web. We
> > encouraged FIDO to evolve their browser specifications within the W3C, to
> > enable larger community involvement than simply Alliance members. This
> > specification is a result of that wider effort.
> >
> > Web Authentication defines a way to use credentials from a secure element
> > to authenticate to web applications using public key cryptography. As
> with
> > FIDO U2F, the browser’s role is mainly to provide the interface between
> the
> > secure element (such as a USB dongle) and the web application, and to
> > enforce a scoped security model to bind the resulting attestation to the
> > specific web application.
> >
> > Web Authentication support is currently in development for Microsoft Edge
> > [4] [5]. Google Chrome’s support is also in-development.  Several
> websites
> > have deployed support for U2F, the predecessor to WebAuthn, including
> > Gmail, Dropbox, and Github. Additionally, there are many U2F devices in
> use
> > today which will function with the Web Authentication API.
> >
> > Proposed: To implement the Web Authentication API, with support for the
> USB
> > U2F HID token attestation format.
> >
> > Please send comments on this proposal to the list no later than 21
> November
> > 2016.
> >
> > [1] https://www.w3.org/blog/webauthn/
> >
> > [2] https://groups.google.com/d/msg/mozilla.dev.platform/
> > IVGEJnQW3Uo/Eu5tvyLmCgAJ
> >
> > [3] https://www.w3.org/TR/webauthn/
> >
> > [4] https://blogs.windows.com/msedgedev/2016/04/12/a-world-
> > without-passwords-windows-hello-in-microsoft-edge/#XKWsxS6PwLOtBYrG.97
> >
> > [5] https://developer.microsoft.com/en-us/microsoft-edge/
> platform/status/
> > webauthenticationapi/?q=webauth
> >
> > - J.C., Crypto Engineering
>
> Hi,
>
> the company I am working for is a small member of the the FIDO alliance.
> We are offering our own U2F USB HID tokens (and soon U2F BLE devices...)
>
> As far as I know, there are still several debates inside the Alliance but
> until recently it was never clearly stated that present U2F tokens/devices
> will be compatible with the next W3C WebAuthN (I rather understood the
> contrary as thre was nothing about this point inside the public w3C drafts)
>
> So, do you have new/other information to back your proposition :
> "Proposed: To implement the Web Authentication API, with support for the
> USB
> U2F HID token attestation format."
>
> Did I miss something ? (that's possible, communication is kind of messy
> inside the Alliance...)
> ___
> 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: Web Authentication

[J.C. Jones]

The W3C Web Authentication Working Group [1] was formed to produce a
browser-facing standard for using strong, cryptographic scoped credentials
to authenticate to web applications in an un-phishable way. The Working
Group began working from specifications produced by the FIDO Alliance, but
through the W3C process ensured there was a web-focus to the final result.

We have been tracking the Web Authentication standard since last year’s
FIDO U2F announcement [2],  and we believe Web Authentication provides a
valuable augmentation to web application security in an inclusive way. We
are proposing to implement the current draft specification for Web
Authentication [3], and then track the evolution through to its final
Recommendation state.

Background: The Mozilla Foundation joined the FIDO Alliance to support the
work of providing augmented security to user logins across the Web. We
encouraged FIDO to evolve their browser specifications within the W3C, to
enable larger community involvement than simply Alliance members. This
specification is a result of that wider effort.

Web Authentication defines a way to use credentials from a secure element
to authenticate to web applications using public key cryptography. As with
FIDO U2F, the browser’s role is mainly to provide the interface between the
secure element (such as a USB dongle) and the web application, and to
enforce a scoped security model to bind the resulting attestation to the
specific web application.

Web Authentication support is currently in development for Microsoft Edge
[4] [5]. Google Chrome’s support is also in-development.  Several websites
have deployed support for U2F, the predecessor to WebAuthn, including
Gmail, Dropbox, and Github. Additionally, there are many U2F devices in use
today which will function with the Web Authentication API.

Proposed: To implement the Web Authentication API, with support for the USB
U2F HID token attestation format.

Please send comments on this proposal to the list no later than 21 November
2016.

[1] https://www.w3.org/blog/webauthn/

[2] https://groups.google.com/d/msg/mozilla.dev.platform/
IVGEJnQW3Uo/Eu5tvyLmCgAJ

[3] https://www.w3.org/TR/webauthn/

[4] https://blogs.windows.com/msedgedev/2016/04/12/a-world-
without-passwords-windows-hello-in-microsoft-edge/#XKWsxS6PwLOtBYrG.97

[5] https://developer.microsoft.com/en-us/microsoft-edge/platform/status/
webauthenticationapi/?q=webauth

- J.C., Crypto Engineering
___
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:

> 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