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

Ryan Sleevi <> Mon, 25 August 2014 12:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B1F71A9062 for <>; Mon, 25 Aug 2014 05:26:47 -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=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WdoqiNhCjAmr for <>; Mon, 25 Aug 2014 05:26:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B00E1A9061 for <>; Mon, 25 Aug 2014 05:26:45 -0700 (PDT)
Received: by with SMTP id id10so14748424vcb.7 for <>; Mon, 25 Aug 2014 05:26:44 -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=W1TJ62PuFqR4CaCGsVtxOsEHVc+pYt+Kd1+sLACWbtE=; b=JXkhfFyyU4vqayBoQ8xHEOpJJIJ5i7AQGOt42DFskj+zbITnM4qkbNdZ8u1Nb1JAAl 9hmmPcZOCrbyoTRsazqtAVJ71Mf87VH3VYlFZDjpq31C+jTmejKte3jFnW+LcppEvAtW ciyfvOt9i+PjIZdTZQfsbB0JlOr4A0tp9CASoNQhIQA9xfPqxQAKpeX2XHS4XBfjerBp j2DQRcoZ1MmVvZRDFchvEikXpX+6DN0m8GbmW5eflBrv7KjEkR9ABZgCUkpZJw3JwMol r5wIxgW7DY6QpzAS17Bbi0VA3+4WS7e4hzmGn/LmoctMJTfGExD+EQuMlvTpuoretMW8 M6Yg==
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=W1TJ62PuFqR4CaCGsVtxOsEHVc+pYt+Kd1+sLACWbtE=; b=NshbfiXBT8tkHWQeBSq0cxeXc1kBaX8+5WwzzxV4Ypj6sbehds9wXbvTlp/nM0ChCb SsixjrI57QmxxxPmoHrVQHegZ4XAukXF1HVSPc3J9Zj43d1awQCPX6oHByyBYfzmdKxs lE8/hz4WP/VPr+YCPL63r6nju1f2CVF444JJsPP3774UDbrbc55klQ4tNF4BqgDJodjv b6w3AJel3gI5InXiBezV2ATnthWF+SC9UHwZKcxHLS1BPPWt39F2PhAxfDNtcmcbVoE6 nbOLnhcmDhscGk4WF6WZQWpvtHlx/8bBRqXM24l55P/K0Gbh3br6RS3j/uo/G3uMRE+A PueQ==
X-Gm-Message-State: ALoCoQnCL+5D7OjoZEtka0tttr/t7Ix4i6zuL2Y04ULZW/Cy/V2y2vsVShmWGlQe0cbA4uDs6H3b
MIME-Version: 1.0
X-Received: by with SMTP id dh1mr1003061vdc.78.1408969604392; Mon, 25 Aug 2014 05:26:44 -0700 (PDT)
Received: by with HTTP; Mon, 25 Aug 2014 05:26:44 -0700 (PDT)
Received: by with HTTP; Mon, 25 Aug 2014 05:26:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 25 Aug 2014 05:26:44 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Ted Lemon <>
Content-Type: multipart/alternative; boundary="bcaec51a8e56c50aa40501734c52"
X-Mailman-Approved-At: Mon, 25 Aug 2014 06:59:36 -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 12:26:47 -0000

On Aug 25, 2014 4:39 AM, "Ted Lemon" <> wrote:
> On Aug 25, 2014, at 1:52 AM, Ryan Sleevi <> wrote:
> > 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.
> If I'd suggested that this be how DNSSEC is used, that would definitely
be a problem.   What I actually suggested though was that DNSSEC be checked
to see if a conflicting key can be securely shown to exist.

You had originally stated:

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.

In either case - blocking DNSSEC or mangling - if there is a way for the
attacker to EVER drop a pin, we can presume they will take it and exploit

That's why I think the mitigations here are flawed, especially when they
rest on another network level signal. Dropping a pin - except for max-age -
is tantamount to a downgrade attack. We have seen enough of these in
elements like TLS version negotiation or in revocation checking, and
certainly with DNSSEC deployment, to know that downgrades are bad and
network signals are, at best, unreliable.

> > 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
> Which we already have, in the form of trust anchors and validation
chains.   Your court order attack works just as well for pinning as it does
for DNSSEC, so I don't see how this is relevant.

My point was that we have significant mitigations - in operational
requirements (quarterly audits), in business requirements (CA/Browser
Forum), and in technical mitigations (CT) - in place to deal with the court
order, such that there has never been any documentary evidence of one,
whereas such orders are weekly for DNS.

In this model, where again, a downgrade is a full compromise of the system,
I would rather prefer the devil I know with the mitigations I control than
that which I do not.

> > 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.
> That may be true.   The point of suggesting DNSSEC as a mitigation
strategy is that if we start to see hostile key pinning (nice term, BTW),
is not that it would necessarily get implemented today, but that once
hostile key pinning becomes a common attack, which I expect will happen
shortly after key pinning becomes widely deployed in its vulnerable state,
there will be a stronger motivation to implement some kind of strategy for
detecting it.

Can you describe why you believe it likely? Key pinning has been
implemented for some time in UAs, and we have yet to see any evidence of

Its important to remember that hostile key pinning is solely a DOS vector,
AND it requires the attacker hold a valid cert that meets the UAs policy
requirements. Pinning exists as a means to reduce that risk further, and
works because the assumption is that the likelihood of such an event is
small that a TOFU solution can mitigate it to begin with.

> It may be that DNSSEC isn't the right strategy, but not having any
strategy at all seems like a bad idea.   Richard suggested offline that
certificate transparency might work; my concern with that is that there's
no way that I know of (not an expert, so maybe I just don't know) to detect
that you are being prevented from doing certificate transparency, and not
just unable to reach a server that does transparency.

I suspect you may misunderstand how CT works, but there is no extra "reach
a server doing CT" phase. To talk to the target is to talk to the server
doing CT.

> If in fact hostile key pinning can be mitigated using certificate
transparency, that would also address my discuss.
> Richard also suggested tunneling DANE validation chains over HTTP to
address the problem, which sounded to me like another good strategy that
gets around the DNSSEC functionality problem, although it does not get
around the DNSSEC deployment problem: sites that care to prevent hostile
pinning would still have to deploy DNSSEC to prevent it.
> It may also be that the right thing to do is just discuss the problem in
the security considerations section and punt on solving it until later.   I
can't really force you to address the problem now with a DISCUSS, nor would
I want to.  The point of the DISCUSS is to talk about it and figure out
what, if anything can be done.  It may be that there is nothing practical
that can be done.   It may also be that there is something practical that
can be done, but it should be done in a follow-on document.   Either answer
is fine with me if it's true, but the case needs to be made.

Sure, so it sounds like merely a description of hostile key pinning is