Intent to ship: WebCrypto API

[Tim Taubert]

As of September we intend to enable the WebCrypto API by default on all
platforms. It has been developed behind the dom.webcrypto.enabled
preference.

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

Spec:
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
(A CR is planned soon, only smaller changes to the spec lately.)

Reasoning:
The implementation of the WebCrypto API has made lots of progress in
Firefox 33+34. We added most of the basic functionality and algorithms,
and should be mostly spec compliant.

Chromium has had the WebCrypto API enabled by default since Crome 37,
which was released in late June 2014. Their implementation supports a
subset of the algorithms that we do, and has roughly the same level of
spec compliance. We expect the two implementations to be mostly
interoperable as-is, with some fine points being ironed out as the spec
is finalized.

We thus propose to enable the WebCrypto API by default for all platforms
to get some more feedback from developers and give them the opportunity
to use new functionality.

- Tim

[Ehsan Akhgari]

I'm excited to see this finally happen!

Can you please clarify what are the areas that we don't fully adhere to
the spec? Do we expect the fixes to those and potentially new spec
issues in the future to break backwards compatibility?

Thanks!
Ehsan

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

[helpcrypto helpcrypto]

I'll love to know if Mozilla/Firefox is going to provide something (even
out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.

This will fill the gap that currently exist with hardware token support
(which, is going to be discussed nexr 10th September)
Regards.

[Dirkjan Ochtman]

On Wed, Sep 3, 2014 at 7:36 PM, Tim Taubert <ttau...@mozilla.com> wrote:
> Chromium has had the WebCrypto API enabled by default since Crome 37,
> which was released in late June 2014. Their implementation supports a
> subset of the algorithms that we do, and has roughly the same level of
> spec compliance. We expect the two implementations to be mostly
> interoperable as-is, with some fine points being ironed out as the spec
> is finalized.

