New draft: Reverse HTTP Transport


TIru Reddy and I have a fun new -00 today for your amusement: Reverse HTTP
Transport (

   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!

--Ben Schwartz

Received on Tuesday, 11 July 2023 14:44:01 UTC