Re: [websec] #57: Re-add an upper limit to max-age

Trevor Perrin <> Fri, 05 April 2013 07:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8130121F9473 for <>; Fri, 5 Apr 2013 00:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.479
X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G5CYb8gtwghk for <>; Fri, 5 Apr 2013 00:03:12 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) by (Postfix) with ESMTP id C950F21F942C for <>; Fri, 5 Apr 2013 00:03:11 -0700 (PDT)
Received: by with SMTP id c10so264675wiw.2 for <>; Fri, 05 Apr 2013 00:03:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4BRk/pBCPpRLVn/wYDRD4cd3s128roCDiWfpxwQ/DYM=; b=ZMdVHb9tLIePwCzi0845os0Gze42N6qXJWRl8NhmDzSD9rl1Xn2kwd4tILXyMLrvaT bnJngPe69ppNtntLgKvNmi6bzoktWbqoAvBvx5QNPxuQ4ZF3gqLM9r4th7tF/Hn9rnDK wM1Nr6HQS9WiDiTsIFn6h0EO5zGgve6paMKDnDVBX9FBvkd9KJCZ66WWzaTFvt0E+hXM LN6aB1jx30R/HCdV3BXlvFGOE0H3r1CpPiZwoGXM6FIkmnE+FYSnw5DsA8eM49iW9tGm Mhz6khrCx2WQfeCsTb5PpxyX+556k7vKyHrnL73A0aV7hSCWB/06x1+NWjpuBX3nDdkf XqRA==
MIME-Version: 1.0
X-Received: by with SMTP id az10mr2001807wib.3.1365145390807; Fri, 05 Apr 2013 00:03:10 -0700 (PDT)
Received: by with HTTP; Fri, 5 Apr 2013 00:03:10 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Fri, 05 Apr 2013 00:03:10 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Yoav Nir <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQmlQouryXzeZBycxmvHDT/SQQSGP46AGDwy4wbZ6gEPMLtW8obAiLotdxCt86F9WHQPKbmi
Cc: "<>" <>, Ryan Sleevi <>, websec issue tracker <>
Subject: Re: [websec] #57: Re-add an upper limit to 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: Fri, 05 Apr 2013 07:03:12 -0000

On Fri, Mar 29, 2013 at 7:05 PM, Yoav Nir <> wrote:
> Getting back to the subject of the thread, I still don't see the difference for a site operator between being bricked for 60 days and being bricked for a year. For an only retailer it's catastrophe either way.

Hi Yoav,

There are other things to consider when thinking about pin lifetimes:

 - Suppose a site foolishly sets a year-long pin to keys that will be
expired in 6 months.  A client who receives this pin and then visits
the site 6 months later will perceive that the site is bricked for the
next 6 months.

 - Suppose a site has a year-long pin to a set of end-entity keys.
Suppose these keys are compromised by a hacker.  For the next year,
the site will be unable to change keys to re-establish security
without a risk of "bricking" the site for clients with the old pin.

 - Suppose you purchase a domain name.  The previous owner may have
set long-term pins, meaning the name is not fully usable until these

So this isn't just a question of "how long might a site outage last".
Longer pin lifetimes increase the *possibility* of a site outage,
because there will be more old pins out there you have to stay
consistent with.

I do agree that a 30 or 60 day limit will be cold comfort if you brick
your site for that long.  Certainly, pinning will need other

One safeguard could be some sort of "pin activation", where new or
changed pins are not accepted immediately, but must be observed for
some period of time before they "activate".  I know this WG considered
a mechanism similar to TACK.  TACK's exact mechanism doesn't translate
well to HPKP, but perhaps there is something else to be done.  It may
be worth more thought.