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

[Yoav Nir <[e-mail]>]

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

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

+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