[cryptography] "There is something Google can do. So they should do it."

Stephen Farrell 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):
>>
>> https://www.reddit.com/r/crypto/comments/3u92aw/dells_tumble_googles_fumble_and_how_government/cxejl5y
> 
> 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 [1] 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
nor accurate.

   [1] https://www.ietf.org/mail-archive/web/websec/current/maillist.html

> 
> 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",
> https://www.ietf.org/mail-archive/web/pkix/current/msg33425.html.
> 
> 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
work.

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
IETF publications.

Cheers,
S.

> 
> The NSA and GCHQ does not need to limit cryptography or algorithms.
> They just need more browser (in)security engineers in more working
> groups.
> 
> Jeff
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
> 


More information about the cryptography mailing list