Re: New draft: Reverse HTTP Transport

Hiya,

On Tue, Jul 11, 2023 at 3:47 PM Benjamin Schwartz <ietf@bemasc.net> wrote:

> Hi HTTPBIS,
>
> TIru Reddy and I have a fun new -00 today for your amusement: Reverse HTTP
> Transport (
> https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-00.html).
>
> Abstract:
>    This document defines a secure transport for HTTP in which the client
>    and server roles are reversed.  This arrangement improves the origin
>    server's protection from Layer 3 and Layer 4 DDoS attacks when an
>    intermediary is in use.  It allows origin server's to be hosted
>    without being publicly accessible but allows the clients to access
>    these servers via an intermediary.
>
> Although the mechanism described here is generic, the main expected use
> case is related to MASQUE, OHAI, and Oblivious DoH.  The essence of the
> proposal is straightforward, but there are definitely some things for us to
> talk about in the details:
>
> * Transport proxies like CONNECT-UDP are handled by having the origin run
> its own proxy endpoint for access to itself.
>   - "CONNECT-TCP" is not used (even though I think it's great), because
> the target is only identified by an Origin, not a URI Template.
> * The TLS server (i.e. HTTP client) speaks first, at 1.5 RTT on the
> half-open TLS connection.
> * Ownership of transport endpoints and IP addresses is inferred from
> ownership of matching HTTP origins.
> * There are some real open questions about what to do about DNS
> verification and stolen key attacks.
>
> Please send us your thoughts!
>

This is generally interesting so thanks for sharing. There are a lot of
open questions, aside from the ones you others highlighted, the big one for
me is that more definition is required to make the Reverse HTTP/3 design
actually realizable. The doc states "operating with the roles reversed but
otherwise unmodified" but I don't think this actually works that way. QUIC
places more restrictions on what client or server roles can and can't do.
For example, a QUIC server can open server streams. HTTP/3 doesn't allow
request message sequences to be sent on QUIC bidirectional server streams,
so an HTTP/3 implementation would need to support a different mapping
definition to make this work in practice.

Cheers,
Lucas