W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2007

Re: Message delimiting security issues

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 19 Jan 2007 12:34:51 -0800
Message-Id: <FE432A44-FFA5-413F-95F3-8F59890529B1@gbiv.com>
Cc: <ietf-http-wg@w3.org>
To: <LMM@acm.org>

On Jan 19, 2007, at 11:05 AM, Larry Masinter wrote:

> In my opinion:
>
> * The current spec is ambiguous, and needs clarification

The current spec needs a complete rewrite.  Besides that, the entire
ABNF has to be rewritten in order for it to meet current IETF reqs.
I suspect that will cause a lot of implied LWS to disappear.

> * Although, in general, it is not appropriate to 'tighten'
>   a specs requirements, in some cases (and in this case)
>   it is the right choice:
>
>   There are few clients that send LWS between header
>   name and :.
>
>   There are already many servers that reject such
>   requests.

I think the spec should reflect the standard, not be artificially
restricted by adherence to past revisions of itself.  By standard,
I mean the measure expected by all of the implementations that are
exchanging legitimate communication via HTTP.  AFAIK, there are no
servers or clients that send legitimate messages with anything
other than

    Field-name: field-value

so it is time for the spec to reflect that fact.  My only caveat is
that there should be an exception for the message/http media type,
such that messages received via SMTP shall allow line folding.

> So, in my opinion, we should change the spec that
> clients MUST NOT send LWS in headers before the :,
> and that servers MUST reject any such message as
> malformed.
>
> This may make a few servers that were previously
> compliant non-compliant, but in general it will
> improve interoperability and security.

No, I will not accept that.  MUST NOT send such LWS is fine,
including when a message is forwarded, but forbidding a server from
processing such a message is not going to happen because it would
make all implementations non-compliant.

Servers should be configurable in regards to robust or restricted
parsing behavior, and nothing we say can improve the "security"
of broken software that was deployed years ago.  Software that
correctly parses according to the RFC is not subject to those
perceived security issues.

....Roy
Received on Friday, 19 January 2007 20:34:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:00 GMT