[MIX]: "Assumed"/"Proven" Terminology. (Re: [MIX]: Expand scope beyond TLS/non-TLS)

Thanks Jeffrey and Zack (and sorry about the misspelling; I'll pay more
attention from now on). Forking this piece off to keep the other thread
focused on the private/public distinction.

On Fri, Jun 6, 2014 at 3:43 AM, Zack Weinberg <zackw@cmu.edu> wrote:

> > 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).

Your interpretation is exactly what I was trying to express. We need one
check that we can do before making a network connection ("Is it HTTP? Skip
it."), and one check we can do after the TLS-handshake ("You want to use
DH_anon? Really?").

The terminology I started with was "a priori insecure" and "a posteriori
insecure"[1]. I assumed that was too Kantian for a spec, but since you also
landed on that distinction, I'm going to run with something like it. :)

origins are either "a priori insecure
"potentially secure
or "insecure
(where "a priori insecure" is a subset of "insecure"). WDYT?



Received on Friday, 6 June 2014 07:43:10 UTC