Script updating archive at 2024-12-03T01:39:39Z. [ci skip]

tlswg · Dec 3, 2024 · 4db0da0 · 4db0da0
1 parent 6a28d08
commit 4db0da0
Showing 1 changed file with 50 additions and 3 deletions.
diff --git a/archive.json b/archive.json
@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2024-12-01T01:50:43.865887+00:00",
+  "timestamp": "2024-12-03T01:38:59.897419+00:00",
   "repo": "tlswg/draft-ietf-tls-esni",
   "labels": [
     {
@@ -13117,7 +13117,7 @@
       "labels": [],
       "body": "The draft claims to work with DTLS, but it's slightly ambiguous. We use `ClientHello` structures directly in ECH structures, but `ClientHello` is one of the structures that DTLS changes. Do we use the DTLS version or the TLS version? The differences are:\r\n\r\n1. The `legacy_version` field is hardcoded to a different value.\r\n2. There is a goofy `legacy_cookie` field.\r\n\r\nThe goofy `legacy_cookie` field is interesting. In principle, it should really should get the same treatment as `legacy_session_id` and be copied over, because there's nothing to hide there. But I think it's actually always empty, since HelloVerifyRequest is banned in DTLS 1.3. But then we probably need to answer dumb questions like:\r\n\r\n1. What happens if a client sends an ECH-ful ClientHello and gets HelloVerifyRequest back?\r\n2. What happens if a server receives an ECH-ful ClientHello but the legacy_cookie field isn't empty?\r\n3. Do we have injectivity problems allowing the two ClientHellos in there? I think we're fine, because `legacy_version` distinguishes the two ClientHellos but, ugh, why oh why did we do this in DTLS??\r\n\r\nNot terribly difficult, but it's ambiguous enough that I think we need to say something here. My inclination is to say that we use the DTLS ClientHello, and pick the least annoying answers for (1) and (2). But I think we do need to write them down somewhere.",
       "createdAt": "2024-11-27T06:11:47Z",
-      "updatedAt": "2024-11-28T05:06:59Z",
+      "updatedAt": "2024-12-02T15:45:20Z",
       "closedAt": null,
       "comments": [
         {
@@ -13224,6 +13224,13 @@
           "body": "Another source of ambiguity: we cite a section of RFC 8446 for HKDF-Expand-Label, but then RFC 9147 replaces HKDF-Expand-Label with a different function. Does that apply to ECH too? I assume so but we probably need a sentence to say it explicitly.\r\n\r\nWhy do we keeping doing this to ourselves? We should have picked a domain separation strategy that didn't cause an ambiguity in every TLS extension we ever write that calls HKDF-Expand-Label.",
           "createdAt": "2024-11-28T05:06:47Z",
           "updatedAt": "2024-11-28T05:06:58Z"
+        },
+        {
+          "author": "davidben",
+          "authorAssociation": "COLLABORATOR",
+          "body": "> Another source of ambiguity: we cite a section of RFC 8446 for HKDF-Expand-Label, but then RFC 9147 replaces HKDF-Expand-Label with a different function.\r\n\r\nhttps://github.com/tlswg/draft-ietf-tls-esni/pull/641 does the minimal thing here, but we really made a mess of HKDF-Expand-Label in RFC 8446. Implicitly including a \"tls13\" prefix was a mistake.",
+          "createdAt": "2024-12-02T15:45:18Z",
+          "updatedAt": "2024-12-02T15:45:18Z"
         }
       ]
     }
@@ -57908,7 +57915,7 @@
       "labels": [],
       "body": "This PR implements the option if we decide to use DTLS's ClientHello as the payload and AAD, rather than somehow fit TLS's in there.\r\n\r\nFixes #639.\r\n\r\nI haven't yet gotten this working for BoringSSL (probably will finish that after the holiday), but I suspect this is the more straightforward option for us. @martinthomson what has NSS implemented / would be more convenient for NSS?",
       "createdAt": "2024-11-27T18:36:12Z",
-      "updatedAt": "2024-11-28T00:23:11Z",
+      "updatedAt": "2024-12-02T15:45:29Z",
       "baseRepository": "tlswg/draft-ietf-tls-esni",
       "baseRefName": "master",
       "baseRefOid": "d2e60197f3f1b70a5c11c875da2c826736bded51",
@@ -57933,6 +57940,20 @@
           "body": "> I haven't yet gotten this working for BoringSSL\r\n\r\nI can now report that there is at least one implementation. \ud83d\ude42 Possibly two if NSS had already done it before all this. Also our Go testing stack if you count that one, but that stack is weird.\r\n\r\nIt was a lot of chasing down of the TLS vs DTLS header (our DTLS stack carries the old style header around because it was the way you spelled it in 1.2), and making sure all the ClientHello processing bits picked up the right now. But nothing fundamentally hard. Just more ways that we pay for DTLS 1.2's sins.",
           "createdAt": "2024-11-28T00:23:10Z",
           "updatedAt": "2024-11-28T00:23:10Z"
+        },
+        {
+          "author": "ekr",
+          "authorAssociation": "COLLABORATOR",
+          "body": "I believe this is the correct resolution. @seanturner @jsalowey @dconnolly  are you OK with merging it?",
+          "createdAt": "2024-12-01T22:01:09Z",
+          "updatedAt": "2024-12-01T22:01:09Z"
+        },
+        {
+          "author": "davidben",
+          "authorAssociation": "COLLABORATOR",
+          "body": "Also got https://github.com/tlswg/draft-ietf-tls-esni/pull/641. \ud83d\ude1e",
+          "createdAt": "2024-12-02T15:45:27Z",
+          "updatedAt": "2024-12-02T15:45:27Z"
         }
       ],
       "reviews": [
@@ -57950,6 +57971,32 @@
           "comments": []
         }
       ]
