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

[Mark Nottingham <[e-mail]>]

> On 17 Jun 2021, at 1:15 pm, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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.

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.

Martin commented:

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

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,

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