[Bug 25985] WebCrypto should be inter-operable

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

Henri Sivonen <hsivonen@hsivonen.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsivonen@hsivonen.fi

--- Comment #25 from Henri Sivonen <hsivonen@hsivonen.fi> ---
(In reply to Ryan Sleevi from comment #1)
> However, there are types of interoperability that are more problematic.
> Cryptography is an extremely special case, for a variety of reasons. Some of
> them include:
...
(In reply to Ryan Sleevi from comment #7)
> And that's not even beginning to touch on the (many) issues from
> http://www.cryptolaw.org/

Frankly, these look like vague "There are concerns." kind of concerns that
aren't usefully actionable.

Does any major browser these days ship different versions with different sets
of algorithms to different countries? If not, then it seems beside the point to
bring these points up. If they do, then it would be useful to be specific about
which algorithms get disabled in which cases by which browsers.

(In reply to Ryan Sleevi from comment #1)
> This is also similar to browsers' existing TLS stacks - administrators can
> (and do) change or disable the ciphersuites used to negotiate with a server.
> Even the SSL "mandatory to implement" cipher may be disabled.

I think drawing an analogy between TLS and the Web Crypto API is incorrect,
because they provide different interfaces to the application developer.

In the case of TLS, the application developer gets an authenticated encrypted
duplex channel. In the Web case, the situation is even more specific and the
Web application developer gets authenticated and encrypted HTTP requests and
responses. The cipher suite details have no bearing on the interface presented
to the Web application developer, so it's OK for the server to negotiate a
different cipher suite with different browsers.

With the Web Crypto API, the level of abstraction is different. Chances are
that you are implementing a particular application protocol that uses
particular ciphers and if those ciphers are not available, your code breaks or
you have to provide the crypto in JS. If you have to provide the crypto in JS,
the point of having the browser provide the crypto primitives is completely
defeated as far as implementation convenience goes or as far as asking the
browser to hold the keys even in the face of XSS attacks goes. Then the Web
Crypto APIs just for acceleration and constant timeness treated as an optional
characteristic.

> As more and more users
> disable weak algorithms, user agents would be forced to remove *all*
> cryptographic capabilities 

This assumes that it's reasonable for users to be able to disable weak
algorithms in a low-level API. As noted above, the alternatives are that the
application breaks or that the application falls back on JS-implemented crypto.

If the application just breaks, it's very unlikely that users properly connect
the breakage to the configuration changes they have themselves made. Instead,
the user will just perceive the mystery breakage and probably blame it on the
browser. Therefore, it's probably not a good idea for a browser to make it easy
for users to make this kind of configuration changes that are most likely to
reflect badly on the user's perception of the browser.

If the application falls back on JS-implemented crypto (i.e. the Web Crypto API
was just used for acceleration and optional constant timeness in the first
place. The user doesn't get any security benefit from the application falling
back on JS-implemented crypto, so it doesn't make sense for the user to disable
weak algorithms in that sense, either.

For practical purposes, Web applications will use the Web Crypto API behind the
scenes and users won't have any meaningful browser configuration recourse to
fight against the application developers making bad algorithm choices. The best
bet is not to include weak algorithms in the first place, but the nature of Web
compatibility will make it hard to get rid of any algorithm deemed weak
subsequently.

(In reply to Ryan Sleevi from comment #3)
> If that sounds hypothetical, it's not. Z, in this case, is ECC with the NIST
> curves. So let's say we spec'd "NIST curves and Curve25519 and Brainpool"
> (Bug 25839). Now users within the US government are prohibited from using
> Curve25519/Brainpool, so they wish to disable those curves. Are they too now
> prevented from using WebCrypto?

If complying with FIPS means that random parts of the Web break for users whose
browsers have been configured to be FIPS-compliant rather than Web-compatible,
in the big picture it doesn't matter that much if the breakage arises from
individual algorithms disappearing from the API or the whole API disappearing.
Either way, it's going to be inconvenient for users who live under the FIPS
bureaucracy, since some sites will just break in unobvious ways. The only way
to make this not be the case would be not having non-FIPS crypto available via
the API at all, but that would clearly be wrong, since it would be wrong for
the whole rest of the world, including non-governmental users in the United
States, to be limited in crypto in order to help U.S. government users not be
inconvenienced by U.S. government bureaucracy.

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

Received on Tuesday, 10 June 2014 11:36:01 UTC