- From: Zack Weinberg <zackw@cmu.edu>
- Date: Thu, 5 Jun 2014 21:43:02 -0400
- 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. zw
Received on Friday, 6 June 2014 01:43:26 UTC