[cryptography] "There is something Google can do. So they should do it."
stephen.farrell at cs.tcd.ie
Fri Nov 27 19:04:22 EST 2015
On 27/11/15 23:43, Jeffrey Walton wrote:
> On Fri, Nov 27, 2015 at 5:47 PM, Greg <greg at kinostudios.com> wrote:
>> Thought this list would be interested in reading about the roll that Google played in compromising 100k+ users (in addition to Dell):
> They seem to be missing the issue (if I am parsing it correctly):
> REDDIT > So you are saying that Chrome should roll out its own
> REDDIT > cert store because relying on Windows 10's cert store is
> REDDIT > insecure?
> REDDIT >
> REDDIT > Sorry your argument seems very weak and odd to me.
> REDDIT > It also detracts away from the severity of what Dell has done.
> That's not Chrome or Windows per se. Rather, that it is a feature of
> the Web/Browser security model. In the security model, proxying and
> interception is a valid use case. You can thank the browser
> (in)security engineers for that.
> It not just limited to W3C participants. The IETF just jumped on the
> "proxying and interception is a valid use case" bandwagon with RFC
> 7469, "Public Key Pinning with Overrides"
That is not actually the title of that RFC.
> (https://tools.ietf.org/html/rfc7469). Checkout section 4, and then
> try to find what the override is supposed to do, or additional
> information or guidance on using it.
I'm not a fan of that override stuff myself (which is in 2.6 and
not in section 4 btw) but weren't you yourself  a part of that
discussion in the websec wg? While you may have joined in that part
of the discussion too late to affect the outcome, I think
characterising this is "just jumped on ... bandwagon" isn't fair
> Finally, don't look to the IETF to help distinguish the "good" bad
> guys from the "bad" bad guys when a conforming user agent does
> override (or tries to decide if it should override). I've been trying
> to discover that myself. See "How do we differentiate authentic
> servers from proxies performing TLS interception",
> And finally (and either humorously or sadly, depending on your state
> of mind), the PKIX's position is there's no difference between
> authentic server authentication and an imposter pretending to be an
> authentic server. They are happy to allow a CA to issue certificates
> for either usage, even though they appear to be as diametrically
> opposed as you can get.
IMO the above is a mis-characterisation of the situation and of the
recent discussion on the pkix at ietf.org mailing list.
My read of that discussion is that a number of people stated a number
of times that no matter how much one would like some bit in a protocol
to distinguish real authentication vs. a MitM with a locally installed
trust point, there's just no way that can work. I saw that you seemed
to disagree with that, but tbh I've no idea how what you want could
What you're after can't be provided by the IETF. I do agree that
implementations could handle overrides differently in ways that
would make it harder do be a MitM.
I'd also point you at RFC2804 and BCP200 which are other relevant
> The NSA and GCHQ does not need to limit cryptography or algorithms.
> They just need more browser (in)security engineers in more working
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography