Re: [websec] Consensus call: Issue #57 (max-max-age)
"Ryan Sleevi" <ryan-ietfhasmat@sleevi.com> Wed, 22 May 2013 22:45 UTC
Return-Path: <ryan-ietfhasmat@sleevi.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299F21F90DF for <websec@ietfa.amsl.com>; Wed, 22 May 2013 15:45:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjWI6CAub7Ck for <websec@ietfa.amsl.com>; Wed, 22 May 2013 15:45:51 -0700 (PDT)
Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 0F02E21F90D2 for <websec@ietf.org>; Wed, 22 May 2013 15:45:51 -0700 (PDT)
Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id BD9DCBC032; Wed, 22 May 2013 15:45:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=X0fJHMcyqd5oX6QqVGe1Xzk2tmw=; b=m8uOyrNDwJvezx6po l2QJjeoTSfMDzkrC+ELCc+aatp0EPk7AH/CX2R6f32Z07rpcL6L2aH2+UroIAJIl 8/kTZ2t8u+incurckTOJENRWQ/R7bgSAemdcMfb90zNSJDLFg4hs7HzgtVYAOMg6 jYntBwCF4JZkH6kp9FFSffmflE=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPA id 736A1BC031; Wed, 22 May 2013 15:45:50 -0700 (PDT)
Received: from 216.239.45.93 (proxying for 216.239.45.93) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 22 May 2013 15:45:50 -0700
Message-ID: <1da99e22e4f28c080510f136765a6bcb.squirrel@webmail.dreamhost.com>
In-Reply-To: <519D3CAB.80004@gondrom.org>
References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <CA+cU71=Q_QkHqiQ95AZgw8Bi7U_mgCi4icMypwFUp1C6i=apUA@mail.gmail.com> <518EE510.9060600@it.aoyama.ac.jp> <8450797E-818C-445C-ABD2-1B8F9AE1DBB9@checkpoint.com> <5194918A.7030300@gondrom.org> <CAGZ8ZG0SWZD9e-NP2RhQMQ-=F5JUCCytF2NYTdWH7u13hhBqqQ@mail.gmail.com> <519D3254.1040508@gondrom.org> <7189D6F0-1917-419C-80F6-E8A3002642EA@checkpoint.com> <519D3CAB.80004@gondrom.org>
Date: Wed, 22 May 2013 15:45:50 -0700
From: Ryan Sleevi <ryan-ietfhasmat@sleevi.com>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org
Subject: Re: [websec] Consensus call: Issue #57 (max-max-age)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ryan-ietfhasmat@sleevi.com
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 22:45:56 -0000
On Wed, May 22, 2013 2:46 pm, Tobias Gondrom wrote: > On 22/05/13 22:21, Yoav Nir wrote: > > Hi, Tobias > > > > On May 23, 2013, at 12:02 AM, Tobias Gondrom > > <tobias.gondrom@gondrom.org <mailto:tobias.gondrom@gondrom.org>> wrote: > > > > <snip /> > > > >>> On Thu, May 16, 2013 at 12:58 AM, Tobias Gondrom > >>> <tobias.gondrom@gondrom.org <mailto:tobias.gondrom@gondrom.org>> > >>> 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 > Sorry for not chiming in sooner, but I don't think we'd consider a polling based solution as being viable for implementation. We've certainly discussed these in-house and had discussions with other browser vendors, and I don't think anyone is too enthused with the idea. I can certainly understand and appreciate Trevor's concerns - and I haven't really had a chance to sit down and give them the considered response they deserve - but I did want to provide at least some feedback before we got too far out there onto the 'background polling' bandwagon. Cheers, Ryan
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- [websec] Consensus call: Issue #57 (max-max-age) Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tom Ritter
- Re: [websec] Consensus call: Issue #57 (max-max-a… Martin J. Dürst
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Ryan Sleevi
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Daniel Veditz
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Chris Palmer
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Yoav Nir
- Re: [websec] Consensus call: Issue #57 (max-max-a… Tobias Gondrom
- Re: [websec] Consensus call: Issue #57 (max-max-a… Sheehe, Charles J. (GRC-DPC0)
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin
- Re: [websec] Consensus call: Issue #57 (max-max-a… Sheehe, Charles J. (GRC-DPC0)
- Re: [websec] Consensus call: Issue #57 (max-max-a… Trevor Perrin