W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

From: Zack Weinberg <zackw@cmu.edu>
Date: Thu, 5 Jun 2014 21:43:02 -0400
Message-ID: <CAKCAbMhfUuwiRKA94KfxAgQFzV5qJL57gy4rH9_JdWeO49gUHg@mail.gmail.com>
To: noloader@gmail.com
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Thu, Jun 5, 2014 at 8:48 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>> Only by reading the entire spec carefully, and the
>> definition of "TLS-protected" in WSC-UI, does it become clear that
>> "proven insecure" is a state transition from "assumed *secure*" -- we
>> thought this was going to be secure, but then the cipher is weak or
>> something so it isn't.  I think the problem is with "assumed" and
>> "proven"; maybe "insecure by definition", "assumed to be secure", and
>> "discovered to be insecure" would be clearer.
> It seems like there are two mutually exclusive states: secure and
> insecure. The states are based on security model, threat models and
> cryptographic analysis. There's not much room for debate. You can't
> get half pregnant...

Right, as far as I can tell the distinction in the spec between
"assumed insecure" and "proven insecure" is just about *how the UA
knows* that an origin is insecure.  "Assumed insecure" means the UA
knows /a priori/ it's insecure (http:// scheme); "proven insecure"
means it *could have* been secure, but empirically it isn't (https://,
but the server insists on using RC4 or some other weak cryptosystem).

My concern is just to make sure that this is clear in the terminology;
I think the existing terminology gives the impression that something
could move from "assumed insecure" to "proven *secure*", which isn't
true, and if it were true would be a bug in the spec.

Received on Friday, 6 June 2014 01:43:26 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC