Benjamin Kaduk's Discuss on draft-ietf-httpbis-messaging-16: (with DISCUSS and COMMENT)

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