Skip to content

Commit b03f329

Browse files
author
ID Bot
committed
Script updating archive at 2025-02-02T00:17:54Z. [ci skip]
1 parent 9ab78d2 commit b03f329

File tree

1 file changed

+194
-13
lines changed

1 file changed

+194
-13
lines changed

‎archive.json‎

Lines changed: 194 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
{
22
"magic": "E!vIA5L86J2I",
3-
"timestamp": "2025-01-30T00:16:13.910889+00:00",
3+
"timestamp": "2025-02-02T00:17:52.741009+00:00",
44
"repo": "chris-wood/draft-bmw-tls-pake13",
55
"labels": [
66
{
@@ -388,22 +388,29 @@
388388
"id": "I_kwDOM83jm86jILH2",
389389
"title": "How does juggling multiple PAKE algorithms work?",
390390
"url": "https://github.com/chris-wood/draft-bmw-tls-pake13/issues/12",
391-
"state": "OPEN",
391+
"state": "CLOSED",
392392
"author": "davidben",
393393
"authorAssociation": "COLLABORATOR",
394394
"assignees": [],
395395
"labels": [],
396396
"body": "If transitioning between PAKEs algorithms, a client may find itself needing to offer multiple PAKE shares. But this means computing the initial message for _each_ PAKE and sending all of them. This may be expensive for, e.g. PQ-sized options or just when there are many algorithms to support.\r\n\r\nFor key_share, we had this whole HelloRetryRequest dance. Do we need something similar here?",
397397
"createdAt": "2024-12-12T20:33:12Z",
398-
"updatedAt": "2025-01-07T00:38:09Z",
399-
"closedAt": null,
398+
"updatedAt": "2025-01-31T22:16:03Z",
399+
"closedAt": "2025-01-31T22:16:02Z",
400400
"comments": [
401401
{
402402
"author": "baumanl",
403403
"authorAssociation": "COLLABORATOR",
404404
"body": "Our take was that unlike key_share and the general situation where the TLS client and server need to be able to handle a broad range of supported group options, in the PAKE case it is unlikely there will be many algorithms. PAKEs are typically used for more peer to peer protocols and require the client to register to the server before running the protocol, so if the server requires a specific PAKE it could feasibly tell the client that at registration time (maybe we don't want to depend on application layer negotiation of TLS parameters, but this seems like a case where it would be possible). \r\n\r\nIn the case where multiple PQ sized options need to be computed and sent then HRR support could be useful. But considering we don't yet have a single PQ PAKE I am not convinced it is worth the complexity to specify the entire HRR flow now as opposed to leaving it for future work if and when it becomes a concern. ",
405405
"createdAt": "2025-01-07T00:38:07Z",
406406
"updatedAt": "2025-01-07T00:38:07Z"
407+
},
408+
{
409+
"author": "baumanl",
410+
"authorAssociation": "COLLABORATOR",
411+
"body": "@davidben I believe we discussed this offline. I'm going to close, but let me know if there are still concerns here.",
412+
"createdAt": "2025-01-31T22:16:02Z",
413+
"updatedAt": "2025-01-31T22:16:02Z"
407414
}
408415
]
409416
},
@@ -438,31 +445,60 @@
438445
"id": "I_kwDOM83jm86mrcjg",
439446
"title": "Rename NamedPAKE to just PAKE or so?",
440447
"url": "https://github.com/chris-wood/draft-bmw-tls-pake13/issues/15",
441-
"state": "OPEN",
448+
"state": "CLOSED",
442449
"author": "davidben",
443450
"authorAssociation": "COLLABORATOR",
444451
"assignees": [],
445452
"labels": [],
446453
"body": "I'm guessing NamedPAKE was chosen in reference to NamedGroup and NamedCurve? AIUI, \"named\" there is because both ECDHE and DHE had incarnations in TLS where, rather than referencing the algorithm by name, you spelled the parameters out explicitly.\n\n* DHE had the pre-RFC-7919 formulation where the server just specified p and g on the wire. (The post-RFC-7919 formulation is also didn't really fix it, but that's beside the point. \ud83d\ude04)\n* RFC 4492, before RFC 8996 removed it, had `arbitrary_explicit_prime_curves` and `arbitrary_explicit_char2_curves` for spelling the ECDHE curve out.\n\nThese explicit options were widely considered mistakes, so hopefully we won't have this named vs explicit dichotomy to capture anymore. Elsewhere, cipher suites and signature schemes are also names given to parameter sets, and we just call them CipherSuite and SignatureScheme since there is an alternate to distinguish.\n\nGiven that, should we rename `NamedPAKE` to just `PAKE` or something? (And then folks aren't tempted to stick \"named\" in APIs, which seems just confusing. \ud83d\ude04 )",
447454
"createdAt": "2025-01-17T22:28:04Z",
448-
"updatedAt": "2025-01-17T22:28:04Z",
449-
"closedAt": null,
450-
"comments": []
455+
"updatedAt": "2025-01-31T23:12:38Z",
456+
"closedAt": "2025-01-31T23:12:38Z",
457+
"comments": [
458+
{
459+
"author": "baumanl",
460+
"authorAssociation": "COLLABORATOR",
461+
"body": "I defer to your knowledge of the history of \"named\" prefixes and I agree we don't want to imply we are also supporting an \"explicit\" parameter mode! But when just `PAKE` is used I think parts of the draft could be confusing to read since there could potentially be different `PAKE`'s all using the same underlying PAKE but with different parameters selected. (e.g. `SPAKE2PLUS_V1` and a theoretical `SPAKE2PLUS_V2`). ",
462+
"createdAt": "2025-01-31T19:03:15Z",
463+
"updatedAt": "2025-01-31T19:03:15Z"
464+
},
465+
{
466+
"author": "davidben",
467+
"authorAssociation": "COLLABORATOR",
468+
"body": "Ah yeah, having both `PAKE` (the enum) and `pake` (the extension) is confusing. Also gets into philosophical questions about whether SPAKE2+ is a PAKE or a parameterized family of PAKEs. I dunno if \"named\" really captures that either though. (Mostly I feel very silly saying \"named group\" to people because it's such a meaningless combination of words. \ud83d\ude06)\n\nHmm... spitballing, what about PAKEScheme or PAKEAlgorithm or PAKESuite?\n\nSignatures use SignatureScheme, but that's mostly because SignatureAlgorithm was already taken (also by a parameterized family vs instantiation mishap). But scheme is also shorter than algorithm, so I don't particularly regret it.\n\nCipher suites use \"suite\" but that's because they used to be all-encompassing (in SSL 3 they were the only parameter) and then gradually chunks got pulled out (we have `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256`, not `TLS_ECDHE_P256_RSA_WITH_AES_128_GCM_SHA256`), until we finally gave up on that in TLS 1.3 and made them just the AEAD and PRF hash. (And really the PRF hash was only there because adding a new enum seemed silly.)\n\nI think I would lean more towards \"scheme\" or \"algorithm\". There's also \"ID\" but PAKEID is illegible.\n\nWDYT?",
469+
"createdAt": "2025-01-31T19:50:05Z",
470+
"updatedAt": "2025-01-31T19:50:05Z"
471+
},
472+
{
473+
"author": "baumanl",
474+
"authorAssociation": "COLLABORATOR",
475+
"body": "I like PAKEScheme. I think algorithm still somewhat implies that it is referring to a particular PAKE/family of PAKEs. I think Scheme is fuzzy enough that it avoids that but still provides enough context on what the enum is. ",
476+
"createdAt": "2025-01-31T19:54:28Z",
477+
"updatedAt": "2025-01-31T19:54:28Z"
478+
},
479+
{
480+
"author": "davidben",
481+
"authorAssociation": "COLLABORATOR",
482+
"body": "SGTM!",
483+
"createdAt": "2025-01-31T21:45:58Z",
484+
"updatedAt": "2025-01-31T21:45:58Z"
485+
}
486+
]
451487
},
452488
{
453489
"number": 16,
454490
"id": "I_kwDOM83jm86num3H",
455491
"title": "pake removes the need for supported_groups and signature_algorithms",
456492
"url": "https://github.com/chris-wood/draft-bmw-tls-pake13/issues/16",
457-
"state": "OPEN",
493+
"state": "CLOSED",
458494
"author": "davidben",
459495
"authorAssociation": "COLLABORATOR",
460496
"assignees": [],
461497
"labels": [],
462498
"body": "RFC 8446, section 9.2 has this text:\n\n> - If not containing a \"pre_shared_key\" extension, it MUST contain\n> both a \"signature_algorithms\" extension and a \"supported_groups\"\n> extension.\n\nThis text is correct for RFC 8446, but this draft introduces another option that removes the need for the certificate-based flow. We probably need a sentence somewhere saying that explicitly.",
463499
"createdAt": "2025-01-27T20:39:43Z",
464-
"updatedAt": "2025-01-27T20:39:43Z",
465-
"closedAt": null,
500+
"updatedAt": "2025-01-31T19:44:59Z",
501+
"closedAt": "2025-01-31T19:44:59Z",
466502
"comments": []
467503
}
468504
],
@@ -644,7 +680,7 @@
644680
"labels": [],
645681
"body": "Closes #10 ",
646682
"createdAt": "2024-12-03T21:21:00Z",
647-
"updatedAt": "2024-12-04T17:19:43Z",
683+
"updatedAt": "2025-01-31T19:35:08Z",
648684
"baseRepository": "chris-wood/draft-bmw-tls-pake13",
649685
"baseRefName": "main",
650686
"baseRefOid": "e32284368db47b9dd890e973443a87e1a7a30ac3",
@@ -655,7 +691,15 @@
655691
"mergedAt": null,
656692
"mergedBy": null,
657693
"mergeCommit": null,
658-
"comments": [],
694+
"comments": [
695+
{
696+
"author": "davidben",
697+
"authorAssociation": "COLLABORATOR",
698+
"body": "FWIW, this is the version we ended up implementing in BoringSSL. Purely because we already had the code for it and I was too lazy to change it. :-) Though if folks particularly want it to not be sorted, I can go back and tweak it. One way or another, I think we should either:\r\n\r\n* Say it is a client preference order\r\n* Say it is sorted\r\n\r\nRight now I think we say neither. But also I assume everything about negotiation will get reworked to no end later anyway.",
699+
"createdAt": "2025-01-31T19:35:06Z",
700+
"updatedAt": "2025-01-31T19:35:06Z"
701+
}
702+
],
659703
"reviews": [
660704
{
661705
"id": "PRR_kwDOM83jm86TyMZN",
@@ -713,6 +757,143 @@
713757
"comments": []
714758
}
715759
]
760+
},
761+
{
762+
"number": 17,
763+
"id": "PR_kwDOM83jm86Jrcb1",
764+
"title": "add text around modification to supported_groups requirement",
765+
"url": "https://github.com/chris-wood/draft-bmw-tls-pake13/pull/17",
766+
"state": "MERGED",
767+
"author": "baumanl",
768+
"authorAssociation": "COLLABORATOR",
769+
"assignees": [],
770+
"labels": [],
771+
"body": "Initial attempt to clarify the new requirements for a valid client hello. ",
772+
"createdAt": "2025-01-31T19:17:13Z",
773+
"updatedAt": "2025-01-31T19:44:58Z",
774+
"baseRepository": "chris-wood/draft-bmw-tls-pake13",
775+
"baseRefName": "main",
776+
"baseRefOid": "53db802b33640a2a401a5614156618136088e775",
777+
"headRepository": "chris-wood/draft-bmw-tls-pake13",
778+
"headRefName": "l_bauman/req_ext_clarification",
779+
"headRefOid": "89e49afa5582964d6c68ee939ca2ee7eeab4736a",
780+
"closedAt": "2025-01-31T19:44:58Z",
781+
"mergedAt": "2025-01-31T19:44:58Z",
782+
"mergedBy": "baumanl",
783+
"mergeCommit": {
784+
"oid": "36b2bdddc1027829fe8112c4b9f387c792ce67c2"
785+
},
786+
"comments": [],
787+
"reviews": [
788+
{
789+
"id": "PRR_kwDOM83jm86aPNI3",
790+
"commit": {
791+
"abbreviatedOid": "ad4a871"
792+
},
793+
"author": "davidben",
794+
"authorAssociation": "COLLABORATOR",
795+
"state": "APPROVED",
796+
"body": "LGTM with two extremely silly nitpicks. :-)",
797+
"createdAt": "2025-01-31T19:36:55Z",
798+
"updatedAt": "2025-01-31T19:39:08Z",
799+
"comments": [
800+
{
801+
"originalPosition": 5,
802+
"body": "Super nitpicky nitpick: I have never understood whether you are supposed to say \"Client Hello\" or \"ClientHello\" in prose. RFC 8446 uses \"Client Hello\" in section headers, but all the text says \"ClientHello\". I guess that would suggest this should say ClientHello. \ud83e\udd37 ",
803+
"createdAt": "2025-01-31T19:36:56Z",
804+
"updatedAt": "2025-01-31T19:39:08Z"
805+
},
806+
{
807+
"originalPosition": 4,
808+
"body": "Nitpick: I'm not sure if this is actually the style or if I'm just making this up, but I feel like I usually don't see normative text in Introduction sections. I might suggest either moving this to Client Behavior (where we talk about the client extension) or maybe in a separate section after Key Schedule Modifications.",
809+
"createdAt": "2025-01-31T19:38:53Z",
810+
"updatedAt": "2025-01-31T19:39:08Z"
811+
}
812+
]
813+
},
814+
{
815+
"id": "PRR_kwDOM83jm86aPPzu",
816+
"commit": {
817+
"abbreviatedOid": "ad4a871"
818+
},
819+
"author": "davidben",
820+
"authorAssociation": "COLLABORATOR",
821+
"state": "COMMENTED",
822+
"body": "",
823+
"createdAt": "2025-01-31T19:40:12Z",
824+
"updatedAt": "2025-01-31T19:40:12Z",
825+
"comments": [
826+
{
827+
"originalPosition": 4,
828+
"body": "Other reason to move this is that, in the intro, we haven't yet introduced the `pake` extension, so this should probably go somewhere after the point where `pake` is defined.",
829+
"createdAt": "2025-01-31T19:40:12Z",
830+
"updatedAt": "2025-01-31T19:40:12Z"
831+
}
832+
]
833+
},
834+
{
835+
"id": "PRR_kwDOM83jm86aPQeD",
836+
"commit": {
837+
"abbreviatedOid": "ad4a871"
838+
},
839+
"author": "baumanl",
840+
"authorAssociation": "COLLABORATOR",
841+
"state": "COMMENTED",
842+
"body": "",
843+
"createdAt": "2025-01-31T19:41:29Z",
844+
"updatedAt": "2025-01-31T19:41:29Z",
845+
"comments": [
846+
{
847+
"originalPosition": 4,
848+
"body": "Very true, will move",
849+
"createdAt": "2025-01-31T19:41:29Z",
850+
"updatedAt": "2025-01-31T19:41:29Z"
851+
}
852+
]
853+
}
854+
]
855+
},
856+
{
857+
"number": 18,
858+
"id": "PR_kwDOM83jm86JsXHD",
859+
"title": "rename NamedPAKE to PAKEScheme",
860+
"url": "https://github.com/chris-wood/draft-bmw-tls-pake13/pull/18",
861+
"state": "MERGED",
862+
"author": "baumanl",
863+
"authorAssociation": "COLLABORATOR",
864+
"assignees": [],
865+
"labels": [],
866+
"body": "",
867+
"createdAt": "2025-01-31T22:12:18Z",
868+
"updatedAt": "2025-01-31T23:12:38Z",
869+
"baseRepository": "chris-wood/draft-bmw-tls-pake13",
870+
"baseRefName": "main",
871+
"baseRefOid": "36b2bdddc1027829fe8112c4b9f387c792ce67c2",
872+
"headRepository": "chris-wood/draft-bmw-tls-pake13",
873+
"headRefName": "l_bauman/pake_scheme_rename",
874+
"headRefOid": "8077352050f8179b69e3930682239da99c3bcaeb",
875+
"closedAt": "2025-01-31T23:12:38Z",
876+
"mergedAt": "2025-01-31T23:12:37Z",
877+
"mergedBy": "baumanl",
878+
"mergeCommit": {
879+
"oid": "ce4a7db3df8e9d18f675b11c584a4d961a10de97"
880+
},
881+
"comments": [],
882+
"reviews": [
883+
{
884+
"id": "PRR_kwDOM83jm86aQggX",
885+
"commit": {
886+
"abbreviatedOid": "8077352"
887+
},
888+
"author": "davidben",
889+
"authorAssociation": "COLLABORATOR",
890+
"state": "APPROVED",
891+
"body": "",
892+
"createdAt": "2025-01-31T22:57:16Z",
893+
"updatedAt": "2025-01-31T22:57:16Z",
894+
"comments": []
895+
}
896+
]
716897
}
717898
]
718899
}

0 commit comments

Comments
 (0)