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 recently enough for us to be
highly
confident that it's the real 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
