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

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 16 May 2013 07:53 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 BFCF521F8797 for <websec@ietfa.amsl.com>; Thu, 16 May 2013 00:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.362
X-Spam-Level:
X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 PhbJcc2kc1tw for <websec@ietfa.amsl.com>; Thu, 16 May 2013 00:53:45 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 01F3421F859D for <websec@ietf.org>; Thu, 16 May 2013 00:53:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=EHkrcF0eZs6rIdIxur3vfck//ixGgkq43ewBdtPcNTEnEFhoQ7tPtRWZkIgI5A4bfcSfUNPnBF47FzA/BVcK9+IM1/N70D/fX6q8CzTC+WxSIa0mTlzkZQPfIFmQsloW; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 15767 invoked from network); 16 May 2013 09:53:43 +0200
Received: from 188-223-226-249.zone14.bethere.co.uk (HELO ?192.168.1.80?) (188.223.226.249) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 May 2013 09:53:43 +0200
Message-ID: <51949087.9020307@gondrom.org>
Date: Thu, 16 May 2013 08:53:43 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: websec@ietf.org
References: <43C5DE99-43EB-42FC-8F61-24F9A9429FD1@checkpoint.com> <CA+cU71=Q_QkHqiQ95AZgw8Bi7U_mgCi4icMypwFUp1C6i=apUA@mail.gmail.com>
In-Reply-To: <CA+cU71=Q_QkHqiQ95AZgw8Bi7U_mgCi4icMypwFUp1C6i=apUA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Thu, 16 May 2013 07:53:49 -0000

<hat="individual">

I agree with Tom.

Tobias




On 11/05/13 21:09, Tom Ritter wrote:
> 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.
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec