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

Hi Mark, Martin,

On Thu, Jun 17, 2021 at 11:53:26AM +1000, Mark Nottingham wrote:
> Hi Ben,
> 
> 
> > On 17 Jun 2021, at 11:36 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > 
> > Let's discuss whether the currently specified procedures for
> > reconstructing the target URI
> 
> 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.

> > 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.  
> 
> 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.

> > (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?

On Thu, Jun 17, 2021 at 12:32:21PM +1000, Martin Thomson wrote:
> Restoring the CC list (sorry about that).
> 
> On Thu, Jun 17, 2021, at 12:13, Martin Thomson wrote:
> > On Thu, Jun 17, 2021, at 11:53, Mark Nottingham wrote:
> > > > On 17 Jun 2021, at 11:36 am, Benjamin Kaduk via Datatracker <noreply@ietf.org> wrote:
> > > > Let's discuss whether the currently specified procedures for
> > > > 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.

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

> > 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.

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.

> > 
> > 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 

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

Received on Thursday, 17 June 2021 03:16:04 UTC