Hi Martin Such guidance in the spec is relevant for the rightful domain owners. Suppose an attacker got some CA to issue a bad certificate for facebook.com. The attacker now sets up this certificate on some public proxy, and sets a pin for 20 years. Within days the attack is discovered, the certificate revoked and the fake website taken down. But the user-agents that received this pin are blocked from reaching facebook. A limit would help by getting them off of facebook for just 1 month.
Also, if a domain name is sold or transferred to another entity, a long-lived pin could mean that the new owner can't put a website there. I'm not saying these are compelling arguments to limit pins in the UA, but they should be considered. Yoav On May 12, 2013, at 3:40 AM, Martin J. Dürst <due...@it.aoyama.ac.jp> wrote: > I agree with Tom Ritter, with one caveat: The spec should very clearly call > out the issue (balance between too soon pin expiry and too long), rather than > not mentioning it. I haven't found such language (i.e. guidance to UA > implementers) in the document, but I might have looked in the wrong place (I > looked at every piece of text that contained the three letters 'max'). > > Regards, Martin. > > On 2013/05/12 5:09, Tom Ritter wrote: >> On 7 May 2013 03:13, Yoav Nir<y...@checkpoint.com> wrote: >>> How should we handle the max-max-age issue: >>> (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. >>> >>> "None of the above" is possible, but MUST come with argument and proposed >>> text. >> >> >> None of the above: No hard limits, leave limiting the pin time >> unspecified, make no suggestion. I don't believe any text changes are >> necessary. >> >> I think UAs that are sufficiently worried about websites bricking >> themselves come up with creative solutions that work well for them, >> but may not be applicable to others. (Chrome's will (or would) expire >> hardcoded pins if there hasn't been a Chrome update in a month - they >> could do the same for max-ages.) I don't like the idea of suggesting >> that UAs unilaterally override a site's possible desire to pin for >> more than 1 month. >> >> -tom. _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
