Re: #340: CR CR LF

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

Received on Tuesday, 7 February 2012 05:17:31 UTC