<hat="individual"> Hi all,
as mentioned before: I believe a time limit of 1 month is too short considering that some of the high profile use cases (banks, etc.) may only have monthly or bi-monthly usage. In which case the key pin would regularly expire before people return to the site and the protection is null. And regarding some of the concerns of pro-longed malicious bricking by an attacker after an attack has been resolved: Two scenarios: 1. I believe if we have a time limit of more than 1 month we need a different mechanism (e.g. user actively flushing the key cache) anyway. 2. in the case of high frequency sites (like you mentioned Facebook), imagine even a 1 month brick time would already be considered unacceptable too long by most users (in fact probably everything above a few hours would be considered too long) and trigger user action to flush the cache. Best regards, Tobias On 12/05/13 12:57, Yoav Nir wrote: > 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 _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
