* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #282 (closed design: fixed)

Opened 4 years ago

Last modified 3 years ago

Recommend minimum sizes for protocol elements

Reported by: mnot@pobox.com Owned by: julian.reschke@gmx.de
Priority: normal Milestone: 15
Component: non-specific Severity: Active WG Document
Keywords: Cc:
Origin:

Description

Much as we did for URLs, we should consider recommending minimum sizes for protocol elements when they're handled; e.g.,

  • method names
  • status phrases
  • header blocks
  • header lines
  • header field-names
  • chunk sizes
  • message bodies

I'm not sure if we need to go into recommendations for the various field-value types, but it's worth a look.

This should include error handling; i.e. what to do when you receive a [protocol element] that's too big, both as a server and a client.

The same sort of careful language that we used around URLs should be used here too; i.e., that there is no maximum, just a recommended minimum size that needs to be handled by implementations.

Attachments

282.diff (6.2 KB) - added by julian.reschke@gmx.de 3 years ago.
proposed patch for p1 and p6

Change History

comment:1 Changed 3 years ago by mnot@pobox.com

Proposal for headers:

Insert at end of p1 3.2:

HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server MUST be prepared to receive request headers of unbounded length and respond with the 413 (Request Entity Too Large) status code if the received header(s) would be longer than the server wishes to handle (see Section 8.4.14 of [Part2]).

A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.

Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined headers have 20,000 or more octets.

comment:2 Changed 3 years ago by mnot@pobox.com

Proposal covering other situations:

Add section to Security Considerations:

11.5 Protocol Element Size Overflows

Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform a Denial of Service against implementations that accept fields with unlimited lengths.

To promote interoperability, this specification makes specific recommendations for size limits on request-targets [ref] and blocks of header fields [ref]. These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.

This specification also provides a way for servers to reject messages that have request-targets that are too long [ref] or request entities that are too large [ref].

Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) SHOULD be limited by implementations carefully, so as to not impede interoperability.

comment:4 Changed 3 years ago by mnot@pobox.com

Proposal: move the definition of delta-seconds from Age to a new subsection of p6 1.4 Syntax Notation:

1.4.x Delta Seconds

The delta-seconds rule specifies a non-negative integer, representing time in seconds.

delta-seconds = 1*DIGIT

If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, it MUST consider the value to be 2147483648 (231). Recipients parsing a delta-seconds value SHOULD use an arithmetic type of at least 31 bits of range, and senders MUST NOT send delta-seconds with a value greater than 2147483648.

comment:5 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 15

Combined, revised proposal:

Revised proposal:

For HTTP headers, insert at end of p1 3.2:

""" HTTP does not place a pre-defined limit on the length of header fields, either in isolation or as a set. A server MUST be prepared to receive request headers of unbounded length and respond with the 413 (Request Entity Too Large) status code if the received header(s) would be longer than the server wishes to handle (see Section 8.4.14 of [Part2]).

A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.

Various ad-hoc limitations on header length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support messages whose combined header block (i.e., from the start of the request-line or response-line until the CRLF CLRF that terminates the headers) have 4,000 or more octets. """

For max-age and other cache-control directives, move the definition of delta-seconds from Age to a new subsection of p6 1.4 Syntax Notation:

""" 1.4.x Delta Seconds

The delta-seconds rule specifies a non-negative integer, representing time in seconds.

delta-seconds = 1*DIGIT

If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, it MUST consider the value to be 2147483648 (231). Recipients parsing a delta-seconds value SHOULD use an arithmetic type of at least 31 bits of range, and senders MUST NOT send delta-seconds with a value greater than 2147483648. """

For other situations, add section to p1 Security Considerations:

""" 11.5 Protocol Element Size Overflows

Because HTTP uses mostly textual, character-delimited fields, attackers can overflow buffers in implementations, and/or perform a Denial of Service against implementations that accept fields with unlimited lengths.

To promote interoperability, this specification makes specific recommendations for size limits on request-targets [ref] and blocks of header fields [ref]. These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.

This specification also provides a way for servers to reject messages that have request-targets that are too long [ref] or request entities that are too large [ref].

Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) SHOULD be limited by implementations carefully, so as to not impede interoperability. """

comment:6 Changed 3 years ago by julian.reschke@gmx.de

  • Owner set to julian.reschke@gmx.de
  • Status changed from new to assigned

Changed 3 years ago by julian.reschke@gmx.de

proposed patch for p1 and p6

comment:7 Changed 3 years ago by julian.reschke@gmx.de

From [1323]:

add guidance on minimum sizes of protocol elements (see #282)

comment:8 Changed 3 years ago by julian.reschke@gmx.de

  • Status changed from assigned to closed
  • Resolution set to incorporated

comment:9 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:10 Changed 3 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.