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

[Ryan Sleevi <[e-mail]>]

On Aug 25, 2014 4:39 AM, "Ted Lemon" <[e-mail]> wrote:
>
> 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.

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

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

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