Re: New draft: Reverse HTTP Transport

I mentioned an approach like this as an alternative to resumable uploads. Problem remains substrate -- this is so simple on a SCTP stack compared to a QUIC stack, but oh well.



-Eric







---- On Tue, 11 Jul 2023 07:43:45 -0700 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!



--Ben Schwartz