Re: [websec] Ted Lemon's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS)

Yoav Nir <> Mon, 25 August 2014 08:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 911641A86F0; Mon, 25 Aug 2014 01:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qm2ryj7WwuZe; Mon, 25 Aug 2014 01:44:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 17B491A702D; Mon, 25 Aug 2014 01:44:14 -0700 (PDT)
Received: by with SMTP id hi2so2169639wib.5 for <multiple recipients>; Mon, 25 Aug 2014 01:44:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IgBEI6JXMMQJ9ap41ilJRIoCtQPRlpPq1rP2HLIQpLg=; b=mwU0msVattpnBdLxqYo8w5d/hh6fmLJjftTKzUOlbPY5+xRwXLAasShLokpx6rT1ui bTUcpA8A28Hu4GSIVvV2uUSgp0aa/TJVPU0KR9Lz2t2N45rcy3K0PgdSVxflj7UFYSMn X9Sj4GMMbLV5CjO2vB4sNpdyJ7tlRGPBBKTcbEwlZs5O0Yj2G0iNFXkorINzhyKhE0pq 44ZRWzxljHBKIkIvmQzyNN+ZroZCpgk/3JACl/A0hWRbMwNu5CJhafF8HKvp5/O8UXYa Mi0c+syFAnRPQr4b6anuLqC+e30MZNALfKyf4m5gA/yxZVTBSfaX4gDUA7wFEXgRqRAL sNVA==
X-Received: by with SMTP id fl18mr21358390wjc.8.1408956253754; Mon, 25 Aug 2014 01:44:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id dc9sm29492794wib.5.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Aug 2014 01:44:13 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6065A492-04F5-4AD2-BDD4-55C454C9FBFF"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 25 Aug 2014 11:44:09 +0300
Message-Id: <>
References: <> <>
To: Ryan Sleevi <>
X-Mailer: Apple Mail (2.1878.6)
Cc:, "<>" <>, Ted Lemon <>,, The IESG <>
Subject: Re: [websec] Ted Lemon's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS)
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: Mon, 25 Aug 2014 08:44:17 -0000

On Aug 25, 2014, at 8:52 AM, Ryan Sleevi <> wrote:

> On Thu, Aug 7, 2014 at 6:57 AM, Ted Lemon <> wrote:
> Ted Lemon has entered the following ballot position for
> draft-ietf-websec-key-pinning-19: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This mechanism relies on there being no MiTM attack from a compromised
> signing key either prior to a legitimate pinning, or in a situation where
> the host being "protected" doesn't actually do pinning.   I think this
> should be mentioned in the security considerations section.   I raise
> this to the level of DISCUSS because I think this actually creates a new
> attack surface for government censorship: you MiTM the host you're
> attacking, pin it to a cert signed using a compromised CA, and then that
> UA can't communicate with the host again for the duration of the pin.
> The scenario would be that the government has a transparent web cache in
> the path between the host and the UA, and the web cache pins false cert
> for hosts that are being censored.   Now even if the user sets up a
> tunnel to bypass the transparent cache, they can't access the censored
> site, so they conclude that the site is down and abandon the tunnel.   I
> could easily see this being used in a scenario like the recent DNS
> censorship in Turkey.
> Setting a lower maximum pin age mitigates the damage of such attacks if
> the user keeps the tunnel up for the duration of the pin, but I don't
> think it's realistic to assume that they will.   I think that the only
> way to mitigate this attack is to have a mechanism whereby conflicting
> DANE TLSA information overrides the pin.   This would allow a site being
> attacked in this way to securely inform the UA that the pin was invalid.
>  The government could of course prevent DNSSEC validation, but the UA
> could take this as another signal to drop the pin: if the zone where the
> TLSA record should be fails to validate (as opposed to isn't signed,
> which wouldn't signify anything), the pin is likely a censorship attempt.
> Happy to note "Hostile Pins" as an attack scenario, as it's one we've discussed at length, however, I find the scenario a bit convoluted, and worse, the proposed solution (DNSSEC) being worse than the problem that it's solving.

+1 but for a slightly different reason.

If you have a functioning DNSSEC, you don’t need HPKP. Just use DANE. 

HPKP is the TOFU stop-gap measure for an Internet that does not have DNSSEC everywhere.