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

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

On Thu, Jun 17, 2021 at 02:19:36PM +1000, Mark Nottingham wrote:
> 
> > On 17 Jun 2021, at 1:15 pm, Benjamin Kaduk <kaduk@mit.edu> 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.

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.

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

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

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

Received on Saturday, 19 June 2021 01:18:33 UTC