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

On Thu, Jun 5, 2014 at 8:29 PM, Zack Weinberg <> wrote:
> On Thu, Jun 5, 2014 at 8:48 AM, Mike West <> wrote:
>> is a first pass at making this change. The draft at
>> has been updated
>> accordingly; it's probably easier to read there. :)
> This addresses my initial concerns, but on reread, I have a couple more.
> This is largely editorial, but the wording regarding "assumed
> insecure", "assumed secure", and "proven insecure" could be better:
> right now it makes it sound like the UA has to make a network request
> before it can move something from "assumed insecure" to "proven
> insecure".  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...

I'm not sure what to do with the gaps in the security model. For
example, selecting RC4 is a bad idea because we know its "insecure"
for use in SSL/TLS. As another example, connecting to the wrong server
because of Diginotar like-funny business still falls under "secure"
though intuitively, we know its not.

The security model could be fixed, but it would require
acknowledgement of the gap. That's probably not going to happen.


Received on Friday, 6 June 2014 00:48:36 UTC