- From: Benjamin Schwartz <ietf@bemasc.net>
- Date: Tue, 11 Jul 2023 10:43:45 -0400
- To: ietf-http-wg@w3.org
- Message-ID: <CAJF-iTTjW+pCcbwXdO38YmzFetVYBKJ6WF2PhiWHm=RfxnZirg@mail.gmail.com>
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
Received on Tuesday, 11 July 2023 14:44:01 UTC