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

[Ryan Sleevi <[e-mail]>]

On Thu, Aug 7, 2014 at 6:57 AM, Ted Lemon <[e-mail]> wrote:

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

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.