Re: [websec] Consensus call: Issue #57 (max-max-age)

[Trevor Perrin <[e-mail]>]

Hi Yoav,

On Tue, May 21, 2013 at 3:26 PM, Yoav Nir <[e-mail]> 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/