> Ryan's previous post already covered the reasons for disabling pin > validation for user-defined trust anchors, which still hold even though > Superfish did their superfish thing.
That's not acceptable for two reasons. First, the user did not take an administrative action. Second, pinning is a control we use to stop that sort of thing. We also don't have an audit trail because the IETF thought it was wise for the user agents to be complicit in the cover up. I don't believe this proposal - in its current form - will prove effective in the canonical cases: (1) CA failure like Diginotar; and (2) MitM attacks like Superfish. Are there other obvious cases I missed that this control will be effective? Jeff On Thu, Feb 19, 2015 at 1:00 PM, Joseph Bonneau <[email protected]> wrote: > > On Thu, Feb 19, 2015 at 9:43 AM, Jeffrey Walton <[email protected]> wrote: >> >> Quod erat demonstratum: >> >> http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/ >> >> This proposal needs to be revisited. It has serious defects. > > > Ryan's previous post already covered the reasons for disabling pin > validation for user-defined trust anchors, which still hold even though > Superfish did their superfish thing. > > If the spec did not allow this behavior, the next Superfish would probably > just configure local UAs to launch with pinning disabled completely. I don't > think their recklessness would somehow stop short of overriding the > browser's pinning policy. _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
