From 96701ce022c540813fce004f0c8803eabdca57e4 Mon Sep 17 00:00:00 2001 From: EKR Date: Mon, 27 May 2024 11:43:38 -0700 Subject: [PATCH] Explain rules --- draft-ietf-tls-esni.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index 08a44248..c1b9cfb5 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -927,13 +927,20 @@ Clients MAY use information learned from a rejected ECH for future connections to avoid repeatedly connecting to the same server and being forced to retry. However, they MUST handle ECH rejection for those connections as if it were a fresh connection, rather than -enforcing the single retry limit from {{rejected-ech}}. - -Any persisted information MUST be associated with the ECHConfig source used -to bootstrap the connection, such as a DNS SVCB ServiceMode record {{ECH-IN-DNS}}. -Clients MUST limit any sharing of persisted ECH-related state to connections that use -the same ECHConfig source. Otherwise, it might become possible for the client to have -the wrong public name for the server, thus making recovery impossible. +enforcing the single retry limit from {{rejected-ech}}. The reason +for this requirement is that if the server sends a "retry_config" +and then immediately rejects the resulting connection, it is +most likely misconfigured. However, if the server sends a "retry_config" +and then the client tries to use that to connect some time +later, it is possible that the server has been forced to +change its configuration again and is now trying to recover. + +Any persisted information MUST be associated with the ECHConfig source +used to bootstrap the connection, such as a DNS SVCB ServiceMode record +{{ECH-IN-DNS}}. Clients MUST limit any sharing of persisted ECH-related +state to connections that use the same ECHConfig source. Otherwise, it +might become possible for the client to have the wrong public name for +the server, thus making recovery impossible. ECHConfigs learned from ECH rejection can be used as a tracking vector. Clients SHOULD impose the same lifetime and scope restrictions @@ -942,7 +949,6 @@ tracking vectors such as PSKs. In general, the safest way for clients to minimize ECH retries is to comply with any freshness rules (e.g., DNS TTLs) imposed by the -ECHConfig source. This makes it most likely that the client will have up to date information.