Is there a list of algorithms we support somewhere, particularly the
ones we share with Chromium? IIRC the supported algorithms is where
the real interop problems are expected to be. (I quickly searched MDN,
but that didn't turn up anything useful.)

Cheers,

Dirkjan

[Anne van Kesteren]

On Wed, Sep 3, 2014 at 7:36 PM, Tim Taubert <ttau...@mozilla.com> wrote:
> Chromium has had the WebCrypto API enabled by default since Crome 37,
> which was released in late June 2014. Their implementation supports a
> subset of the algorithms that we do, and has roughly the same level of
> spec compliance. We expect the two implementations to be mostly
> interoperable as-is, with some fine points being ironed out as the spec
> is finalized.

In Chromium the methods only work on authenticated origins. What is
our story? Is the non-overlap of algorithms documented on MDN?


--
http://annevankesteren.nl/

[Ehsan Akhgari]

On 2014-09-04, 4:42 AM, Anne van Kesteren wrote:
> On Wed, Sep 3, 2014 at 7:36 PM, Tim Taubert <ttau...@mozilla.com> wrote:
>> Chromium has had the WebCrypto API enabled by default since Crome 37,
>> which was released in late June 2014. Their implementation supports a
>> subset of the algorithms that we do, and has roughly the same level of
>> spec compliance. We expect the two implementations to be mostly
>> interoperable as-is, with some fine points being ironed out as the spec
>> is finalized.
>
> In Chromium the methods only work on authenticated origins. What is
> our story?

I hope that we are not doing that. I don't think Chromium's reasoning
there makes sense.

[Henri Sivonen]

I agree with Ehsan.

For reference, the Chromium "Intent to Ship" is
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Tn3pfJZDcGg/nUlvUOFKL_QJ
and says "This API will only be exposed to secure origins, as
security-sensitive operations are inherently dangerous when performed
on insecure connections."

It doesn't explain how exposing Web Crypto to http origins makes
things worse compared to http origins not having Web Crypto and
implementing the same algorithms in pure JS. Compared to pure JS, Web
Crypto provides potentially closer to constant-time implementations,
but that's an improvement and doesn't make things worse. Same for
general higher speed. Compared to regular JS storing key material in
IndexedDB, Web Crypto makes it possible to make the key material not
readable by JS (JS can request operations to be performed with the
keys but not read back the keys themselves). That, again, seems like
an improvement compared to not having Web Crypto available.

There's a possible argument that it's dangerous for people to be
confused about what sort of security characteristics Web Crypto can
provide on unauthenticated origin, but I think it is futile to try to
install clue into would-be users by requiring an authenticated origin:
the low-level nature of the API is such a foot gun (the name "subtle"
is an euphemism for that), that if someone is confused about what
security characteristics Web Crypto can provide on unauthenticated
origin, there are plenty of other things about Web Crypto to be
confused about in ways that lead to insecure outcomes. On the other
hand, if the threat model that's being addressed is a passive
eavesdropper (as opposed to an active attacker who changes network
traffic), Web Crypto can provide additional confidentiality compared
to no crypto being in use. Since in this case, the browser does not
make any representations in the UI to the user about the
confidentiality, integrity or authenticity of the communications,
nothing is being misrepresented to the user. However, a site that
considers it worthwhile to hide certain things from passive
eavesdroppers can still benefit.

As for making new features unavailable without TLS in order to promote
the use of TLS, I think the TLS requirement should be motivated by
some real security or deployability concerns to avoid unproductive
resentment by Web developers. (Otherwise, we should be restricting new
CSS to https!) Also, while restricting special-interest features might
feel good (by creating a feeling that we are restricting *something*)
and be more feasible than restricting features that have broad appeal,
restricting special-purpose features is less impactful than
restricting features that have broad appeal.

In this sense, I think restricting HTTP/2 to TLS is the right call.
The restriction to TLS addresses a true deployability concern.
Furthermore, better performance has broad appeal and, on the flip
side, being denied better performance just makes things slow or
instead of preventing stuff altogether. I also think that restricting
Service Workers to authenticated origins is right call, because
failure to do so would mean that an active MITM could continue to have
an effect after the actualy MITMing opportunity has gone (e.g. when
the user has left a café with an open Wi-Fi AP). I also think that
restricting privacy-sensitive APIs that need per-origin permissions to
authenticated origins is the right call, because if the origin isn't
authenticated, the browser can't really limit the scope of the
permission that has been granted, since an active MITM can inject
stuff to any unauthenticated origin that has obtained the permission.
(I'm not sure if getUserMedia is restricted along these line, but I
think it should be if it isn't already.)

Furthermore, APIs whose effects aren't tightly coupled with a
particular page are especially poor candidates for being restricted to
authenticated origins. If the API doesn't have effects that are
visible and coupled to a page (Web Crypto is a data in, data out API),
it's possible to serve an iframe from an https origin and offer a
postMessage interface that proxies the API to an http-origin parent
page. One might argue that this is progress, because then the site has
to take the step to serve *something* from an https origin, but that's
not really much a win considering how common it is for sites to serve
just a login form or a credit card number request form over https and
serve the rest of the site over http. For the sort of security and
privacy we want from https promotion, sites should go all-in with
https and the pattern of using https only for login and credit card
numbers shows that sites that aren't sold on "https all the things"
will make an effort to use as little TLS as they can.

I support the Intent to Ship without a restriction to authenticated origins.

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

[Tim Taubert]

Ehsan Akhgari wrote:
> Can you please clarify what are the areas that we don't fully adhere to
> the spec? Do we expect the fixes to those and potentially new spec
> issues in the future to break backwards compatibility?

KeyAlgorithms were recently changed to dictionaries (from interfaces)
and we did not get around to change that yet. Richard Barnes has a patch
almost ready in bug 1037892 [1] though.

We didn't have to change tests to make them work with KeyAlgorithm
dictionaries so that change would not break existing code. We would
probably aim to land it before enabling WebCrypto by default anyway.

Other parts we're missing is import/export for some formats (e.g. PKCS8
for ECDH/DH) and we're missing a few algorithms completely. We only need
more time to implement those but that wouldn't break any existing code
either.

- Tim

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1037892

> Thanks!
> Ehsan
>
> On 2014-09-03, 1:36 PM, Tim Taubert wrote:
>> As of September we intend to enable the WebCrypto API by default on all
>> platforms. It has been developed behind the dom.webcrypto.enabled
>> preference.
>>
>> Tracking bug:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=865789
>>
>> Spec:
>> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html
>> (A CR is planned soon, only smaller changes to the spec lately.)
>>
>> Reasoning:
>> The implementation of the WebCrypto API has made lots of progress in
>> Firefox 33+34. We added most of the basic functionality and algorithms,
>> and should be mostly spec compliant.
>>

>> Chromium has had the WebCrypto API enabled by default since Crome 37,
>> which was released in late June 2014. Their implementation supports a
>> subset of the algorithms that we do, and has roughly the same level of
>> spec compliance. We expect the two implementations to be mostly
>> interoperable as-is, with some fine points being ironed out as the spec
>> is finalized.
>>

[Tim Taubert]

helpcrypto helpcrypto wrote:
> I'll love to know if Mozilla/Firefox is going to provide something (even
> out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.

The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
API.

> This will fill the gap that currently exist with hardware token support

Not sure what exactly what you are referring to here but I don't know of
any current plans to extend the WebCrypto API beyond what the spec says.

- Tim

[Tim Taubert]

Dirkjan Ochtman wrote:
> Is there a list of algorithms we support somewhere, particularly the
> ones we share with Chromium? IIRC the supported algorithms is where
> the real interop problems are expected to be. (I quickly searched MDN,
> but that didn't turn up anything useful.)

Richard Barnes made a nice list of algorithms [1] we support and the
Firefox version they were introduced. A similar list [2] exists for
Chromium, but I can't tell how up-to-date that is. Judging from their
list of tests [3] this seems to indeed list of all of the available
algorithms.

- Tim

[1]
https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing#gid=1
[2]
https://docs.google.com/document/d/184AgXzLAoUjQjrtNdbimceyXVYzrn3tGpf3xQGCN10g/edit?pli=1
[3]
https://chromium.googlesource.com/chromium/blink/+/master/LayoutTests/crypto/

> Cheers,
>
> Dirkjan

[Tim Taubert]

Anne van Kesteren wrote:
> In Chromium the methods only work on authenticated origins. What is
> our story?

Completely agree with Ehsan and Henri. I don't know of any plans to even
consider doing that and we currently expose the WebCrypto API to
unauthenticated origins as well.

> Is the non-overlap of algorithms documented on MDN?

We currently have no documentation for the WebCrypto API other than for
crypto.getRandomValues(). It should certainly be documented on MDN and
we could provide a list of algorithms we support. Not sure whether we
would want to do that for Chromium's supported algorithms as well?

- Tim

[Anne van Kesteren]

On Tue, Sep 9, 2014 at 12:48 PM, Tim Taubert <ttau...@mozilla.com> wrote:
> Completely agree with Ehsan and Henri. I don't know of any plans to even
> consider doing that and we currently expose the WebCrypto API to
> unauthenticated origins as well.

Note https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 which I
filed. I sort of assumed we wanted to align with Chromium. Either way,
if we think it should be exposed to non-TLS environments, bz could
probably use some help arguing the case.

>> Is the non-overlap of algorithms documented on MDN?
>
> We currently have no documentation for the WebCrypto API other than for
> crypto.getRandomValues(). It should certainly be documented on MDN and
> we could provide a list of algorithms we support. Not sure whether we
> would want to do that for Chromium's supported algorithms as well?

I think we typically have documentation for other browsers as well,
though I don't think it's needed for an initial pass. Hopefully the
community can contribute it.


--
http://annevankesteren.nl/

[helpcrypto helpcrypto]

Thanks for your answers, Tim.

On Tue, Sep 9, 2014 at 12:38 PM, Tim Taubert <ttau...@mozilla.com> wrote:

> helpcrypto helpcrypto wrote:
> > I'll love to know if Mozilla/Firefox is going to provide something (even
> > out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.
>
> The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
> API.
>

I mean to actually use current secmod.db pkcs#11 modules/keys
AFAIK, Webcrypto just talks about "operations with keys" but doesnt say
anything about "where the keys came from" (just on-demand generated). This
is left for KeyDiscovery.
Is there any public place where i can look for such a thing as
"KeyDiscovery implementation status on Firefox"?

> > This will fill the gap that currently exist with hardware token support
>
> Not sure what exactly what you are referring to here but I don't know of
> any current plans to extend the WebCrypto API beyond what the spec says.
>

Will be possible to request an specific PKCS#11 token to generate a keypair?
Will be possible to request a certificate which contains an specific string?

Thats the kind of operations im talking about.

Regards

[Joshua Cranmer 🐧]

On 9/9/2014 5:38 AM, Tim Taubert wrote:
> helpcrypto helpcrypto wrote:
>> I'll love to know if Mozilla/Firefox is going to provide something (even
>> out-of-standard) to make possible using PKCS#11/NSS with Webcrypto.
> The WebCrypto API basically exposes PKCS#11/NSS functionality with a DOM
> API.

The current specification only provides encryption/decryption
primitives, to my knowledge. Support for hardware tokens (getKeysByName,
I think it was?) was pushed into a later draft, and I think it's this
feature that the poster was asking for.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

[Ehsan Akhgari]

On 2014-09-09, 6:35 AM, Tim Taubert wrote:
> Ehsan Akhgari wrote:
>> Can you please clarify what are the areas that we don't fully adhere to
>> the spec? Do we expect the fixes to those and potentially new spec
>> issues in the future to break backwards compatibility?
>
> KeyAlgorithms were recently changed to dictionaries (from interfaces)
> and we did not get around to change that yet. Richard Barnes has a patch
> almost ready in bug 1037892 [1] though.
>
> We didn't have to change tests to make them work with KeyAlgorithm
> dictionaries so that change would not break existing code. We would
> probably aim to land it before enabling WebCrypto by default anyway.

Yeah, I agree that the chances of content code breaking because of this
is minimal.

> Other parts we're missing is import/export for some formats (e.g. PKCS8
> for ECDH/DH) and we're missing a few algorithms completely. We only need
> more time to implement those but that wouldn't break any existing code
> either.

