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
Cc: Ben Campbell <ben@nostrum.com>
Subject: [websec] handling STS header field extendability
Precedence: list

Hi, here's a write-up on the background of, and proposed resolution to th=
e=20
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 ver=
y end.

thanks,

=3DJeffH


Background:
----------

We've defined the Strict-Transport-Security (STS) header field like so..

      Strict-Transport-Security =3D "Strict-Transport-Security" ":"
                                  [ directive ]  *( ";" [ directive ] )


      directive                 =3D directive-name [ "=3D" directive-valu=
e ]
      directive-name            =3D token
      directive-value           =3D token | quoted-string


=2E.such that the definition of new directives is open-ended, i.e., the S=
TS header
field is extendable.

draft-ietf-websec-strict-transport-sec-11 presently states at the end of =
section=20
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, Lock=
CA,
LockEV.  We've decided that cert pinning is an intersecting but orthogona=
l
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 p=
olicy
context (i mentioned this in the WG session at IETF-82 Taipei).

Thus we don't have any presently anticipated extensions for the STS heade=
r field.

However, I don't believe we wish to change the (implicitly extensible) ma=
ner in=20
which the ABNF is specified, nor necessarily close the door to defining s=
ome=20
extension if we happen to come up with an appropriate need.


The IETF-84 Vancouver, WebSec WG meeting minutes [1] state on this topic.=
=2E

   The group then discussed the registry management, particularly around
   =93mandatory to understand=94 extensions. The sense of the room was th=
at 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 dra=
ft
   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 ti=
me. Ben=20
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" exten=
sions,
 > then I'm fine with it, other than thinking it might be worth noting th=
at any
 > such extensions must be safe to ignore.
 >
(b)
 > -- My questions about a registry don't depend on the mandatory to unde=
rstand.
 > 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 particu=
lar,
 > this defers making decisions about the documentation policy for extens=
ions
 > (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 di=
dn't
 > expect any extensions--in which case the draft probably shouldn't ment=
ion
 > 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 a=
nd the
 > ADs to decide if they agree with me or not. So it's okay to say "We di=
sagree
 > 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 a=
ny case=20
I've composed a note regarding furture-defined directives being ignored b=
y=20
(legacy) UAs.


For (b)

Alter the spec text to include a reference of the required IANA Policy fo=
r any=20
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 declar=
e for=20
FOO in the above text.

Since HSTS is a security policy, I lean towards wanting to have relativel=
y=20
rigorous review applied to any registry and its contents created for HSTS=
=20
directives and thus am thinking a policy of "IETF Review" is what we ough=
t to=20
state here.

thoughts?

[1] https://www.ietf.org/proceedings/84/minutes/minutes-84-websec

---
end