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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 16 Jun 2021 18:36:04 -0700

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.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jun 2021 11:53:26 +1000

Hi Ben,

> On 17 Jun 2021, at 11:36 am, Benjamin Kaduk via Datatracker <[email-masked]> wrote:
> 
> reconstructing the target URI

For others' benefit: this is s 3.3.

> from a request-target in absolute-form
> protection that https is supposed to provide.  

Where do you see that behaviour specified?

> (The converse case does

--
Mark Nottingham   https://www.mnot.net/

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 12:13:19 +1000

> > reconstructing the target URI

I think that this question doesn't really read on -messaging, but more on -semantics.  However, I am not seeing any requirement on the server to ensure that the response it generates is secured.

s 4.2.2 of semantics -- https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.uri

> A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time.

No similar requirement is made of the server.  It would be trivial to impose a similar requirement on servers in that same paragraph.

s 4.3.3 of semantics is another place you might look for this: https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.origin

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 12:32:21 +1000

Restoring the CC list (sorry about that).

On Thu, Jun 17, 2021, at 12:13, Martin Thomson wrote:
> I think that this question doesn't really read on -messaging, but more 
> on -semantics.  However, I am not seeing any requirement on the server 
> to ensure that the response it generates is secured.
> 
> s 4.2.2 of semantics -- 
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.uri
> 
> No similar requirement is made of the server.  It would be trivial to 
> impose a similar requirement on servers in that same paragraph.
> 
> s 4.3.3 of semantics is another place you might look for this: 
> https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.origin 
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Jun 2021 20:15:31 -0700

Hi Mark, Martin,

> For others' benefit: this is s 3.3.

Oops, my pre-balloting editing removed the reference to the actual text in
question; thanks for providing the link.

> Where do you see that behaviour specified?

I guess there's two parts, here: "take the scheme from the request-target"
seems to fall pretty clearly from §3.3's "the target URI is the
request-target".  Getting from that to "engage processing for the https
origin" is something more of a leap, and I confess that I was just relying
on the intuition I developed over the couple days I spent enjoying
-semantics earlier in the week and did not go digging for specific
references in -semantics to support that statement.  The origin triple for
a URI derives from the scheme (looking now, that's §4.3.1 of -semantics),
and so my intuition was presumably trying to extend that to how the
namespace is per origin and accordingly the resource representation that
would be returned in response to the request in question.  I don't know if
there are other places in -semantics that give more specifics on how or
whether the target URI affects the origin/namespace that the origin server
uses to service the request.

> > to ensure that the response it generates is secured.

I think that's a good insight that this question exposed something like a
gap in -semantics.

> > > A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests. Note that the definit…

I think at some formal level, adding analogous requirements for the server
to only send secured responses on https resources would close off the
harmful edge case I had in mind when balloting.  It seems like adding such
a requirement would be a good idea, at least given the little thought I've
put in so far.

My initial unease as I was reading -messaging stems roughly from a sense
that it describes a scenario where the server is acting on "untrusted
input" in a mode with "elevated privilege" (stretching the terminology,
obviously), brought about by a potential mismatch between the in-band
protocol element and the request's context.  Looking a bit more closely
into the analogous parts of h3 is assauging that concern to a large extent,
though, as h3 is explicitly not restricted to URIs with scheme http/https.
That makes me feel more confident that the abstract model of an HTTP server
needs to be paying significant attention to the scheme vs just replying on
whatever transport the request came in on.

> > https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#https.origin 

Looking quickly, it seems that the discussion of server behavior mostly
presumes that the server is acting in an https role, since the origin and
its namespace are identified by the request target's host and port value.

Do you think anything would go in §7.4 of -semantics?  For reference, it
currently has:

> Before performing a request, a server decides whether or not to provide
> service for the target URI via the connection in which the request is
> received. For example, a request might have been misdirected,
> deliberately or accidentally, such that the information within a received
> Host header field differs from the connection's host or port.

It doesn't seem like much of a stretch to add "or have been sent over a
connection with attributes that are incompatible with the requirements of
the requested scheme".

Thanks,

Ben

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jun 2021 14:19:36 +1000

> On 17 Jun 2021, at 1:15 pm, Benjamin Kaduk <[email-masked]> wrote:
> 

There *should* be as clear and consistent difference between the request-target (the on-the-wire component in HTTP/1.1) and the target uri / target resource, which is the version-independent concept in semantics. All of the requirements for things like this should be pointed at target [uri, resource], not the request-target.

If that's not the case somewhere, or we could make that more clear, a pointer or a suggestion would be welcome.

> impose a similar requirement on servers in that same paragraph.

I don't think that helps, at least in the case of HTTP/1.1. There, the server is responsible for setting the correct scheme for the target URI when a request is received; the security properties of the request and response follow from that. Effectively, it's not under attacker control.

However, I don't see any equivalent mechanism regarding :scheme in http/2 bis  or http/3. Off the cuff, I tend to think that security considerations about this probably belong on both of those specs.

Cheers,

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 17 Jun 2021 14:40:17 +1000

> > to ensure that the response it generates is secured.
...
> I don't think that helps, at least in the case of HTTP/1.1. There, the 
> server is responsible for setting the correct scheme for the target URI 
> when a request is received; the security properties of the request and 
> response follow from that. Effectively, it's not under attacker control.

That only establishes that it is not an attack, which might mean that the requirement is not strictly necessary.  Adding a requirement might still be useful.

> However, I don't see any equivalent mechanism regarding :scheme in 
> http/2 bis  or http/3. Off the cuff, I tend to think that security 
> considerations about this probably belong on both of those specs.

I disagree.  This is a generic requirement: if the scheme is "https", the server needs to ensure that the response has appropriate integrity and confidentiality protections.  I think that is all that Ben's question suggests we do.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Jun 2021 16:18:50 +1000

> On 17 Jun 2021, at 2:40 pm, Martin Thomson <[email-masked]> wrote:
> 

I'm not *against* a requirement here, but...

> I disagree.  This is a generic requirement: if the scheme is "https", the server needs to ensure that the response has appropriate integrity and confidentiality protections.  I think that is all th…

The point is that the core construct in Semantics is the target URI, and each protocol version should clearly define how to derive one for a given request on the wire, warning of the pitfalls that one might encounter in doing so -- in this case, assuming that :scheme is truthful. I'll open an issue on h2bis and we can move the discussion there.

Cheers,

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 Jun 2021 18:17:54 -0700

Hi Mark,

I suspect that I have missed the point you were trying to make, so my
apologies if the following comes across as confused...

> If that's not the case somewhere, or we could make that more clear, a pointer or a suggestion would be welcome.

AFAIK this distinction is properly made everywhere.  My complaint was
attempting to focus specifically on the procedure for converting the
request-target to the target URI, since in this one specific case of the
absolute-form request target the procedure is that "the target URI is
defined to have the same value as the request-target" and there seem to be
some edge cases relating to the scheme selection.

At a high level, my point is that if a client sends a request with
request-target of https://www.example.com over TCP-without-TLS, I expect
the client to get back an HTTP 4xx response over that TCP channel, or maybe
just a TCP RST.  In particular, I do not expect it to get a non-4xx
response, and definitely not 200 with content from the "https" origin.
There are actually quite a few places in the flow of processing the message
where this could be done, across both -messaging and -semantics, but I
don't remember a specific place that gives a clear direction to the server
implementation to handle this scenario.

> I don't think that helps, at least in the case of HTTP/1.1. There, the server is responsible for setting the correct scheme for the target URI when a request is received; the security properties of…

(This is the part where I'm most confused.)
Where is the requirement specified that the server set the correct scheme
for the target URI?  If the procedure to set the taret URI is "use the
scheme the client gave you", that seems like it's clearly under attacker
control, so I don't understand how you reached the conclusion in the final
sentence.  Were you maybe talking about h2 at that point and not HTTP/1.1?

> However, I don't see any equivalent mechanism regarding :scheme in http/2 bis  or http/3. Off the cuff, I tend to think that security considerations about this probably belong on both of those spec…

That makes sense to me, as does spinning it off to a separate issue for
h2-bis.  I will note that I didn't raise a concern for h3 and :scheme
processing since h3 always requires secure transport and the failure
case didn't seem very significant.

Thanks,

Ben