Re: [websec] Comments on draft-ietf-websec-key-pinning

[Daniel Kahn Gillmor <[e-mail]>]

Hi Jeffrey--

I share your concerns about MitM attacks on the web, and I'm also not
happy about the compromises made in HPKP about "locally-installed" trust
roots, fwiw.

But i don't think your arguments are helping.

On Sat 2015-02-21 21:38:20 -0500, Jeffrey Walton wrote:
> You'll have to forgive my ignorance because the document states its
> use to defend against some MitM attacks. The two canonical cases are
> (1) Diginotar and (2) Superfish. We can defend against them with
> pinning, so its not clear to me why browsers are having such trouble
> with it.

I believe pinning *would* prevent Diginotar misissuance, unless the
origin server had pinned to the diginotar CA itself.

All origin servers that had pinned to something other than the Diginotar
CA would have their users reject any cert issued by Diginotar.

Pinning doesn't defend against Superfish because Superfish is malware
installed at system initialization time.  It could have been a lookalike
version of a popular browser, or just a replacement of a system library
involved in certificate validation.  The only technical defense against
this kind of thing is to wipe your brand new system down as close to the
bare metal as you can go and install it properly from known-good
sources.  Most people are not capable of doing this on most computers,
though, so as a society our recourse against future Superfishes may need
to be something beyond just the technical.

> I think browser architects and the security community need a Key Usage
> of INTERCEPT to help differentiate the cases. It will help browsers
> and other user agents differentiate the "good" bad guys from "bad" bad
> guys. It will also help them determine when its OK to break a known
> good pinset.
>
> CAs surely won't issue INTERCEPT certificates and (I believe) most
> folks won't declare INTERCEPT, so you've avoided the problem for a
> majority of the use cases (over 90%?). That's a huge step forward in
> helping browsers and other UAs differentiate the "good" bad guys from
> "bad" bad guys.
>
> The "good" bad guys will honor it and you'll know you're dealing with
> a "good" bad guy. The "bad" bad guys will not honor it and you'll know
> you're dealing with a "bad" bad guy. In this case of a "bad" bad guy,
> UAs should refuse to break the pinset.

I can't tell if you're being serious here or not.  It sounds like you're
endorsing something very similar to:

  https://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01

Which i think is a terrible idea.

>  And UAs won't fall victim to the Diginotar and Superfish cases.

I'm quite certain that in your scenario, Superfish would have set
themselves up as a "good" bad guy and the overwhelming majority of users
would be none the wiser.

      --dkg