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