Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)

Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 04 January 2012 10:05 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 9B21F21F870E for <websec@ietfa.amsl.com>; Wed, 4 Jan 2012 02:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Level:
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 6sSCcvufqzdy for <websec@ietfa.amsl.com>; Wed, 4 Jan 2012 02:05:41 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEF721F870D for <websec@ietf.org>; Wed, 4 Jan 2012 02:05:39 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=WtR3SgRfa4Sj0cQKwa28i8J67mp6xYw1HglCXhmjtPP+ePCWgDAySnUY8jgultYfT9chN7bkELNu+4WJf8Vx46z4/EcxPdWCaojXK7XtVKPoExhAjzQ+eJPuZGbMgoX7; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 3218 invoked from network); 4 Jan 2012 11:05:26 +0100
Received: from unknown (HELO ?10.5.8.84?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Jan 2012 11:05:26 +0100
Message-ID: <4F042462.9080206@gondrom.org>
Date: Wed, 04 Jan 2012 10:05:22 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0
MIME-Version: 1.0
To: websec@ietf.org
References: <4F023DD0.8060308@KingsMountain.com> <D4D8FBAE-C04C-4396-A8B8-17F42874B1DF@checkpoint.com> <4F02BABA.9070304@gmx.de>
In-Reply-To: <4F02BABA.9070304@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] default value for max-age ? (was: Re: Strict-Transport-Security syntax redux)
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: Wed, 04 Jan 2012 10:05:41 -0000

On 03/01/12 08:22, Julian Reschke wrote:
> On 2012-01-03 07:26, Yoav Nir wrote:
>> On Jan 3, 2012, at 1:29 AM, =JeffH wrote:
>>
>>> Julian wondered..
>>>>
>>>> wouldn't it make sense to have a default for max-age so it
>>>> can be made OPTIONAL?
>>>
>>> hm ... I lean towards keeping max-age as REQUIRED (without a default 
>>> value) and
>>> thus hopefully encouraging deployers to think a bit about this and its
>>> ramifications, and also because its value is so site-specific in 
>>> terms of a web
>>> application's needs, deployment approach, and tolerance for downside 
>>> risk of
>>> breaking itself.
>>
>> I tend to agree, but it's not deployers who are going to do the 
>> thinking - it's the implementers of web servers.
>>
>> So somewhere, in some control panel for IIS, or a config file for 
>> Apache, or some WebUI for some SSL-VPN, there's going to be a 
>> configuration to turn on HSTS, and that product is going to have a 
>> default max-age. The deployers are just going to check the box.
>>
>> I think we should provide guidance for those implementers as to what 
>> is a good default there.
>> ...
>
> If we know a good default then it should be the default on the wire 
> (IMHO). It would help getting predictable behavior when it's missing. 
> (Right now the spec allows recipients to do anything they want then 
> it's missing, right?)
>
> Best regards, Julian
>

<hat="individual">
well, the optimal default may actually be depending on the host.
So we might want to describe what good values might be under which 
circumstances.
E.g. long time-spans when using very trusted process and provider, 
shorter time-spans with less capable / higher risk of bricking yourself 
/ loosing your private key / ...

Thinking about the idea default of max-age = 0: AFAIK this would be 
equivalent to it being disabled, correct? (Not sure I'd like that: 
imagine in an Admin GUI you enable HSTS/Cert Pinning and then don't set 
the max-age and have basically disabled it....)
On the other hand I believe the optimal value would be host specific, 
and therefore there SHOULD NOT be a global default value !=0. :-(
(=> Thereby vanishing myself in a puff of logic...)

Best regards, Tobias