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

[Tobias Gondrom <[e-mail]>]

On 22/05/13 22:21, Yoav Nir wrote:
> Hi, Tobias
>
> On May 23, 2013, at 12:02 AM, Tobias Gondrom
> <[e-mail] <mailto:[e-mail]>> wrote:
>
> <snip />
>
>>> 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.
>
> There is an alternative to the web crawler (although the crawler would
> be better). Your browser could refresh the pins in the background. If
> the pin is about to expire (say, in 7 days) and you have an Internet
> connection, the browser can silently open a connection to the server,
> see that the SSL handshake fits the pin, and refresh the entry in the
> local pin database. This won't scale very well if every site on the
> Internet has pins, but I don't really expect anyone to note more than
> several tens of pins (banking sites, some government, maybe things
> that accept credit cards). With less than 100 sites, you can make do
> with noting 3-4 pins per day, which shouldn't consume too much traffic.

Interesting idea.
And could this maybe also solve Trevor's concerns?

E.g. we could add to the spec some implementation advise, like "even if
the user does not visit the pinned sites, the browser SHOULD attempt in
the background to refresh recognized pins if they are about to expire or
before 30 days have passed...."

That way, pinning updates would come in earlier even though the visit is
maybe only monthly.
Could possibly solve Trevor's use cases #2 and #3?

Note: I would still not want the 30 day hard limit in the spec, because
I feel that this can give results that will be unexpected from a user
point of view...

Best regards, Tobias


>
> I guess browsers would stop refreshing pins if you don't visit the
> site for a year.
>
> Yoav
>