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

Tom Ritter <tom@ritter.vg> Sat, 11 May 2013 20:10 UTC

Return-Path: <tom@ritter.vg>
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 5F6BC21F8930 for <websec@ietfa.amsl.com>; Sat, 11 May 2013 13:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 j+au268Xps74 for <websec@ietfa.amsl.com>; Sat, 11 May 2013 13:10:13 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7C821F8916 for <websec@ietf.org>; Sat, 11 May 2013 13:10:13 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id s9so10004387iec.20 for <websec@ietf.org>; Sat, 11 May 2013 13:10:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qFW+GWysbxQr0RAD4cI/SJwwfDB0f3KAB7N8obnwzqw=; b=c3z7hBajoLrI6LU4I0Bi0JZKWBqi2Hcil68INKZyy6RjKf/LzVQdR2bYO8WOibdwQB 1VqEeWjLc1sGlD0Ow3CzILA+wLM0s73ZvBmNrQJeyUjBXqi1BnnnHlio/9s6tpop3FP4 NocEBBYMMbnIQM/eQnEhdFrLCwSYcad9MFSzY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=qFW+GWysbxQr0RAD4cI/SJwwfDB0f3KAB7N8obnwzqw=; b=jpUhIHp5VvpbPv6Z2iuSflFjyC+nPRGK4r0Tdg8pu/6x18jRwpBwj3Humz8KIBEnV7 oYXozYw5xKCBsv8cEB27GiBYvp7EbGWm9/9dioC1Ffu0U272X/ArL5txXAxLujExc4vi xdCNNuwObWR09LJJk7/livkJaVdAum3OgjS+s2hCmGZay+Hv4n944wQrOq/Fctwv4wuF lCvRkvamQGaMC5q37x+mUPo4NW/JvImh4wLqFGdFlrPTwKVBKeXYs4/hEKG5IJVcz6Vi 7+/i2Wwrko/0qQmjMMah6Gzm3dFYNRvCH665AGoHth/TQtMpD7vyNZ5r0h17hwWKkDSZ xh7g==
X-Received: by 10.50.25.102 with SMTP id b6mr5788199igg.27.1368303012655; Sat, 11 May 2013 13:10:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.20.72 with HTTP; Sat, 11 May 2013 13:09:52 -0700 (PDT)
In-Reply-To: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com>
References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com>
From: Tom Ritter <tom@ritter.vg>
Date: Sat, 11 May 2013 16:09:52 -0400
Message-ID: <CA+cU71=Q_QkHqiQ95AZgw8Bi7U_mgCi4icMypwFUp1C6i=apUA@mail.gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQnoDY3Z4H02FrGScLRGHiA7HzqCqhpdcxuFPnwiHDvYaZNtXW0xqQCgAiog9vD3FZWNxaVo
Cc: IETF WebSec WG <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
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, 11 May 2013 20:10:14 -0000

On 7 May 2013 03:13, Yoav Nir <ynir@checkpoint.com> wrote:
> How should we handle the max-max-age issue:
>  (1) No hard limits, but allow UAs to limit the pin time. Suggest a month
>  (2) Set a hard limit of one month in the RFC. Longer pins are truncated.
>  (3) No hard limits, but allow the UA to skip hard-fail if a pin hasn't been observed for some time (like a month)
>  (4) Adopt some gradual confidence-building scheme a-la-TACK.
>
> "None of the above" is possible, but MUST come with argument and proposed text.


None of the above:  No hard limits, leave limiting the pin time
unspecified, make no suggestion.  I don't believe any text changes are
necessary.

I think UAs that are sufficiently worried about websites bricking
themselves come up with creative solutions that work well for them,
but may not be applicable to others.  (Chrome's will (or would) expire
hardcoded pins if there hasn't been a Chrome update in a month - they
could do the same for max-ages.)  I don't like the idea of suggesting
that UAs unilaterally override a site's possible desire to pin for
more than 1 month.

-tom.