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

From: "Ted Lemon" <[email-masked]>
Date: Thu, 07 Aug 2014 06:57:51 -0700

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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 24 Aug 2014 22:52:22 -0700

> http://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

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
transparency.

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.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 25 Aug 2014 11:44:09 +0300

On Aug 25, 2014, at 8:52 AM, Ryan Sleevi <[email-masked]> wrote:

> 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.

Yoav

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Aug 2014 07:39:18 -0400

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

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 25 Aug 2014 05:26:44 -0700

On Aug 25, 2014 4:39 AM, "Ted Lemon" <[email-masked]> 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:

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
it.

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.

>
> 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.

>
> 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
this.

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
sufficient.