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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
