On Aug 25, 2014, at 8:52 AM, Ryan Sleevi <[email protected]> wrote: > > > > On Thu, Aug 7, 2014 at 6:57 AM, Ted Lemon <[email protected]> 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
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
