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

Yoav Nir <ynir@checkpoint.com> Sat, 23 March 2013 02:13 UTC

Return-Path: <ynir@checkpoint.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 5CDA621F8E7F for <websec@ietfa.amsl.com>; Fri, 22 Mar 2013 19:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.454
X-Spam-Level:
X-Spam-Status: No, score=-10.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 bszh6Bnv3Khj for <websec@ietfa.amsl.com>; Fri, 22 Mar 2013 19:13:40 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 69CF621F8E7E for <websec@ietf.org>; Fri, 22 Mar 2013 19:13:40 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2N2DJoN013629; Sat, 23 Mar 2013 04:13:19 +0200
X-CheckPoint: {514D0E66-0-1B221DC2-2FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 23 Mar 2013 04:13:19 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Joseph Bonneau <jbonneau@gmail.com>
Thread-Topic: [websec] #57: Re-add an upper limit to max-age
Thread-Index: AQHOJ0X4m4jM1OHiCUi5AgAOGVjbxZiyNAIAgAAIBoCAACvZgA==
Date: Sat, 23 Mar 2013 02:13:18 +0000
Message-ID: <C9FEEDC3-3178-4641-B9D2-6319183AD956@checkpoint.com>
References: <058.4066f40ba1a0e0b17085c25af1721605@trac.tools.ietf.org> <073.92e203ac2ffbca6a9b6ecd285f8d0e00@trac.tools.ietf.org> <CAGZ8ZG1HsW_SgB4OFRDPZT_3rUwsB8yvYxtE+fSpwLfoyrtHyg@mail.gmail.com> <CAOe4Ui=1ADLZsHrHpFofQW48DpERfAENH0a5zUFta81PejCNUA@mail.gmail.com>
In-Reply-To: <CAOe4Ui=1ADLZsHrHpFofQW48DpERfAENH0a5zUFta81PejCNUA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.41]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <609113009BA92D4690E8CDC657275E7B@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<websec@ietf.org>" <websec@ietf.org>, websec issue tracker <trac+websec@grenache.tools.ietf.org>, "<sleevi@google.com>" <sleevi@google.com>
Subject: Re: [websec] #57: Re-add an upper limit to max-age
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Sat, 23 Mar 2013 02:13:41 -0000

On Mar 22, 2013, at 7:36 PM, Joseph Bonneau <jbonneau@gmail.com> wrote:

> On Fri, Mar 22, 2013 at 7:07 PM, Trevor Perrin <trevp@trevp.net> wrote:
>> With a spec maximum (say 30 days), then you have a clear reference
>> point to plan around.
> 
> Agreed.
> 
> I have some stats I've been looking at from Google's web crawls about
> HSTS headers. Out of 12853 hosts I observed setting HSTS, 53% set of a
> max-age of 1 year. After that it's 15% 30 days, 12% 180 days, 10% 1
> day, and a smattering of other choices (with a few large hosts like
> Twitter setting very long-lived max-age).

As Ekr said in the meeting, there is a big difference here between HSTS and HPKP. It doesn't matter if Paypal or some bank advertises HSTS for a million years. It's not likely that someone who has declared a policy for always using secure transport will suddenly switch to non-secure transport. They might stop advertising HSTS, but they're not likely to stop insisting on TLS use.

OTOH a particular public key might be replaced because of switching certificate vendors, because auditors don't like that key length any more, or because your certificate vendor has decided that ECC is the way to go. Pinning something that has an expiry date for an unlimited time could be a problem.

Something to consider is that if the max-age time is shorter than the time between accesses to the site, the security of this mechanism is lost. If either the draft or the UA sets an upper limit of 30 days, then HKPK won't work for pub.ietf.org. This is a site that I only use from one week before an IETF meeting to one week following it. In between there are a little over three months where I don't use the site at all. So it would make sense for the site operator to set a max-age of 4 months. That limit may be inappropriate for web mail or social media, but even those might be accessed from different UAs at different times. For example, I might use my home computer for a social media site while I'm at home, but use a smart phone or a laptop for the same site when I'm away from home. 

I understand Trevor's issue. Does it make a difference to a site operator whether the site is partially bricked by bad pins for 30 days or 365 days?

Yoav