[websec] handling STS header field extendability

=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 09 August 2012 22:09 UTC

Return-Path: <Jeff.Hodges@KingsMountain.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 8AF8421F86AD for <websec@ietfa.amsl.com>; Thu, 9 Aug 2012 15:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.561
X-Spam-Level:
X-Spam-Status: No, score=-99.561 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=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 bEAzya51nVRP for <websec@ietfa.amsl.com>; Thu, 9 Aug 2012 15:09:52 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 8498221F8606 for <websec@ietf.org>; Thu, 9 Aug 2012 15:09:52 -0700 (PDT)
Received: (qmail 28696 invoked by uid 0); 9 Aug 2012 22:09:51 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 9 Aug 2012 22:09:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yuFuPHKxRZWtxQDPeaT8duNauGgb8cVF2biruB7U3II=; b=NNAT759sy301VaX53y74dj3O+P0JXCjgK2HVuqk2L2iKeE/K9I1Gl90toOilxW9eOgVjM8YTB18U7hwT6PFamj8YfbnzWUZ6/ZiY0ZTt5zELNT4fJMXFlEKlLjV++iCC;
Received: from [24.4.122.173] (port=38213 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SzavP-0004t1-MQ; Thu, 09 Aug 2012 16:09:51 -0600
Message-ID: <5024352D.4040604@KingsMountain.com>
Date: Thu, 09 Aug 2012 15:09:49 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: Ben Campbell <ben@nostrum.com>
Subject: [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: Thu, 09 Aug 2012 22:09:53 -0000

Hi, here's a write-up on the background of, and proposed resolution to the 
question of handling STS header field extendability more properly in the spec.

I also pose the question of which IANA policy to declare, down at the very end.

thanks,

=JeffH


Background:
----------

We've defined the Strict-Transport-Security (STS) header field like so..

      Strict-Transport-Security = "Strict-Transport-Security" ":"
                                  [ directive ]  *( ";" [ directive ] )


      directive                 = directive-name [ "=" directive-value ]
      directive-name            = token
      directive-value           = token | quoted-string


..such that the definition of new directives is open-ended, i.e., the STS header
field is extendable.

draft-ietf-websec-strict-transport-sec-11 presently states 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
    defined for them at such time.


The only extensions we'd discussed in the past were the CertPinning, LockCA,
LockEV.  We've decided that cert pinning is an intersecting but orthogonal
policy to HSTS, and thus best handled at this point via a separate header field.
Also, the various LockFoo notions should be addressed in a cert pinning policy
context (i mentioned this in the WG session at IETF-82 Taipei).

Thus we don't have any presently anticipated extensions for the STS header field.

However, I don't believe we wish to change the (implicitly extensible) maner in 
which the ABNF is specified, nor necessarily close the door to defining some 
extension if we happen to come up with an appropriate need.


The IETF-84 Vancouver, WebSec WG meeting minutes [1] state on this topic..

   The group then discussed the registry management, particularly around
   “mandatory to understand” extensions. The sense of the room was that the
   group did not want to create mandatory to understand extensions ever. If
   such extensions are needed, they will need a new header. Where the draft
   says other specifications can update this one, say that any necessary
   registries may be created when such an update comes around.

Note that -11 already states that a registry should be created at that time. Ben 
indicated in his review that it isn't sufficient in his view (below).


Ben replied directly to me regarding the meeting minutes...
 >
 > I think we may be conflating two mostly orthangonal comments:
 >
(a)
 > -- If the working group doesn't expect "mandatory to understand" extensions,
 > then I'm fine with it, other than thinking it might be worth noting that any
 > such extensions must be safe to ignore.
 >
(b)
 > -- My questions about a registry don't depend on the mandatory to understand.
 > I'm skeptical of any draft that says "you can extend this, but we will leave
 > the creation of a registry until someone actually does it." In particular,
 > this defers making decisions about the documentation policy for extensions
 > (rfc5226 section 4.1), which is rarely a good idea. The only situation where
 > it seems to make sense to defer the registry would be if you really didn't
 > expect any extensions--in which case the draft probably shouldn't mention
 > extending it.
 >
 > That all being said, please keep in mind that I, as a gen-art reviewer, am
 > only offering my opinion like anyone else. It's up to the work group and the
 > ADs to decide if they agree with me or not. So it's okay to say "We disagree
 > with Ben here, and choose to leave it as is".


Proposed Resolution:
-------------------

For (a)

The spec already notes that UAs must ignore unrecognized directives. in any case 
I've composed a note regarding furture-defined directives being ignored by 
(legacy) UAs.


For (b)

Alter the spec text to include a reference of the required IANA Policy for any 
defined registry.

NOTE: we need to decide the type of IANA Policy (more below)

The spec text I now have in my -12 working copy at the end of section 6.1 is..

    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.


We need to decide what IANA policy definition [RFC5226] we wish to declare for 
FOO in the above text.

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 here.

thoughts?

[1] https://www.ietf.org/proceedings/84/minutes/minutes-84-websec

---
end