Sounds good!

Cheers,
Ehsan

[Ehsan Akhgari]

On 2014-09-09, 7:25 AM, Anne van Kesteren wrote:
> On Tue, Sep 9, 2014 at 12:48 PM, Tim Taubert <ttau...@mozilla.com> wrote:
>> Completely agree with Ehsan and Henri. I don't know of any plans to even
>> consider doing that and we currently expose the WebCrypto API to
>> unauthenticated origins as well.
>
> Note https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972 which I
> filed. I sort of assumed we wanted to align with Chromium. Either way,
> if we think it should be exposed to non-TLS environments, bz could
> probably use some help arguing the case.

I think Henri's analysis upthread is great.

FWIW going forward, I would expect this desire to expose more APIs only
to documents loaded over TLS to pop up over and over again. While
everyone agrees that a world with more TLS deployments is a better world
to live in, I think this is a line that we should tread carefully, and
we should be able to justify our decision on a case by case basis.

>>> Is the non-overlap of algorithms documented on MDN?
>>
>> We currently have no documentation for the WebCrypto API other than for
>> crypto.getRandomValues(). It should certainly be documented on MDN and
>> we could provide a list of algorithms we support. Not sure whether we
>> would want to do that for Chromium's supported algorithms as well?
>
> I think we typically have documentation for other browsers as well,
> though I don't think it's needed for an initial pass. Hopefully the
> community can contribute it.

We should try to get the chromium folks contribute those docs. :-)

Cheers,
Ehsan

[Jonas Sicking]

Which version are we thinking of enabling this for? For Gecko
34/FirefoxOS 2.1 or a later version?