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

[Ted Lemon <[e-mail]>]

On Aug 25, 2014, at 1:52 AM, Ryan Sleevi <[e-mail]> 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. 

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.