Re: [websec] handling STS header field extendability

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 18 August 2012 10:44 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 1B20A21F8539 for <websec@ietfa.amsl.com>; Sat, 18 Aug 2012 03:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.964
X-Spam-Level:
X-Spam-Status: No, score=-96.964 tagged_above=-999 required=5 tests=[AWL=-1.602, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOhRnetVcPId for <websec@ietfa.amsl.com>; Sat, 18 Aug 2012 03:44:41 -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 2E9CD21F8546 for <websec@ietf.org>; Sat, 18 Aug 2012 03:44:39 -0700 (PDT)
Received: (qmail 10175 invoked from network); 18 Aug 2012 12:44:37 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2012 12:44:37 +0200
Message-ID: <502F7214.6010102@gondrom.org>
Date: Sat, 18 Aug 2012 11:44:36 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: websec@ietf.org
References: <502ECBD3.6050902@KingsMountain.com> <B80C8460-9C37-4BFC-B4F0-D757E9FB3290@checkpoint.com>
In-Reply-To: <B80C8460-9C37-4BFC-B4F0-D757E9FB3290@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] handling STS header field extendability
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, 18 Aug 2012 10:44:42 -0000

On 18/08/12 07:21, Yoav Nir wrote:
> On Aug 18, 2012, at 1:55 AM, =JeffH wrote:
>
>> Yoav Nir noted:
>>> As a reminder, the proposed resolution is as follows:
>>>
>>> * Do not establish a registry now
>>>       Let the first new header field specification establish it
>>>
>>> * A client that gets an unknown field ignores it
>>>       This means no mandatory-to-understand extensions
>> Thanks, Yoav.
>>
>> I'd also noted that we need to decide on a IANA policy to declare.
> Do we need to do this?  Assuming the proposed resolution achieves consensus (and there have been no nays yet), we're not setting up a registry. I don't think we get to set a policy for a registry we're not setting up.

<hat="WG chair">
AFAIK from an administrative perspective, Yoav is right.
In general we set the IANA policy for registry updates at creation of 
the registry. So no need to do it here without the registry (assuming we 
don't create an IANA registry).



>
>
>> My original message is here..
>>
>>    https://www.ietf.org/mail-archive/web/websec/current/msg01315.html
>>
>> ..and I suggested that, since HSTS is a security policy, I lean towards wanting
>> to have relatively rigorous review applied to any registry and its contents
>> created for HSTS directives and thus am thinking a policy of "IETF Review" is
>> what we ought to state (for "FOO" in the below excerpt from -12 at the end of
>> section 6.1)..
>>
>>     Additional directives extending the semantic functionality of the STS
>>     header field can be defined in other specifications, with a registry
>>     (having an IANA policy definition of FOO [RFC5226]) defined for them
>>     at such time.
>>
>>     NOTE:  Such future directives will be ignored by UAs implementing
>>            only this specification, as well as by generally non-
>>            conforming UAs.  See Section 14.1 "Non-Conformant User Agent
>>            Implications" for further discussion.
>>
> HSTS is a security policy. Suppose an extension requires that the certificate contain a logo. Is that security-relevant?  According to section 2 of RFC 5226, policies are made to avoid hoarding of resources (I don't think that's relevant here), and to make sure it makes sense. I think "expert review" would be OK, but I don't think we need to bother with deciding this now.
>
> Yoav
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec