[Bug 25985] WebCrypto should be inter-operable

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25985

--- Comment #40 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Henri Sivonen from comment #39)
> I think it's fine for Node.js to implement browser APIs, but I think it's a
> mistake to let the server side wag the browser-side spec. See: DOM.

I think it's a pretty gross mischaracterization to suggest the server side is
wagging the browser side.

I think it entirely disregards the point that a "web" device ranges from your
smartwatch to your laptop, and that there are a variety of concerns and
requirements in between.

> 
> I also think it's a mistake to make browser API specs vaguer in order to
> make devices with low-quality browsers or browser ports comply. See: Various
> Mobile Profiles from the feature phone era.

Low-quality is an entirely unnecessary pejorative here, unless you believe that
"Web" is meant to encompass "Desktop machines with high-power, general purpose
CPUs". Which the W3C, nor do many of the UAs, consider to be the end-all,
be-all.

> > Let me emphatically state that "conformance" lacks a strong definition in
> > the context of cryptographic operations. It is essential to treat them "as
> > if" they were hardware capabilities.
> 
> Do you say this in order to make sure that stuff *can* map to hardware
> capabilities like AES-NI or do you say this in order to be able to treat
> crypto differently policy-wise compared to features that browsers are
> expected to have regardless of the underlying hardware?

The answer is both. On a lower-end device constrained by die size, it's
absolutely a matter of hardware. On the higher-end devices, there's still a
matter of policy.

In both cases, there are a set of factors and considerations that exist outside
the purely abstract notion of "implement the following steps" - concerns such
as export controls, concerns such as hardware capabilities, etc.

> Isn't this what Chromium is on track to doing once it switches to BoringSSL?

Both of your responses are entirely irrelevant to the question I was asking,
and show a failure to appreciate the concerns. You still have not answered the
questions I asked, which applies not just for Chromium, but for all user
agents.

Your proposed path is one that makes it impossible for a UA to reasonably be
agnostic about crypto - which only serves to solidify the notion of a "few
UAs", and that the web technologies are impossible to implement unless you're
an entrenched incumbent.

Chromium's ability to launch was predicated on it's ability to use the existing
platform crypto libraries - including on Windows. Only as it grew, and the
"experiment" was worthwhile, was it even possible to switch to NSS, and only
recently has it become "possible" to switch to BoringSSL - and not without
significant costs and engineering investment over *years*. That's not something
to so glibly dismiss with a one-off, nor does it do anyone in the WG any
favours, when the heart of the question remains - which is, "what is
conformant"

> >   - Is a distinction made between the library being an older version, which
> > may not support RSA-OAEP, and the library being newer, but having RSA-OAEP
> > explicitly disabled by the user (through means outside of Chromium's
> > control?)
> 
> I'd say the question of whether Chromium is conforming in that case wouldn't
> be of practical importance. From the practical perspective, it matter if
> stuff works. If stuff doesn't work, the system+configuration as a whole
> would be non-conforming if RSA-OAEP was in the set of algorithms that the WG
> has deemed to be part of the Web Platform.

This is of the utmost practical importance, because one defines the other. You
can't just wave this away, as you did earlier. What does conformance mean on
such a system. Does the lack of RSA-OAEP mean you lack WebCrypto entirely? Does
the fact that such a profile exists - on a vast number of machines, and in ways
that non-skilled users (e.g. those who aren't going to recompile a bleeding
edge, ToT version of NSS) can't just solve? And what about for other platforms
- like Windows or OS X - where users can't even just arbitrarily extend?

> 
> > - What about for algorithms for which there are no PKCS#11 mechanism points
> > assigned yet, like Curve25519 or the NUMS curves?
> 
> Seems reasonable to implement Curve25519 without any PKCS#11 layer in
> between in that case.

It may seem reasonable to you, but only because you seem to be choosing to
ignore the very concerns being presented to you. The use of the PKCS#11 layer
is what allows a UA to avoid, entirely, any of the legal or regulatory
frameworks surrounding it. Implementing Curve25519, without any PKCS#11 layer,
requires significant investment in legal efforts (at a MINIMUM). And if
Curve25519 was MTI, what then?

> If the Web developer is implementing something that has NaCl at the other
> end of the pipe, then if Curve25519 isn't available, AFAICT, the options are
> polyfilling with JS (including asm.js) with the risk to timing side channel
> attacks, telling the user to get another browser or changing what's at the
> other end of the pipe (if possible).

Exactly what the spec says today.

> I don't expect a world where every browser implements every algorithm ever
> thought up. I expect the WG to maintain documentation of which set of
> algorithms browsers are expected to implement either because the algorithms
> provide good crypto and should *become* more common or because they are
> needed for compatibility with very common legacy at the other end of the
> pipe. That target set might expand over time and expansions of the set might
> not be implemented immediately, but it's still better than not trying to aim
> for convergence of the available features across implementations.

This is what the WG has always said, from the beginning, when it decided not to
do MTI. Nothing has changed here.


> In particular, I'd expect the WG to reject from that set algorithms that are
> neither necessary for compatibility nor provide better (yeah, what's
> "better" is probably hard to articulate fully) crypto than what's already in
> the set. ("Our research department came up with these" shouldn't be good
> enough, in itself, for inclusion.) As a obvious example, just because there
> exists a definition for a BADA55 curve somewhere doesn't mean that such a
> curve should be put in the set of algorithms that browsers are supposed to
> implement. 

This is a decision that will (and has already, several times), completely
prevent the WG from progressing. Are you an American imperialist who refuses to
accept things such as SEED or GOST? Are you a European loyalist who loves the
Brainpool curves, even though one can argue they too have issues? Even the
cryptographic community is divided upon what an appropriate set of criteria for
curves are. This WG is the LEAST CAPABLE of making such a decision.

So by introducing such arbitrary value judgements, and even if they're based on
an objective set of criteria (the absolute MINIMUM requirement for MTI), the
criteria themselves will be somewhat arbitrary (or "consensus driven", which is
indistiguishable from arbitrariness), it just serves to drive endless debate in
a WG not well-suited for that.

> (More controversially: The most common NIST curves probably need
> to be in the set due to compatibility considerations despite the open
> questions about their constants, but it doesn't follow that a bunch of other
> curves whose constants have similar provenance should be added, too.
> Instead, other curves added to the set should probably have better
> justifiable design choices.)

And "better justifiable design choices" is a judgement call that, as the CFRG
shows, is one that reasonable, seasoned members of the cryptographic community,
well versed in the nuance, STILL disagree on.

> 
> In practice, though, I'd expect the set of algorithms to be pretty heavily
> influenced by what the browsers with the most market share are willing to
> implement (in the fashion of comment 37) and not just by abstract
> discussions in the WG.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 30 July 2014 18:33:36 UTC