Script updating gh-pages from b1077b7. [ci skip]

tlswg · Oct 31, 2024 · 3e10c41 · 3e10c41
1 parent 2d3ee6f
commit 3e10c41
Show file tree

Hide file tree

Showing 2 changed files with 17 additions and 17 deletions.
diff --git a/bemasc-k/draft-ietf-tls-svcb-ech.html b/bemasc-k/draft-ietf-tls-svcb-ech.html
@@ -1083,7 +1083,7 @@
 </tr></thead>
 <tfoot><tr>
 <td class="left">Schwartz, et al.</td>
-<td class="center">Expires 3 May 2025</td>
+<td class="center">Expires 4 May 2025</td>
 <td class="right">[Page]</td>
 </tr></tfoot>
 </table>
@@ -1096,12 +1096,12 @@
 <dd class="internet-draft">draft-ietf-tls-svcb-ech-latest</dd>
 <dt class="label-published">Published:</dt>
 <dd class="published">
-<time datetime="2024-10-30" class="published">30 October 2024</time>
+<time datetime="2024-10-31" class="published">31 October 2024</time>
     </dd>
 <dt class="label-intended-status">Intended Status:</dt>
 <dd class="intended-status">Standards Track</dd>
 <dt class="label-expires">Expires:</dt>
-<dd class="expires"><time datetime="2025-05-03">3 May 2025</time></dd>
+<dd class="expires"><time datetime="2025-05-04">4 May 2025</time></dd>
 <dt class="label-authors">Authors:</dt>
 <dd class="authors">
 <div class="author">
@@ -1143,7 +1143,7 @@ <h2 id="name-status-of-this-memo">
         time. It is inappropriate to use Internet-Drafts as reference
         material or to cite them other than as "work in progress."<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
 <p id="section-boilerplate.1-4">
-        This Internet-Draft will expire on 3 May 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
+        This Internet-Draft will expire on 4 May 2025.<a href="#section-boilerplate.1-4" class="pilcrow">¶</a></p>
 </section>
 </div>
 <div id="copyright">
@@ -1445,7 +1445,7 @@ <h2 id="name-security-considerations">
 <a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
       </h2>
 <p id="section-8-1">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 <span class="bcp14">NOT RECOMMENDED</span>. Zone owners who do use such a mixed configuration <span class="bcp14">SHOULD</span> 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.<a href="#section-8-1" class="pilcrow">¶</a></p>
-<p id="section-8-2">When Encrypted ClientHello is deployed, an attacker still has many ways to infer the SNI with reduced confidence. 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. 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.<a href="#section-8-2" class="pilcrow">¶</a></p>
+<p id="section-8-2">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.<a href="#section-8-2" class="pilcrow">¶</a></p>
 <p id="section-8-3">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.<a href="#section-8-3" class="pilcrow">¶</a></p>
 <p id="section-8-4">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 <span>[<a href="#RFC9364" class="cite xref">RFC9364</a>]</span> 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, <span><a href="https://rfc-editor.org/rfc/rfc9460#section-3.1" class="relref">Section 3.1</a> of [<a href="#SVCB" class="cite xref">SVCB</a>]</span> recommends that clients abandon the connection attempt when such an attack is detected.<a href="#section-8-4" class="pilcrow">¶</a></p>
 </section>

diff --git a/bemasc-k/draft-ietf-tls-svcb-ech.txt b/bemasc-k/draft-ietf-tls-svcb-ech.txt
@@ -5,9 +5,9 @@
 TLS Working Group                                            B. Schwartz
 Internet-Draft                                      Meta Platforms, Inc.
 Intended status: Standards Track                               M. Bishop
-Expires: 3 May 2025                                            E. Nygren
+Expires: 4 May 2025                                            E. Nygren
                                                      Akamai Technologies
-                                                         30 October 2024
+                                                         31 October 2024
 
 
    Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
@@ -35,7 +35,7 @@ Status of This Memo
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 3 May 2025.
+   This Internet-Draft will expire on 4 May 2025.
 
 Copyright Notice
 
@@ -289,15 +289,15 @@ 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, an attacker still has many
-   ways to infer the SNI with reduced confidence.  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.  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, 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.
 
    ECH ensures that TLS does not disclose the SNI, but the same
    information is also present in the DNS queries used to resolve the