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. For maxAge in particular, this
can lead to very silly parsing interpretations. Considering the following
value:
max-age=123
If I'm not mistaken, ABNF doesn't specify any sort of greedy matching, so
this could be interpreted as:
delta-seconds = 1 (1DIGIT), v-ext = 23 (0OWS 2tchar)
delta-seconds = 12 (2DIGIT), v-ext = 3 (0OWS 1tchar)
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 )
Alternatively, can/should the v-ext be dropped entirely, and extensions to
the STS header be accomplished via defining a new STS-d-ext?
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.
Should STS-d-ext be defined as "value" instead, so that it contain a wider
range of characters? Alternatively, if the intent for STS-d-ext was that
it would always include some name, should it be defined as "name [ OWS "="
OWS value ]"?
Either way seems to offer a solution. It seems that if a parser were
written based on the current draft, it would be correct/valid to reject an
STS header that included cert pins, as specified in the current pinning
draft. This would be because the cert pinning draft makes use of "="
within the extension definitions, which is not a legal character for an
STS-d-ext in the base spec.
Best regards,
Ryan
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
