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

Trevor Perrin <> Thu, 23 May 2013 15:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DA7111E8119 for <>; Thu, 23 May 2013 08:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.48
X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WtED2S2UujcW for <>; Thu, 23 May 2013 08:17:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::234]) by (Postfix) with ESMTP id C2FED11E8132 for <>; Thu, 23 May 2013 08:17:58 -0700 (PDT)
Received: by with SMTP id t60so1185963wes.25 for <>; Thu, 23 May 2013 08:17:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=FPGaL+yODO0ncatUxv+Z75w9JSeJBfkQDc3z1Y3DC14=; b=Ut0EpQnOOUK/xrTUQOxEs9CqiTMyvvQE28bpxkaxGZJ/Db7AL7AdN82a0FTDeriP9+ HbRY33jRB2vagSI1OnP075tM579Nrey0f1KqnnP82WvanuuhjZA4K9EdI6EbJe9MuVxu Ysxe9VFzXPPRNiNqih/jyrncnRlHuxUswb4ruHDVPdzj8kb0z3WEvTeTMawCqztuRzuQ mDntQB8BtMi0fT/8Pgg6Ere0XY+WmG5ke5KsnwIO7Hblt+C1i4JN3hyOjNvtFWOem52f yEqQwH+ydlEoJiVJui6Y+ZuGz9YzM1QEP78bsoGGc50apfhfnjg/cljzpASjAv9MIb/f A6kg==
MIME-Version: 1.0
X-Received: by with SMTP id ez9mr25444707wid.8.1369322277616; Thu, 23 May 2013 08:17:57 -0700 (PDT)
Received: by with HTTP; Thu, 23 May 2013 08:17:57 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Thu, 23 May 2013 08:17:57 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Daniel Veditz <>
Content-Type: multipart/alternative; boundary=f46d0438eb9ff0d8eb04dd642f42
X-Gm-Message-State: ALoCoQlre/n/uLkLZ7weVTDtilHjkGuStFeG8IIqKdAYrWe4I/knDQE/6gImsay5gIUx8nXdTwFt
Cc: IETF WebSec WG <>
Subject: Re: [websec] Consensus call: Issue #57 (max-max-age)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 May 2013 15:18:03 -0000

On Wed, May 22, 2013 at 7:43 PM, Daniel Veditz <> wrote:

> On 5/22/2013 3:29 PM, Trevor Perrin wrote:
>> 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].
> Note that Mozilla currently requires sites to specify an HSTS pinning time
> of at least 18 WEEKS to be included in the pre-load list. There was concern
> that sites with shorter pins could have stopped using HSTS by time that
> version of the browser shipped. I personally think that's a little strict,
> but even if we relaxed the requirement to the length of a Beta cycle that's
> still a longer period of time (6 weeks) than the maximum 30 days you're
> suggesting.

Hi Daniel,

That seems like a downside of compiling preloads into browser binaries, as
done by Chrome and Firefox.

But it looks like Google and Mozilla have both considered having the
browser query a service to update a local list.  That seems like a better
approach, since it would eliminate this problem of shipping a build with
pin information that is several weeks stale, and can only be updated with a
new browser binary.
"As both the pinning list grows, and our desire to have a consistent
pinning list across all versions of Chromium, we should look to move the
static pin database into a module that may be updated independently of the
main Chromium binary."
"There are two ways to accomplish this:
1. Hard-code the list in each shipping version of Firefox
2. Stand up a service (like blocklist ping) that serves the list upon