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

On Thu, Jun 5, 2014 at 8:48 PM, Jeffrey Walton <> 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