[Bug 25985] WebCrypto should be inter-operable

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

--- Comment #26 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Henri Sivonen from comment #25)
> 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.

Major browsers do, but in a way that are transparent to major browsers. This is
because major browsers are not in the business, generally speaking, of shipping
cryptography. They defer that to existing libraries.

There's also exemptions that are applicable to browsers' use of cryptography
(that is, as it relates to SSL/TLS) that do not apply to other uses. This
includes both patents and legal restrictions (encryption vs
authentication/signatures).

This is not the best forum to speculate or offer legal advice. I am merely
presenting the facts, as they stand, because that HAS required the
implementation efforts work together with counsel. And I doubt we're alone in
this.

> 
> (In reply to Ryan Sleevi from comment #1)
> 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.

But it doesn't change what I said - administrators can and do regularly disable
cipher suites and algorithms. The choice to disable algorithms is transparent
to the web author, but not to the server administrator - it directly affects
the security profile of servers (eg: crappy suites vulnerable to BEAST or
issues like RC4), and failure causes interop.

However, if your use case is "implementing a particular application protocol",
then either you have negotiation capabilities - in which case, your application
can work, sans polyfills - or you don't, in which case, you, the application
author, can make a choice about whether polyfills are appropriate. In some
cases, they are. In some cases, they are not. A protocol without negotiation is
something that is rare in practice for standards bodies to produce, although I
certainly admit the possibility of an application-specific protocol.

More importantly, and at the risk of diverging this bug - WebCrypto does not
protect you in the face of XSS attack. I cannot stress that enough. If you feel
it does, it's best to start a thread on public-webcrypto-comments@ so we can
explain how, even with 'extractable', you are not protected from common
attacks, both cryptographic and on privacy.



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

But the reality is that this happens, which you seem to believe doesn't.

They are required by local jurisdiction, enterprise policies, industry
regulation, export policies, or mere taste.

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

In every UA implementing, the ability to make these kind of configuration
changes is not part of the UA. It is entirely transparent to the UA, but
happens, which is the point.

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

This is irrelevant and not the point I was making. It was about algorithms that
show future weaknesses.

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

I'm sorry, but you've missed the point here as well. This has nothing to do
with FIPS compliance. Your point about "ignoring the US government" is the
exact opposite of the point.

The NIST curves are standard and, without exception, the most widely adopted
curves - in implementations and in deployment. However, people, which would
seem to include yourself, may have a distrust of the U.S. Government, and thus
wish to disable these curves, using alternate curves. These curves may be
non-standard (but performant) curves like Curve25519, they may be "standard by
a different agency" curves, such as Brainpool. Or they may be experimental
curves (like the MSR curves). But the NIST curves still exist, and substantial
use cases depend on supporting them.

Again, this has NOTHING to do with FIPS. This is simply that if WebCrypto
requires support for the NIST curves (which nearly everyone *presently* use),
then any disabling of the NIST curves would require disabling the entire API.
That is not acceptable. If the NIST curves are NOT required, then we're either
recommending people use non-standard curves, or standard curves that have
poorer security/performance characteristics. This is also craziness.

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

Received on Tuesday, 10 June 2014 17:49:33 UTC