From ed55fd435735751026d8bb7dcc58d057f7c32f68 Mon Sep 17 00:00:00 2001
From: ID Bot <idbot@example.com>
Date: Sun, 19 Jan 2025 00:26:17 +0000
Subject: [PATCH] Script updating archive at 2025-01-19T00:26:17Z. [ci skip]

---
 archive.json | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/archive.json b/archive.json
index 13f710b..2ceb51c 100644
--- a/archive.json
+++ b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2025-01-16T00:24:16.460182+00:00",
+  "timestamp": "2025-01-19T00:26:12.898757+00:00",
   "repo": "tfpauly/draft-happy-eyeballs-v3",
   "labels": [
     {
@@ -1167,6 +1167,22 @@
       "updatedAt": "2025-01-06T17:15:33Z",
       "closedAt": null,
       "comments": []
+    },
+    {
+      "number": 71,
+      "id": "I_kwDOKH7CuM6mpPpQ",
+      "title": "ECH guidance conflicts with ECH-SVCB",
+      "url": "https://github.com/tfpauly/draft-happy-eyeballs-v3/issues/71",
+      "state": "OPEN",
+      "author": "bemasc",
+      "authorAssociation": "NONE",
+      "assignees": [],
+      "labels": [],
+      "body": "The current draft says\n\n> If the client supports TLS Encrypted Client Hello (ECH) discovery through SVCB records {{!SVCB-ECH=I-D.ietf-tls-svcb-ech}}, depending on the client's preference to handle ECH, the client SHOULD sort addresses with ECH keys taking priority to maintain privacy when attempting connection establishment.\n\nECH-SVCB says\n\n> A SVCB RRSet containing some RRs with \"ech\" and some without is vulnerable to a downgrade attack ... 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.\n\nIn essence, there is a discrepancy as to whose responsibility it is to prioritize ECH.\n\nI think the ECH-SVCB view should probably prevail.\n\nPhilosophically, the client cannot make the service more secure than the operator intends it to be.\n\nOperationally, it seems valuable to be able to test ECH by placing it on a less-used, lower-priority endpoint, and it would be very surprising to discover that this effectively inverts the stated priority for some (large?) segment of clients.",
+      "createdAt": "2025-01-17T16:14:21Z",
+      "updatedAt": "2025-01-17T16:14:21Z",
+      "closedAt": null,
+      "comments": []
     }
   ],
   "pulls": [