Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Ted Lemon <Ted.Lemon@nominum.com>
In-Reply-To: <CACvaWvYTuutQGgkcZN3RraY9+UuRJ5WzBveci5oxrg=q96CdCw@mail.gmail.com>
Date: Mon, 25 Aug 2014 07:39:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <3B6D8F39-468E-45ED-B9AD-9FCE8F2FC55A@nominum.com>
References: <20140807135751.6422.30957.idtracker@ietfa.amsl.com>
 <CACvaWvYTuutQGgkcZN3RraY9+UuRJ5WzBveci5oxrg=q96CdCw@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/s5T66LldjBQYbjF0f-s7X96uc4A
Cc: draft-ietf-websec-key-pinning@tools.ietf.org,
 "<websec@ietf.org>" <websec@ietf.org>, The IESG <iesg@ietf.org>,
 websec-chairs@tools.ietf.org
Subject: Re: [websec] Ted Lemon's Discuss on
 draft-ietf-websec-key-pinning-19: (with DISCUSS)
Precedence: list

On Aug 25, 2014, at 1:52 AM, Ryan Sleevi <sleevi@google.com> 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.

> 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 transparency.

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.

> 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.=20

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.

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.   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.