From 26fd2b697df797eaf8a65586021a5de68e212f6c Mon Sep 17 00:00:00 2001 From: ID Bot Date: Thu, 31 Oct 2024 13:35:12 +0000 Subject: [PATCH] Script updating gh-pages from 6f29b0d. [ci skip] --- bemasc-k/draft-ietf-tls-svcb-ech.html | 2 +- bemasc-k/draft-ietf-tls-svcb-ech.txt | 19 ++++++++++--------- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/bemasc-k/draft-ietf-tls-svcb-ech.html b/bemasc-k/draft-ietf-tls-svcb-ech.html index ab8dee3..3a420c9 100644 --- a/bemasc-k/draft-ietf-tls-svcb-ech.html +++ b/bemasc-k/draft-ietf-tls-svcb-ech.html @@ -1445,7 +1445,7 @@

8. Security Considerations

A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: a network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint. This configuration is NOT RECOMMENDED. Zone owners who do use such a mixed configuration SHOULD mark the RRs with "ech" as more preferred (i.e. lower SvcPriority value) than those without, in order to maximize the likelihood that ECH will be used in the absence of an active adversary.

-

When Encrypted ClientHello is deployed, there are many ways that an attacker might infer the SNI. Even in an idealized deployment, ECH's protection is limited to an anonymity set consisting of all the ECH-enabled server domains supported by a given client-facing server that share an ECH configuration. An attacker who can enumerate this set can always guess the encrypted SNI with probability at least 1/K, where K is the number of domains in the set. Some attackers may achieve much greater accuracy using traffic analysis, popularity weighting, and other mechanisms.

+

When Encrypted ClientHello is deployed, the inner TLS SNI is protected from disclosure to attackers. However, there are still many ways that an attacker might infer the SNI. Even in an idealized deployment, ECH's protection is limited to an anonymity set consisting of all the ECH-enabled server domains supported by a given client-facing server that share an ECH configuration. An attacker who can enumerate this set can always guess the encrypted SNI with probability at least 1/K, where K is the number of domains in the set. Some attackers may achieve much greater accuracy using traffic analysis, popularity weighting, and other mechanisms.

ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the server's hostname. This specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encryption, an attacker on this path can also learn the destination server name. A similar attack applies if the client can be linked to a request from the resolver to a DNS authority.

An attacker who can prevent SVCB resolution can deny clients any associated security benefits. A hostile recursive resolver can always deny service to SVCB queries, but network intermediaries can often prevent resolution as well, even when the client and recursive resolver validate DNSSEC [RFC9364] and use a secure transport. These downgrade attacks can prevent a client from being aware that "ech" is configured which could result in the client sending the ClientHello in cleartext. To prevent downgrades, Section 3.1 of [SVCB] recommends that clients abandon the connection attempt when such an attack is detected.

diff --git a/bemasc-k/draft-ietf-tls-svcb-ech.txt b/bemasc-k/draft-ietf-tls-svcb-ech.txt index 3a8055a..f29a895 100644 --- a/bemasc-k/draft-ietf-tls-svcb-ech.txt +++ b/bemasc-k/draft-ietf-tls-svcb-ech.txt @@ -289,15 +289,16 @@ Figure 1: ECH SvcParam with a public_name of "ech-sites.example.net". likelihood that ECH will be used in the absence of an active adversary. - When Encrypted ClientHello is deployed, there are many ways that an - attacker might infer the SNI. Even in an idealized deployment, ECH's - protection is limited to an anonymity set consisting of all the ECH- - enabled server domains supported by a given client-facing server that - share an ECH configuration. An attacker who can enumerate this set - can always guess the encrypted SNI with probability at least 1/K, - where K is the number of domains in the set. Some attackers may - achieve much greater accuracy using traffic analysis, popularity - weighting, and other mechanisms. + When Encrypted ClientHello is deployed, the inner TLS SNI is + protected from disclosure to attackers. However, there are still + many ways that an attacker might infer the SNI. Even in an idealized + deployment, ECH's protection is limited to an anonymity set + consisting of all the ECH-enabled server domains supported by a given + client-facing server that share an ECH configuration. An attacker + who can enumerate this set can always guess the encrypted SNI with + probability at least 1/K, where K is the number of domains in the + set. Some attackers may achieve much greater accuracy using traffic + analysis, popularity weighting, and other mechanisms. ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the