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

[Tobias Gondrom <[e-mail]>]

<hat="individual">

Hi Trevor, hi all,

thanks for the thoughts.
Maybe a few comments and a question inline.


On 18/05/13 18:40, Trevor Perrin wrote:
>
> Hi Tobias, all,
>
> I think Tobias gives a fair summary of the arguments against a 30-day
> spec limit.  Let me summarize the opposing arguments:
>
>
> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>
>     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.
>
>
> You're assuming that pin assertions (like HPKP headers) are only
> processed by individual browsers. 
>
> I hope pin assertions will *also* be processed by web crawlers to
> create pin lists which are made available to browsers (via preloaded
> lists, secure links, online lookups, etc.)
>
> In that case, having pins last a month (instead of shorter) keeps the
> frequency of re-crawling sites and re-downloading pin lists
> manageable.  Longer pins wouldn't be a big improvement.#

The web crawler idea could be interesting as a solution to early pin
expiry if we would have a hard limit in the RFC, but only if _all_
browsers will implement and use them. Which from my current
understanding is not on the horizon. At least I have seen no such
indications. Otherwise you get the varying implementations through
"creative approaches" you are worried about down below (and which I
don't like either).

And maybe a question to go a step further:
Would you agree that if we would do a 30-day hard limit as you propose,
this would basically mean that all less frequent banking/paypal/...
users MUST (or a very strong SHOULD) use such a web crawler to make sure
that their pin has not expired before they come back?
This would be a big problem in my eyes, as IMHO this assumption can not
be guaranteed nor expected to be rolled out consistently.

>  
>
>     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.
>
>
> Agreed that a 30-day limit is not, by itself, sufficient mitigation
> against "malicious bricking by an attacker after an attack".  I
> suspect pinning will need several additional mechanisms to prevent,
> limit, and recover from such attacks.  "Pin activation" is one
> mechanism I think is particularly helpful, for this case.
>
> A 30-day spec limit is more important for other reasons:
>  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).

Hm, in my view case #2 and #3 are about your own pinning time frames and
should be ok with recommendations, but would not require hard limits in
the draft. And in fact as we have multiple pins in the header we have a
migration path from A to B during that transition.

Reading your cases, it feels to me #1 the malicious domain name transfer
is the strongest case.
Is that in your opinion as well?
I am wondering how often that would happen? And whether we should not be
solving this through other means? (e.g. flushing the cache, reseting
this domain pin due to legal action or whatever?)

Overall, I still think it would be better not to assert a hard time
limit of 30 days in the doc.

(and if at all a time limit would be there, it should be at least 60
days, to cover users who revisit sites once per month which I imagine
many banking etc. users may do...).

I would be very interested to also read from others on the mailing-list
and the editors of the draft about their opinion on the web crawler, and
the use cases?

Best regards, Tobias