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

Re: Message delimiting security issues

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 20 Aug 2007 13:38:58 +1000
Message-Id: <D21F5CF0-5019-4D35-85D7-0613113D97D7@mnot.net>
Cc: <LMM@acm.org>, <ietf-http-wg@w3.org>
To: Roy T. Fielding <fielding@gbiv.com>

Line folding now <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/ 

On 20/01/2007, at 7:34 AM, Roy T. Fielding wrote:

> 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

Mark Nottingham     http://www.mnot.net/
Received on Monday, 20 August 2007 03:39:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC