Hi Ryan, thanks for the detailed feedback.
Following Julian Reschke's questions, I also had a few questions related
to the draft-02 syntax. I've been basing my understanding on RFC 5234,
which I understand to be the most current/relevant to understanding the
syntax.
First, maxAge and includeSubDomains both include value extension points,
defined as:
maxAge = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ]
includeSubDomains = "includeSubDomains" [ OWS v-ext ]
v-ext = value ; STS extension value
However, the rule for OWS is specified as:
OWS = *( [ CRLF ] WSP )
As written, it would seem that the OWS between either delta-seconds or
"includeSubDomains" can legitimately be omitted before the v-ext. As best
I can tell, this would mean that the following values would still be
valid:
max-age=123.456
includeSubDomainsabc
In the first case ".456" is the v-ext, while in the second, "abc" is. In
both cases, because the OWS is truly optional (valid to have 0
occurrences), only the v-ext is present.
yes, trying to use the OWS construction there is broken as you point out.
<snip/>
To remedy this, I believe some form of explicit delimiter between the
existing values and the v-ext should be defined for the existing headers.
If the intent was to have extension values whitespace separated, then
would the following modification to introduce required whitespace solve
it?
maxAge = "max-age" OWS "=" OWS delta-seconds [ RWS v-ext ]
includeSubDomains = "includeSubDomains" [ RWS v-ext ]
v-ext = value ; STS extension value
OWS = *( [ CRLF ] WSP )
RWS = 1*( [ CRLF ] WSP )
Yes, using a required whitespace (RWS) construction would seem to fix it.
However, since we've migrated to base the ABNF on RFC2616 and not HTTPbis, we
should perhaps whole-hog and use the former's LWS (linear whitespace) construct
which has the "implied whitespace" notion, and get rid of the OWS stuff.
Alternatively, can/should the v-ext be dropped entirely, and extensions to
the STS header be accomplished via defining a new STS-d-ext?
yes, that's a possibility. I put the v-ext thing in there with max-age for
completeness without a good use case, and maybe it'll just cause more trouble
than its worth.
Second, as currently specified, extension directives take the form of:
STS-d = STS-d-cur / STS-d-ext
STS-d-ext = name ; STS extension directive
name = token
token = 1*tchar
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
As currently written, STS-d-ext doesn't seem to be able to contain name
"=" value pairs such as those used by Evans' and Palmer's pinning draft,
because "=" is not a valid token character. Likewise, it wouldn't be able
to contain "#rule" style lists, because comma is not a valid tchar.
good catch.
Should STS-d-ext be defined as "value" instead, so that it contain a wider
range of characters?
offhand, "value" seems the way to go to me.
Again, thanks much for your review, I'm working on getting new rev out with
repaired ABNF amongst other things.
=JeffH
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
