Re: Message delimiting security issues

On Wednesday 17 January 2007 19:45, Henrik Nordstrom wrote:
> In this specific case I am leaning more towards that there was an
> oversight in the wording of 4.2, forgetting to mention that LWS is not
> allowed between the header name and the delimiter. The reasoning being
>
> a) It's not allowed by MIME, which the HTTP header syntax is supposed to
> build upon.
It is not only supposed to build upon, but the spec explicitly
refers to it (4.2: "HTTP header fields [...] follow the same generic
format as that given in Section 3.1 of RFC 822 [9]").
If HTTP was intended to differ from RFC 822 with respect to
this, I would expect the sentence to read "HTTP header fields [...] follow
a similar format as that given [...]"

> b) Clearly not expected to most readers.
Not expected at all. Making the already awkward LWS-situation
of RFC 822 even worse by allowing it nearly everywhere deliberately,
while trying to straighten out the CRLF-lunacy of RFC 822 partially
(for the payload) really is an unforeseeable (unbelievable) pitfall.
I guess nobody would expect to encounter something like
"Host        :       foo.com      :            80"
even though the spec "allows for it", strictly speaking,
according to the implied *LWS rule.

> c) And nearly all implementations gets this wrong one way or another.
>
> As it's very doubtful there is any implementations relying on this being
> allowed today, and the security implications of implementations not
> properly ignoring the LWS the question is if 4.2 should be strengthened
> disallowing LWS between the header name and the separator (also in line
> with MIME header syntax), or if the current messy situation should be
> kept relying on each implementer to figure out the implications of
> implied *LWS..
The phrase "current messy situation" gets to the point.
I would consider the "augmentation" of "implied *LWS" rather
a degradation for the following reasons:

a) any "implied" rule in a spec makes it harder to read
and more error-prone (Travis: "I'm used to BNF explicitly specifying exactly
what can and cannot happen, and not making implicit back-references")
b) implied LWS is superfluous -- nobody needs it and nobody wants
it because
c) any superfluous LWS squanders bandwidth
d) having to expect LWS nearly anywhere is a nuisance
for parsers (at least for those that go for speed)

I would not try to strengthen some minituae while pertaining
to the sentences that really impose problems reading, interpreting
and implementing the whole spec.

Even if LWS is considered a "feature" of the spec (which it is not imho)
the spec should explicitly state where it is allowed, like RFC 822 does.

Kind regards
Ingo Struck

Received on Thursday, 18 January 2007 10:52:33 UTC