From 8404709ba75e8d3fbd09de8a67eb94786094c1ac Mon Sep 17 00:00:00 2001 From: Christopher Wood Date: Mon, 9 Oct 2023 17:40:43 -0400 Subject: [PATCH] Remove alternative designs --- draft-ietf-tls-esni.md | 55 ------------------------------------------ 1 file changed, 55 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index d70b5b6b..726aca16 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -1708,61 +1708,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