Skip to content

Commit

Permalink
Add text describing deployment impacts of no SNI access
Browse files Browse the repository at this point in the history
  • Loading branch information
chris-wood committed Oct 10, 2023
1 parent 86c60ec commit 3d33591
Showing 1 changed file with 34 additions and 4 deletions.
38 changes: 34 additions & 4 deletions draft-ietf-tls-esni.md
Original file line number Diff line number Diff line change
Expand Up @@ -98,7 +98,8 @@ list {{?RFC7301}}. Co-located servers with consistent externally visible TLS
configurations, including supported versions and cipher suites, form an
anonymity set. Usage of this mechanism reveals that a client is connecting to a
particular service provider, but does not reveal which server from the
anonymity set terminates the connection.
anonymity set terminates the connection. Deployment implications of this
feature are discussed in {{deployment}}.

ECH is supported in TLS 1.3 {{!RFC8446}}, DTLS 1.3 {{!RFC9147}}, and
newer versions of the TLS and DTLS protocols.
Expand Down Expand Up @@ -1124,7 +1125,19 @@ following string:
In the subsequent ServerHello message, the backend server sends the
accept_confirmation value as described in {{backend-server}}.

# Compatibility Issues
# Deployment Considerations {#deployment}

The design of ECH as specified in this document necessarily requires changes
to client, client-facing server, and backend server. Coordination between
client-facing and backend server requires care, as deployment mistakes
can lead to compatibility issues. These are discussed in {{compat-issues}}.

Beyond coordination difficulties, ECH deployments may also induce challenges
for use cases of information that ECH is designed to encrypt. In particular,
use cases which depend on this unencrypted information may no longer work
as desired. This is elaborated upon in {{no-sni}}.

## Compatibility Issues {#compat-issues}

Unlike most TLS extensions, placing the SNI value in an ECH extension is not
interoperable with existing servers, which expect the value in the existing
Expand All @@ -1138,7 +1151,7 @@ guarantee. Thus this protocol was designed to be robust in case of
inconsistencies between systems that advertise ECH keys and servers, at the cost
of extra round-trips due to a retry. Two specific scenarios are detailed below.

## Misconfiguration and Deployment Concerns {#misconfiguration}
### Misconfiguration and Deployment Concerns {#misconfiguration}

It is possible for ECH advertisements and servers to become inconsistent. This
may occur, for instance, from DNS misconfiguration, caching issues, or an
Expand All @@ -1160,7 +1173,7 @@ ClientHellos, as this allows a network attacker to disclose the contents of this
ClientHello, including the SNI. It MAY attempt to use another server from the
DNS results, if one is provided.

## Middleboxes
### Middleboxes

When connecting through a TLS-terminating proxy that does not support this
extension, {{RFC8446, Section 9.3}} requires the proxy still act as a
Expand All @@ -1175,6 +1188,23 @@ as authoritative for the public name, this may trigger the retry logic described
in {{rejected-ech}} or result in a connection failure. A proxy which is not
authoritative for the public name cannot forge a signal to disable ECH.

## Deployment Impact {#no-sni}

Some use cases which depend on information ECH encrypts may break with the
deployment of ECH. The extent of breakage depends on a number of external
factors, including, for example, whether ECH can be disabled, whether or not
the party disabling ECH is trusted to do so, and whether or not client
implementations will fall back to TLS without ECH in the event of such a
toggle.

Depending on implementation details and deployment settings, use cases
which depend on plaintext TLS information may require fundamentally different
approaches to continue working. For example, in managed enterprise settings,
one approach may be to disable ECH entirely and for client implementations
to honor this request. Another approach may be to intercept and decrypt client
TLS connections. The feasibility of alternative solutions specific to individual
deployments.

# Compliance Requirements {#compliance}

In the absence of an application profile standard specifying otherwise,
Expand Down

0 comments on commit 3d33591

Please sign in to comment.