Re: #340: CR CR LF

Assigning for -19.


On 07/02/2012, at 4:14 PM, Amos Jeffries wrote:

> On 07/02/2012, at 2:18 PM, Mark Nottingham wrote:
>>>> 3.5. Message Parsing Robustness
>>>> 
>>>>> Likewise, although the line terminator for the start-line and header
>>>>> fields is the sequence CRLF, we recommend that recipients recognize a
>>>>> single LF as a line terminator and ignore any CR.
>>>> Does this mean that CR CR CR CR CR CR LF should be interpreted as a single
>>>> LF ? It kinds of scares me on the risk of smuggling attacks. I'd rather
>>>> suggest :
>>>> 
>>>>   ... we recommend that recipients recognize a single LF as a line
>>>>   terminator and ignore the optional preceeding CR. Messages containing
>>>>   a CR not followed by an LF MUST be rejected.
>>> I've created<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/340>.
> On 7/02/2012 5:20 p.m., Mark Nottingham wrote:
>> My .02 - I'm +1 on everything except the last sentence; read literally, it prohibits a CR not followed by a LF *anywhere* in the message, and even if that's fixed, it's too prohibitive (the ABNF already requires CRLF).
>> 
>> That makes it:
>> 
>>>    Likewise, although the line terminator for the start-line and header
>>>    fields is the sequence CRLF, we recommend that recipients recognize a
>>>    single LF as a line terminator and ignore the preceding CR, if present.
>> BTW, I think we're getting to wordsmithing here, does anyone disagree with the general sentiment?
> 
> Yes.
> 
> IME, the series of *CR LF has already been a smuggling risk for years and implementations are already handling it properly (or need vulnerability bugs reported immediately). Prohibiting it from being sent and instructing that it ought to be erased if found in the request/statsu/headers lines should be enough.
> 
> It would be nice to go to straight LF as line delimiter. But that would probably break a lot of things.
> 
> 
> FWIW we accept multiple trailing CR before the LF in Squid but 400 any attempt to use it elsewhere in the first line. Its acceptance in the header area is more complex, being accepted as BWS and in some specific field values where encoding or content may need it.
> 
> AYJ
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 27 February 2012 06:53:19 UTC