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

Ryan Sleevi <> Mon, 25 August 2014 05:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 26C081A8A68 for <>; Sun, 24 Aug 2014 22:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ys8gJxKfM3-c for <>; Sun, 24 Aug 2014 22:52:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB7C41A8A60 for <>; Sun, 24 Aug 2014 22:52:22 -0700 (PDT)
Received: by with SMTP id la4so14408820vcb.5 for <>; Sun, 24 Aug 2014 22:52:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zGPj2SBFb0eIxt0deqHPdw9fn5rgEN3OHmbFLGY7gE8=; b=aSemCIpRMDMjv3Ef1o0WgXKQkxCyGAT3L3SzK10vrTyN3oqQig8BCRny6HyJrO1vAR bm0pt2MZDmTTph0iJC1crHrdnBni/DgUZO1hEj/ctxxGrY0WFccwRy6tn+NRAYabcqmT C3Hwib7FC0VKPAOxlyW96BVtCkMAH9KAZuGBcfCS/SGpJdm/pMXEZ7uXWKBn36A/Clua EVGARvXE5jP/9V84iJOwYZ42SOVlgbjuwK7qWqJSiqZS2t3qP3caTbUAJurXh7lP+PQ1 T2tyZ5PetshaDIRtnExGV7QIgkaT81B4D5kC+s9UHOFZJPx5k0Vg3dSZF43yC31K8sk1 Ie0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zGPj2SBFb0eIxt0deqHPdw9fn5rgEN3OHmbFLGY7gE8=; b=WS4Kx+OR6FVkppLcSfELtD2QUS/ex1+ZQvr4n8SY9Skikgl6lq1pLSMIHsfUAhv/TL S51U6tNeRsUQCcd5IsIhI9UWpGUen5TONI73y772/pkPVmTpN8iMq9JOpXGEk6sed0R1 RcnisBdqxGRwNBM7O04DDRzXTa5BZRMKiyN2aUBK8vp4LWczFoPfX8Kk4oT9fkkBnwWa 83YCYApdqzzMjdQcmwSbmfWDm7Z8/9XwpUcpYBGqV/GE3n3p7z7eZDPgu2Bos9Es+qzN ix4lRFBJd7N0PcXCs7u5Frik5PtuqaigSxUnm025Ozh3tb7v8ILqPPrYVnjoEUT+p0Gt m/3g==
X-Gm-Message-State: ALoCoQnEzL17+iQv6Fn6OiQMzV68eShGwJDCae/i+MLJP3PSnqFHZVFV8zO6nnvRy45VJnxCqLNF
MIME-Version: 1.0
X-Received: by with SMTP id xy10mr3313989vdb.51.1408945942127; Sun, 24 Aug 2014 22:52:22 -0700 (PDT)
Received: by with HTTP; Sun, 24 Aug 2014 22:52:22 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sun, 24 Aug 2014 22:52:22 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Ted Lemon <>
Content-Type: multipart/alternative; boundary="089e015386486390a605016dcaf9"
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Cc:, "<>" <>, 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 05:52:25 -0000

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.

That is, consider the inverse ordering. A user visits a good site, with the
TRUE certificate chain being sent, and notes the GOOD pins. At some point
later on, a hostile intermediate attempts to MITM the connection. The UA
correctly refuses to connect to the host, because the pins do not match.

The hostile attacker (the government) blocks DNSSEC, which now the UA takes
as a signal to drop the pin. In doing so, they now connect to the BAD site
with the BAD certificates, and note HOSTILE pins.

Or consider the operational risks of DNSSEC, which lacks formalized key
strengths or management lifecycles, and which, as evidence repeatedly shows
for DNS, can be transferred through court order. In this case, if a DNSSEC
TLSA record overrides the pinning, the site is again at the mercy of a
single point of failure. Thus we'd need DNSSEC pinning and DNSSEC

I don't mean for this to get into a larger debate about DNSSEC, merely
provide context for why it's not discussed as a mitigation in considering
hostile pins. I think I can fairly certainly say such a mitigation wouldn't
get implemented.