[Bug 25972] Please require a secure origin

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

--- Comment #7 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Boris Zbarsky from comment #6)
> > There are zero mandatory algorithms.
> 
> I think that's a problem!

Then file a bug! And we can discuss (again) all of the technical, political,
and legal reasons that makes mandatory algorithms challenging. This is the same
discussion that has been had repeatedly, since the WG started, but if you feel
the answers have not been satisfactory, you should file a bug with your
concerns.

> 
> > There is no way to build a secure system on an insecure transport.
> 
> I've seen you object to people making the same argument about some of the
> algorithms the spec defines.

In the very post being replied to, I attempted to address this before you even
raised it, by showing how the two views - insecure transport vs insecure
primitive - are *not* similar, nor the same objection.

> 
> I don't see why a webpage that's served over http shouldn't be allowed to
> verify signatures or compute hashes, frankly, even if we buy the argument
> that it shouldn't be allowed to do encryption/decryption (which I'm not sure
> I do).

Digest is something whose security is contingent upon use cases, but which
there exists the possibility of low-risk/no-risk uses. Of course, actually
establishing that there is a use case for those (eg: in the non-security space)
has yet to be established.

Verifying signatures, however, is something I do object to. Having signature
verification go over HTTP is no different than file sharing sites listing the
MD5/SHA1 right next to the HTTP download link to a file. You are not protected
from an attacker, at all, who can modify the code and insist that any arbitrary
file has a "valid" signature. Or replacing the signature in transit. Even if
the signature is delivered via secure transport, if the code to verify the
signature is not, then you're still at the same place. And I don't mean
sourcing the script over HTTPS, the entire execution environment has to be
secure in order to securely validate a signature.

So, while in theory it sounds like "this is just a public key operation, no
secrets here", the actual security goals of a "signature verification" system
are immediately defeated by the mutability of the environment when it's an
insecure environment.

> 
> Fundamentally, it seems like you have some set of use cases (Netflix's?) in
> mind but don't care about things that aren't in that set.  Or something.  I
> really can't tell what's behind this drive to disable this API except in
> some Google-specific set of cases.

Within the Chromium security team, we've discussed this API at length, as well
as examined use cases (including those in the document) and their security
expectations. In no case do we believe that real world security expectations
can be met, and we have seen time and time again the misuse of this.

Similar, although for different reasons, to Service Worker, as User Agent
Vendors, Spec Authors and Web Developers, we should stop the proliferation of
insecure-by-default, particularly when the insecurity does nothing to actually
permit building secure applications.

Again, this is *different* than the algorithm argument. Several algorithms
noted as "insecure by themselves" CAN be combined into "secure" primitives, and
are NECESSARY to support use cases - including those that we've documented. The
INRIA security analysis notes this - that while many of the ciphers lack CCA,
it IS possible to build CCA through the use of MACs.

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

Received on Wednesday, 4 June 2014 21:22:21 UTC