Hi Yoav, On Tue, May 21, 2013 at 3:26 PM, Yoav Nir <[email protected]> wrote:
> Hi Trevor > > <no hats> > > The suggestion that web spiders also note pins is interesting, but it's > not mentioned in the draft at all. > I think this possibility should be mentioned. The draft discusses "Preloaded Pin Lists", which are presumably conveyed to the UA from some 3rd party (eg browser vendor). It seems reasonable for such lists to be created or kept fresh by scanning web sites. I believe Mozilla is taking this approach to HSTS [1]. Besides preloaded lists, there's other proposals that could discover pins based on scans and then send fresh pins to clients (Convergence, S-Links, Omnibroker, etc.) So I think the draft should endorse the idea that pins might be discovered by one party, then used by a second party. If we agree this is a possible way to use server-asserted pins, then we shouldn't assume that a 30-day pin is always worthless to a UA who can't contact a site every 30 days. > So I believe that we have to take the draft at face value, that it is user > agents that are supposed to note pins. BTW: assuming that relatively few > sites have pins, it is also possible for the browser itself to load pages > in the background to refresh the list of pins. > Seems like a privacy risk to have the browser connecting back to pinned sites on some interval. Eg: you're at a coffee shop and your browser decides to refresh pins for your embarrasing hobby sites. Someone observes these queries via sniffer... If the global set of pins is small enough, the browser could periodically fetch the entire thing (or the most important 10,000 pins, say). I think that's a practical, simple example of using 3rd-party infrastructure. > Either way, we have to assume that the pin is noted by a user agent and is > noted again only when the user clicks a link or types in the address again. > I don't think we want to require anything else. > > I do agree that a spider or the browser itself can periodically check on > pins. > > You go on to note three cases where limiting the max-age may be > beneficial: > > 1) Domain name transfers (sales, disputes, reclaiming hijacked > domains, etc.) > 2) Preventing long-term lock-in. E.g. you are pinned to CA keys which > you lose trust in and suspect might be participating in MITM attacks; you > are not bricked, but you are unable to change to a different CA and assert > new CA pins until the old pins expire. > 3) Pruning the amount of pin history you must keep your site consistent > with (Do you remember what pins you or the previous domain owner asserted 6 > month ago? 6 years ago? ever? They might still be out there, waiting to > trip you up). > > > #2 and #3 make sense, but they only make sense as reasons to set max-age > to a relatively short value. It may be good to incorporate this as advice > to the administrator as to what to set max-age to. They are not a good > reason, IMO, to set a hard limit in the protocol. > Not sure I agree. #2 and #3 are consequences of long-lived bad pins (lock-in to keys/CAs; and uncertainty over what pins might have been asserted by previous sysadmins, domain owners, or attackers). But these bad pins could arise from site mistakes, attacks, or previous domain name owners, so asking sites to assert short-lived pins doesn't guarantee they won't happen. I'll try to break down the proposals for pin lifetimes: A) Sites assert short-lifetime pins B) UAs choose their own pin-lifetime limit C) Spec limit (A) doesn't help with site mistakes, domain name transfers, or attacks (disgruntled site administrator, hacker, or domain hijacker setting bad pins, etc). (B) doesn't give sites a guaranteed recovery period after which any bad pins will disappear. Let's say you acquire a new domain name, or you suspect the previous admin was sloppy with pins, or a hacker might have set bad pins. If UAs can do whatever they want, then you can't be sure there aren't bad pins hanging around somewhere, from *anything* that might have happened *anytime* in the past. Even if your domain seems to be working, there could be bad "report-only" pins that are reporting on your users, or that are locking you in to your current CA and which you might not discover until you actually try to change CAs (months or years later)... Anyways, a spec limit solves these problems - no matter what mistakes, ownership changes, or attacks a domain name suffers, the site has a hard guarantee that only the last 30 days of pin assertions matter. Trevor [1] https://blog.mozilla.org/security/2012/11/01/preloading-hsts/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