+    },
+    {
+      "number": 641,
+      "id": "PR_kwDOB-yxNc6DxC1v",
+      "title": "Clarify that DTLS uses the DTLS HKDF-Expand-Label",
+      "url": "https://github.com/tlswg/draft-ietf-tls-esni/pull/641",
+      "state": "OPEN",
+      "author": "davidben",
+      "authorAssociation": "COLLABORATOR",
+      "assignees": [],
+      "labels": [],
+      "body": "(I made this into a separate PR from #640 just because I realized the ambiguity later and it seemed rude to change #640 after folks have already looked at it.)\r\n\r\nWe've made a mess of things and now every extension that cites HKDF-Expand-Label needs to clarify this. This seems like a mistake.\r\n\r\nWorse, if a future TLS 1.4 change the \"tls13\" prefix to \"tls14\", every extension will now become ambiguous! I've left that alone in this document, but we may need to contend with this later.\r\n\r\nIn hindsight, we should have excluded the implicit \"tls13 \" prefix from the HKDF-Expand-Label function. Instead, the version-dependent labels could have been incorporated into individual labels as needed. (In particular, I don't think this label actually needed to be version-dependent.)\r\n\r\nInstead we seem to have implicitly decided that HKDF-Expand-Label is part of the \"interface\" that TLS exposes to its extensions, without remembering to say so clearly.\r\n\r\nAnyway, this PR does the minimal thing to paper over this mess.",
+      "createdAt": "2024-12-02T15:44:06Z",
+      "updatedAt": "2024-12-02T15:44:07Z",
+      "baseRepository": "tlswg/draft-ietf-tls-esni",
+      "baseRefName": "master",
+      "baseRefOid": "d2e60197f3f1b70a5c11c875da2c826736bded51",
+      "headRepository": "davidben/draft-ietf-tls-esni",
+      "headRefName": "clarify-dtls-2",
+      "headRefOid": "9a378ded96957fbe62155a94735e74f843fe0c0f",
+      "closedAt": null,
+      "mergedAt": null,
+      "mergedBy": null,
+      "mergeCommit": null,
+      "comments": [],
+      "reviews": []
     }
   ]
 }