Re: Message delimiting security issues

Line folding now <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/ 
issues/#i77>


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