Merge pull request #558 from tlswg/caw/remove-alts

Remove alternative designs

draft-ietf-tls-esni.md

@@ -1763,61 +1763,6 @@ true ClientHello used upon ECH negotiation.
 
 --- back
 
-
-# Alternative SNI Protection Designs
-
-Alternative approaches to encrypted SNI may be implemented at the TLS or
-application layer. In this section we describe several alternatives and discuss
-drawbacks in comparison to the design in this document.
-
-## TLS-layer
-
-### TLS in Early Data
-
-In this variant, TLS Client Hellos are tunneled within early data payloads
-belonging to outer TLS connections established with the client-facing server.
-This requires clients to have established a previous session -— and obtained
-PSKs —- with the server. The client-facing server decrypts early data payloads
-to uncover Client Hellos destined for the backend server, and forwards them
-onwards as necessary. Afterwards, all records to and from backend servers are
-forwarded by the client-facing server -- unmodified. This avoids double
-encryption of TLS records.
-
-Problems with this approach are: (1) servers may not always be able to
-distinguish inner Client Hellos from legitimate application data, (2) nested
-0-RTT data may not function correctly, (3) 0-RTT data may not be supported --
-especially under DoS -- leading to availability concerns, and (4) clients must
-bootstrap tunnels (sessions), costing an additional round trip and potentially
-revealing the SNI during the initial connection. In contrast, encrypted SNI
-protects the SNI in a distinct Client Hello extension and neither abuses early
-data nor requires a bootstrapping connection.
-
-### Combined Tickets
-
-In this variant, client-facing and backend servers coordinate to produce
-"combined tickets" that are consumable by both. Clients offer combined tickets
-to client-facing servers. The latter parse them to determine the correct backend
-server to which the Client Hello should be forwarded. This approach is
-problematic due to non-trivial coordination between client-facing and backend
-servers for ticket construction and consumption. Moreover, it requires a
-bootstrapping step similar to that of the previous variant. In contrast,
-encrypted SNI requires no such coordination.
-
-## Application-layer
-
-### HTTP/2 CERTIFICATE Frames
-
-In this variant, clients request secondary certificates with CERTIFICATE_REQUEST
-HTTP/2 frames after TLS connection completion. In response, servers supply
-certificates via TLS exported authenticators
-{{?EXPORTED-AUTHENTICATORS=RFC9261}} in CERTIFICATE frames. Clients use a
-generic SNI for the underlying client-facing server TLS connection. Problems
-with this approach include: (1) one additional round trip before peer
-authentication, (2) non-trivial application-layer dependencies and interaction,
-and (3) obtaining the generic SNI to bootstrap the connection. In contrast,
-encrypted SNI induces no additional round trip and operates below the
-application layer.
-
 # Linear-time Outer Extension Processing {#linear-outer-extensions}
 
 The following procedure processes the "ech_outer_extensions" extension (see