From d2e60197f3f1b70a5c11c875da2c826736bded51 Mon Sep 17 00:00:00 2001 From: Eric Rescorla Date: Sun, 24 Nov 2024 15:13:51 -0800 Subject: [PATCH] Update the key rotation text. Fixes #629 (#635) * Update the key rotation text. Fixes #629 * Update draft-ietf-tls-esni.md Co-authored-by: Martin Thomson --------- Co-authored-by: Martin Thomson --- draft-ietf-tls-esni.md | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/draft-ietf-tls-esni.md b/draft-ietf-tls-esni.md index e53a8c50..0058c984 100644 --- a/draft-ietf-tls-esni.md +++ b/draft-ietf-tls-esni.md @@ -1371,13 +1371,15 @@ has size k = 1. Client-facing servers SHOULD deploy ECH in such a way so as to maximize the size of the anonymity set where possible. This means client-facing servers should use the same ECHConfig for as many hosts as possible. An attacker can distinguish two hosts that have different ECHConfig values based -on the ECHClientHello.config_id value. This also means public information in a -TLS handshake should be consistent across hosts. For example, if a -client-facing server services many backend origin hosts, only one of which -supports some cipher suite, it may be possible to identify that host based on -the contents of unencrypted handshake message. Similarly, if a backend -origin reuses KeyShare values, then that provides a unique identifier for -that server. +on the ECHClientHello.config_id value. + +This also means public information in a TLS handshake should be +consistent across hosts. For example, if a client-facing server +services many backend origin hosts, only one of which supports some +cipher suite, it may be possible to identify that host based on the +contents of unencrypted handshake message. Similarly, if a backend +origin reuses KeyShare values, then that provides a unique identifier +for that server. Beyond these primary security and privacy goals, ECH also aims to hide, to some extent, the fact that it is being used at all. Specifically, the GREASE ECH @@ -1386,6 +1388,7 @@ the TLS handshake at all. Its goal is to provide "cover" for the real ECH protocol ({{real-ech}}), as a means of addressing the "do not stick out" requirements of {{?RFC8744}}. See {{dont-stick-out}} for details. + ## Unauthenticated and Plaintext DNS {#plaintext-dns} In comparison to {{?I-D.kazuho-protected-sni}}, wherein DNS Resource Records are @@ -1420,6 +1423,13 @@ for extended periods of time, e.g., using per-client ECHConfig structures delivered via HTTPS RRs with high TTLs, challenging. Clients can help mitigate this problem by flushing any DNS or ECHConfig state upon changing networks. +ECHConfig rotation rate is also an issue for non-malicious servers, +which may want to rotate keys frequently to limit exposure if the key +is compromised. Rotating too frequently limits the client anonymity +set. In practice, servers with high load are the best candidates +to be client-facing servers and so anonymity sets will typically +be large even with fairly fast rotation intervals. + ## Ignored Configuration Identifiers and Trial Decryption {#ignored-configs} Ignoring configuration identifiers may be useful in scenarios where clients and @@ -1635,7 +1645,7 @@ out-of-scope for this specification. This design does not provide forward secrecy for the inner ClientHello because the server's ECH key is static. However, the window of exposure is bound by the key lifetime. It is RECOMMENDED that servers -rotate keys frequently. +rotate keys regularly. ### Enable Multi-party Security Contexts