- From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
- Date: Wed, 16 Jun 2021 18:36:04 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-messaging@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com
Benjamin Kaduk has entered the following ballot position for draft-ietf-httpbis-messaging-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-messaging/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server. I'm specifically concerned about taking the scheme directly from the request target, i.e., making the distinction between the "http" and "https" schemes. The simple procedure of "take the scheme from the request-target" would seem to allow for the client to cause the server to engage processing for the "https" origin without receiving the protection that https is supposed to provide. (The converse case does not immediately seem to present much risk but is probably worth preventing as well on general principles of retaining consistency.) I don't remember seeing any text that would require the server to validate the scheme from the request-target against the actual properties of the transport (or the configured fixed URI scheme as might be provisioned with a trusted outbound gateway, etc.) While we do reference ยง7.4 of [Semantics] with a note that reconstructing the target URI is only part of the process of identifying a target resource, that part of [Semantics] does not mention scheme validation as part of rejecting misdirected requests. Does the origin server need to validate the scheme from an absolute-form request-target? What is the scope of consequences if it fails to do so? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for another extremely well written document! The only general comment I have is that [Semantics] did such a good job of portraying the trailer section as a generic concept that I was surprised to see it presented as specific to the chunked transfer-encoding in this document. It seems to me (naively, of course), that when the content can accurately be delimited, whether by Content-Length or the chunked transfer-encoding, a trailer section could be read after the request or response and clearly distinguished from the start of a new request or response. I recognize that we have a significant deployed base to be mindful of backwards compatibility with, and so do not propose to recklessly add trailer sections everywhere. It might be worth some more prominent acknowledgment that in HTTP/1.1 the trailers section is limited to the chunked transfer-encoding, and discussion of why trailers are not usable in other HTTP/1.1 scenarios, though. I did make a github PR with a handful of editorial suggestions, at https://github.com/httpwg/http-core/pull/872 . 2.2 The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field line or processing the line after it as a new request, either of which might result in a security vulnerability if other implementations within the request chain interpret the same message differently. [...] Given the previous procedure that gives as a permitted behavior to "consume the line without further processing", it seems like an attempt to get the server to ignore the field line would have succeeded if this procedure is followed? I suppose the important difference is that the field line is completely suppressed from any version of the message transmitted downstream, thus avoiding the opportunity for a different interpretation. Regardless, though, it seems like the text of the guidance as written (not quoted above) reads like it is setting us up for vulnerabilities in the presence of non-compliant (or HTTP/1.0?) implementations in the request chain. We might want to put in a bit more explanation of how the stated procedure avoids the vulnerability. Section 3.2 Recipients of an invalid request-line SHOULD respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded. [...] (I assume 301 rather than 308 was an intentional choice for maximum compatibility with old/broken clients.) Section 3.3 Supplying a default name for authority within the context of a secured connection is inherently unsafe if there is any chance that the user agent's intended authority might differ from the selected default. A server that can uniquely identify an authority from the request context MAY use that identity as a default without this risk. Is the contents of the TLS SNI extension sufficient request context to uniquely identify an intended authority? Section 5.1 The field line value does not include any leading or trailing whitespace: OWS occurring before the first non-whitespace octet of the field line value or after the last non-whitespace octet of the field line value ought to be excluded by parsers when extracting the field line value from a field line. I have in general tried to refrain from commenting on the extensive use of the phrase "ought to" in this group of documents, but this particular scenario seems like a strong candidate for a BCP 14 keyword. Section 9.8 TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] This is written as if it's imposing normative requirements on generic TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all the message data that it cares about. ...whereas this SHOULD does not have an obvious analogue in RFC 8446, and thus it would make sense to retain the BCP 14 keyword for. NITS Section 4 The rest of the response message is to be interpreted in light of the semantics defined for that status code. See Section 15 of [Semantics] for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, In some sense it seems that the referenced status codes are defined by [Semantics], not "this specification". I was initially going to propose (in my PR) a change to "defined for", but that seems incorrect and I don't have a better proposal handy. Section 5.2 A sender MUST NOT generate a message that includes line folding (i.e., that has any field line value that contains a match to the obs-fold rule) unless [...] Since we don't include the obs-fold production as a component of any other production, and field-value excludes CRLF, it seems that any such field line value would already be in violation of the ABNF and thus forbidden. I don't really want to advocate for including obs-fold in the field-value production in -semantics, though, so maybe accepting this nit is the least bad choice here. Section 9.2 A client that has more than one outstanding request on a connection MUST maintain a list of outstanding requests in the order sent and MUST associate each received response message on that connection to the highest ordered request that has not yet received a final (non- 1xx) response. "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking.
Received on Thursday, 17 June 2021 01:36:25 UTC