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

Daniel Kahn Gillmor <> Sun, 22 February 2015 05:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 299E11A1A62 for <>; Sat, 21 Feb 2015 21:47:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6sPeyagv1Lcg for <>; Sat, 21 Feb 2015 21:47:54 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0E6E11A1AAC for <>; Sat, 21 Feb 2015 21:47:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id B4FABF984; Sun, 22 Feb 2015 00:47:51 -0500 (EST)
Received: by (Postfix, from userid 1000) id 3C8921FFDD; Sun, 22 Feb 2015 00:47:59 -0500 (EST)
From: Daniel Kahn Gillmor <>
In-Reply-To: <>
References: <> <> <> <> <> <>
User-Agent: Notmuch/0.18.2 ( Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Sun, 22 Feb 2015 00:47:59 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Cc: IETF WebSec WG <>
Subject: Re: [websec] Comments on draft-ietf-websec-key-pinning
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Feb 2015 05:47:57 -0000

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:

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.