Hi Chris, <hat="individual">
It seems like the majority of the WG would not share my concerns. So I will shut up soon. ;-) Maybe two remarks: 1. user choice is a bad idea when it comes to security. Just remember the many SSL cert "click to proceed anyway pop-up windows/issues..." In most cases the user is not qualified to fully understand the consequences of his choice. And also if he is faced with the choice "no access" or "access", he/she will probably go for "access anyway". We have trained them that way the last few years. So I rather want to avoid a user choice as much as possible. 2. as you seem to advocate a hard limit of 30 days. Could you think of browsers refreshing their PINs before expiry automatically? (i.e. without the user actually visiting the site?) And question to all: would this open Pandora's box in terms of privacy etc. as we would leak the list of pinned sites to servers in the middle? Best regards, Tobias On 23/05/13 01:14, Chris Palmer wrote: > Hi all, > > Looks like these are the options: > > 1. No hard limits, but allow UAs to limit the pin time. Suggest a month > > 2. Set a hard limit of one month in the RFC. Longer pins are truncated. > > 3. No hard limits, but allow the UA to skip hard-fail if a pin hasn't > been observed for some time (like a month) > > 4. Adopt some gradual confidence-building scheme a-la-TACK. > > 5. No hard limits, leave limiting the pin time unspecified, make no > suggestion. > > (4) is a key differentiator for TACK, and I want to let TACK be TACK > and HPKP be HPKP. I consider both to be experimental features, and > having two very different proposals maximizes our experimentation > coverage. > > Any of (1, 2, 3, 5) is more or less fine by me; I'll go along with the > consensus. I see them as being on a spectrum of "fixity" or "definedness": > > least fixed . . . most fixed > 5 3 1 2 > > Perhaps in this time of experimentation, less fixed is better. Maybe > we can learn more about how well/not well pinning works, and then > publish a new version of the specification in the future. > > I posit that browsers will have strong incentives to fail open after > some reasonable max-max-age, even if the spec does not mandate it. > (For example, Chrome stops enforcing pinning completely if it > recognizes that its own build date is more than 10 weeks in the past: > a browser that old is definitely an indicator of some kind of problem, > and we want users to be able to recover.) So, not mandating a limit is > not as dangerous as it may seem, as a practical matter. > > However, Trevor compellingly argues: """Anyways, I think making things > safe and simple for site operators is more important than browser > creativity, or trying to maximize pinning's security benefits. That's > why I still prefer a spec-mandated limit. And I think 30 days strikes > a good balance between security benefits and safety, and is easy to > remember and explain.""" > > I am less compelled by the argument that rarely-visited sites will get > no protection from pinning if the max-max-age is as low as 30 days, if > the fail-open behavior is to provide the user a warning/notice/choice: > > Hey, you haven't visited yourbank.com <http://yourbank.com> > recently enough for us to be highly > confident that it's the real yourbank.com <http://yourbank.com>. > Everything else checks out, so > we still have good confidence. > > [ I'm OK with good confidence, proceed anyway ] [ Oops, go > back ] > > So, my vote is for (3). > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
