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

On Jun 16, 2021, at 8:15 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> 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 <mailto: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 <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 <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

This discussion went off in the weeds and started talking about absolute URIs
and changes to basic proxy functionality. None of that is necessary.

The above recognition that there is a missing/implied requirement (that origin
servers obey their own identifier requirements) is a good one, and I agree that
the right fix is to add a specific requirement to that section 7.4 of Semantics
which matches the existing (passive) requirements on the identifier scheme.
Note that this doesn't change the protocol at all -- it reinforces the existing
requirements on https.

We are working on the text now in 

   https://github.com/httpwg/http-core/pull/898

Cheers,

....Roy