Re: [Technical Errata Reported] RFC9112 (7633)

REJECT 

The difference was intentional. A chunked parser is not a start line or field parser (it is a message body parser) and it is supposed to be less forgiving because it does not have to retain backwards compatibility with 1.0 parsers.

Hence, bare LF around the chunk sizes would be invalid and should result in the connection being marked as invalid.

If an implementation chooses to ignore what is currently defined by the spec and somehow reads less of the content than it would have with CRLF, then it has more problems than this would fix. AFAICT, it’s not possible to turn that into an attack based only on whether the recipient accepts or rejects a chunked message.

In any case, suggestions to further hardening of the chunked parser would have to be defined in that section, not here. 

....Roy


> On Sep 5, 2023, at 6:04 PM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC9112,
> "HTTP/1.1".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7633
> 
> --------------------------------------
> Type: Technical
> Reported by: Amos Jeffries <squid3@treenet.co.nz>
> 
> Section: 2.2
> 
> Original Text
> -------------
>   Although the line terminator for the start-line and fields is the
>   sequence CRLF, a recipient MAY recognize a single LF as a line
>   terminator and ignore any preceding CR.
> 
> Corrected Text
> --------------
>   Although the line terminator for the start-line, fields, chunk
>   and last-chunk is the sequence CRLF, a recipient MAY recognize
>   a single LF as a line terminator and ignore any preceding CR.
> 
> Notes
> -----
> chunked encoding (section 6.3) uses CRLF for line/framing delimiters in the same manner as other HTTP message sections. But these lines are not listed as a possible sites of bare-LF line terminator. Which makes for an unnecessary parser exception and complicates possible request smuggling robustness between implementations.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC9112 (draft-ietf-httpbis-messaging-19)
> --------------------------------------
> Title               : HTTP/1.1
> Publication Date    : June 2022
> Author(s)           : R. Fielding, Ed., M. Nottingham, Ed., J. Reschke, Ed.
> Category            : INTERNET STANDARD
> Source              : HTTP
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
>

Received on Wednesday, 6 September 2023 01:47:45 UTC