Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4E10F7ECF806 for ; Thu, 30 Oct 2025 04:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=dennis-jackson.uk Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlzPhZ0nz9gv for ; Thu, 30 Oct 2025 04:19:22 -0700 (PDT) Received: from mout-p-103.mailbox.org (mout-p-103.mailbox.org [80.241.56.161]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E69C47ECF7F6 for ; Thu, 30 Oct 2025 04:19:21 -0700 (PDT) Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4cy1pS2scJz9tCK; Thu, 30 Oct 2025 12:19:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dennis-jackson.uk; s=MBO0001; t=1761823152; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5MMY27oT1hxEQQSmEYWMU54AnTOx5/e/RT3MiQv1zyc=; b=J0I1fcEpqNgNJKcFyVVmsOyr9iD0skKWNQHLFzAl8AfzmGejcH9zWn5yJ/bXyUEYZ+MIxx sr4i3IQWSb+wkpN4vFsSz9iBV7VRgofJKcM9r5NYivwq1VeBFmhHGYtkrkSABgnxmIBe8J owHOAnD96CAoc81zTAl1s0wtyAwKnepMdCNSzX03gVFek2BbZ9NLVwtX4WOOg3ah+JhOW9 CWEm4Y0BYP9E1wKkumNb2sgv+PiaadW4q+abQz5o1pQW/6LAJYig5ug59gVcN6bIlPQJNh /GdM8ePLFsrJtndQYl1xu/OnOYWhO71k12/1x4T7gXIt+3+eMMmUIutlUN8X5g== Content-Type: multipart/alternative; boundary="------------3sW0WVXyJht1Z0QykpM0I1vE" Message-ID: <243852fc-e0d4-4230-9238-b302c37b3ff7@dennis-jackson.uk> Date: Thu, 30 Oct 2025 11:19:10 +0000 MIME-Version: 1.0 To: cfrg@irtf.org References: <2D85ACB8-26D1-4E42-B4BE-DD5CD9BDE33A@nps.edu> <2eff0118-f6c9-4292-b28d-c12e7aefc358@dennis-jackson.uk> Content-Language: en-US From: Dennis Jackson In-Reply-To: Message-ID-Hash: 6DWQEBQAN6CXXXILYGVIITVGUWFNVKMY X-Message-ID-Hash: 6DWQEBQAN6CXXXILYGVIITVGUWFNVKMY X-MailFrom: ietf@dennis-jackson.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: LAMPS , hpke@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_=5Blamps=5D_Re=3A_Re=3A_=5Bhpke=5D_Re=3A_Re=3A_Ne?= =?utf-8?q?w_labels_in_draft-irtf-cfrg-concrete-hybrid-kems-01?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------3sW0WVXyJht1Z0QykpM0I1vE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit There is no technical argument here. I can't say I care for Star Wars either*, but all we need is some distinct hex strings. That's been accomplished: >> 0x7C2D28292D7C for X-Wing >> 0x5C2E2F2F5E5C for P256-ML-KEM1024 >> 0x207C202F2D5C for P384-ML-KEM1024 We should move on. Best, Dennis * tbf Andor was pretty good. On 29/10/2025 21:05, Eric Rescorla wrote: > > > On Wed, Oct 29, 2025 at 2:03 PM Dennis Jackson > wrote: > > My understanding is that the new labels in the CFRG draft were > chosen because nobody could agree on what human readable content > to include. > > The timing around when the drafts landed & the communication > around the label change has made things messy and I totally get > the frustration there. > > A pragmatic way forward would be to just use the hex and drop the > ASCII from the cfrg draft: > >> 0x7C2D28292D7C for X-Wing >> 0x5C2E2F2F5E5C for P256-ML-KEM1024 >> 0x207C202F2D5C for P384-ML-KEM1024 > > These numbers are as good as any other and it paves over the > issues folks already ran into with the (unchangeable) X-Wing label. > > > I don't agree that they're as good as any other. We should resist the > urge to be clever when we don't have to, and "this hex string just > happens to map to some piece of Star Wars inspired ASCII art" > is, at least for me, in that category. > > -Ekr > > Best, > Dennis > > On 29/10/2025 20:43, Eric Rescorla wrote: >> Following up to myself.... I'm also fine with the LAMPS strings. >> >> -Ekr >> >> >> On Wed, Oct 29, 2025 at 1:27 PM Eric Rescorla wrote: >> >> I would make a few points here: >> >> I don't have a strong opinion on whether we ought to have >> structured strings or just 6-byte constants but ISTM that >> having the spec contain strings which contain special >> characters are a clear safety hazard, and the only motivation >> for them seems to be to make a Star Wars joke, which really >> doesn't seem like a priority for the RG. That seems more like >> a bug than a feature to me. With that said, while the X-wing >> label is unfortunate, I don't think anyone is proposing to >> change it, but no such considerations exist for the other >> value. To that end, I propose the following: >> >> - Render the labels only as hex values. >> - Replace the non-X-wing labels with values which don't >> happen to correspond to escape characters. The obvious thing >> to do here is just to use a simple counter, so we can use >> (x00...00 and 0x00..02) but I could imagine other approaches. >> >> The net effect of these is to slightly reduce the surface >> area for errors without creating an interop problem or >> arguments about the semantics of the strings. >> >> Finally, I would observe that arguments of the form "we need >> to get things out now so we need to do things the way I >> prefer" are less persuasive than "we need to get this now so >> I'm prepared to do things a way I don't really like". >> >> -Ekr >> >> >> >> On Wed, Oct 29, 2025 at 1:11 PM Sophie Schmieg >> wrote: >> >> The labels are simple numeric codepoints: >> 0x7C2D28292D7C for X-Wing >> 0x5C2E2F2F5E5C for P256-ML-KEM1024 >> 0x207C202F2D5C for P384-ML-KEM1024 >> in little endian. >> And yes, I concur with Filippo, we need to be able to >> ship without being held up by discussions on naming >> things, and simple numerical values like the ones above >> allow us to do just that. >> >> On Wed, Oct 29, 2025 at 12:17 PM Hale, Britta (CIV) >> wrote: >> >> I concur with keeping clear and human-readable >> ciphersuites (e.g., >> “QSF-P256-MLKEM768-SHAKE256-SHA3256”). Post quantum >> migration is challenging enough without adding a >> further mapping that humans can mis-interpret, which >> can itself lead to introduction of vulnerabilities >> while attempting use of post quantum algorithms. >> >> If there are any cases where shorthand is absolutely >> needed (e.g., in specific WGs where counting bytes >> matters), then reference strings ought to be simple >> such as a numeric mapping to specific suites. ASCII >> art makes it difficult to ensure correctness, even >> among knowledgeable individuals, as is evident by the >> examples already encountered. We should not be making >> standards intentionally more difficult to follow for >> less experienced individuals. >> >> Britta >> >> *From: *Mike Ounsworth > > >> *Date: *Wednesday, October 29, 2025 at 11:11 AM >> *To: *Eric Rescorla >> *Cc: *LAMPS WG , CFRG >> , "hpke@ietf.org" >> *Subject: *[CFRG] Re: New labels in >> draft-irtf-cfrg-concrete-hybrid-kems-01 >> >> NPS WARNING: *external sender* verify before acting. >> >> As as pointed out by Daniel Van Geest in another >> thread, the label for MLKEM1024-P384 is supposed to >> be " | /-\", but in the published version of the cfrg >> draft (both HTML and TXT), it displays as ` | /-` >> (note the missing backslash). So that means that the >> kramdown2rfc tooling is not handling this properly. >> >> So when I said "This is GOING to lead to at least >> incompatibilities if not CVEs" I didn't realize that >> we already had one in the draft. >> >> The point is this: >> >> The LAMPS doc is already in WGLC (months later than >> we wanted), using the labels from YOUR -00 (minus the >> SHAKE256 component). I made that change in >> consultation with you guys as part of the CRFC >> Interim in Sept. Your doc is not in WGLC yet, so can >> you please change your labels to match? >> >> On Wed, 29 Oct 2025 at 12:47, Eric Rescorla >> wrote: >> >> I can't speak for what has or has not happened in >> terms of interop, but on the >> >> substance of the labels I agree with Mike. I >> strongly prefer simple human-readable >> >> labels to ASCII art Star Wars references, no >> matter how clever those references >> >> might be. >> >> -Ekr >> >> On Wed, Oct 29, 2025 at 10:36 AM Mike Ounsworth >> > > wrote: >> >> draft-irtf-cfrg-concrete-hybrid-kems-01 >> publish on Oct 20 and made the following >> label changes: >> >> "QSF-P256-MLKEM768-SHAKE256-SHA3256" -->  >> "|-()-|" >> >> "QSF-P384-MLKEM1024-SHAKE256-SHA3256" --> " | /-" >> >> >> >> Please tell me this is a joke. Then please >> remove this from the draft and put the labels >> back to sane alphanumeric. I'm sorry for >> strong language below, but this makes me mad. >> >> I have been bending over backwards to make >> the LAMPS thing match the HPKE thing, >> including multiple rounds of interop-testing >> against your test vectors and changing the >> LAMPS draft, reference impl, and test vectors >> to match yours. This has resulted in delayed >> publication of the LAMPS draft by several >> months to accommodate interop with the HPKE >> draft. The LAMPS Composite-KEM doc went into >> WGLC on Oct 17 now using HPKE-style labels of >> the form "QSF-MLKEM768-P256-SHA3256" that we >> pulled FROM YOUR DRAFT instead of the >> OID-based labels we had before. Then on Oct >> 20 you publish a new version that goes and >> changes the labels to this nonsense. Can you >> guys please at least pretend like you care >> about interop between these two docs? >> >> My specific objections to more ASCII art labels: >> >> 1. We're already having interop problems at >> the PQC hackathon group because of the >> backslash in the xwing label -- for example, >> in python you have to put the constant in >> your source code as "\\.//^\\" to prevent it >> from interpreting that as an escaped dot and >> double-quote. We've also had similar problems >> representing this label properly in HTML and >> markdown docs. Now you want more labels that >> have both backslashes and now spaces. This is >> GOING to lead to at least incompatibilities >> if not CVEs. >> >> 2. The label is not human-readable; it >> doesn't tell my anything useful about the >> content, nor will it be easy to debug >> mistakes in source code or config files. At >> this point, assigning a numeric codepoint >> would be preferable. >> >> 3. This does not establish a naming >> convention that is easily extensible to other >> hybrid combinations. >> >> I have been doing everything in my power to >> work behind the scenes to get interop between >> these two documents, and it feels like you >> guys are doing everything in your power to >> obstruct it. >> >> >> Can you please put your labels back so that >> they match the LAMPS draft using the pattern >> "QSF-MLKEM768-P256-SHA3256". >> >> (PS this is a re-send from the correct email >> address) >> >> >> -Mike >> >> _______________________________________________ >> CFRG mailing list -- cfrg@irtf.org >> To unsubscribe send an email to >> cfrg-leave@irtf.org >> >> _______________________________________________ >> hpke mailing list -- hpke@ietf.org >> To unsubscribe send an email to hpke-leave@ietf.org >> >> >> >> -- >> >> Sophie Schmieg | Information Security Engineer | ISE >> Crypto |sschmieg@google.com >> >> >> _______________________________________________ >> CFRG mailing list --cfrg@irtf.org >> To unsubscribe send an email tocfrg-leave@irtf.org > _______________________________________________ > Spasm mailing list -- spasm@ietf.org > To unsubscribe send an email to spasm-leave@ietf.org > --------------3sW0WVXyJht1Z0QykpM0I1vE Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

There is no technical argument here. I can't say I care for Star Wars either*, but all we need is some distinct hex strings. That's been accomplished:

0x7C2D28292D7C for X-Wing
0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM1024
We should move on.

Best,
Dennis

* tbf Andor was pretty good.  

On 29/10/2025 21:05, Eric Rescorla wrote:



On Wed, Oct 29, 2025 at 2:03 PM Dennis Jackson <ietf=40dennis-jackson.uk@dmarc.ietf.org> wrote:

My understanding is that the new labels in the CFRG draft were chosen because nobody could agree on what human readable content to include. 

The timing around when the drafts landed & the communication around the label change has made things messy and I totally get the frustration there.

A pragmatic way forward would be to just use the hex and drop the ASCII from the cfrg draft:

0x7C2D28292D7C for X-Wing
0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM1024

These numbers are as good as any other and it paves over the issues folks already ran into with the (unchangeable) X-Wing label.


I don't agree that they're as good as any other. We should resist the
urge to be clever when we don't have to, and "this hex string just
happens to map to some piece of Star Wars inspired ASCII art"
is, at least for me, in that category.

-Ekr

Best,
Dennis

On 29/10/2025 20:43, Eric Rescorla wrote:
Following up to myself.... I'm also fine with the LAMPS strings.

-Ekr


On Wed, Oct 29, 2025 at 1:27 PM Eric Rescorla <ekr@rtfm.com> wrote:
I would make a few points here:

I don't have a strong opinion on whether we ought to have structured strings or just 6-byte constants but ISTM that having the spec contain strings which contain special characters are a clear safety hazard, and the only motivation for them seems to be to make a Star Wars joke, which really doesn't seem like a priority for the RG. That seems more like a bug than a feature to me. With that said, while the X-wing label is unfortunate, I don't think anyone is proposing to change it, but no such considerations exist for the other value. To that end, I propose the following:

- Render the labels only as hex values.
- Replace the non-X-wing labels with values which don't happen to correspond to escape characters. The obvious thing to do here is just to use a simple counter, so we can use (x00...00 and 0x00..02) but I could imagine other approaches.

The net effect of these is to slightly reduce the surface area for errors without creating an interop problem or arguments about the semantics of the strings. 

Finally, I would observe that arguments of the form "we need to get things out now so we need to do things the way I prefer" are less persuasive than "we need to get this now so I'm prepared to do things a way I don't really like".

-Ekr



On Wed, Oct 29, 2025 at 1:11 PM Sophie Schmieg <sschmieg@google.com> wrote:
The labels are simple numeric codepoints:
0x7C2D28292D7C for X-Wing
0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM1024
in little endian.
And yes, I concur with Filippo, we need to be able to ship without being held up by discussions on naming things, and simple numerical values like the ones above allow us to do just that.

On Wed, Oct 29, 2025 at 12:17 PM Hale, Britta (CIV) <britta.hale=40nps.edu@dmarc.ietf.org> wrote:

I concur with keeping clear and human-readable ciphersuites (e.g., “QSF-P256-MLKEM768-SHAKE256-SHA3256”). Post quantum migration is challenging enough without adding a further mapping that humans can mis-interpret, which can itself lead to introduction of vulnerabilities while attempting use of post quantum algorithms.

 

If there are any cases where shorthand is absolutely needed (e.g., in specific WGs where counting bytes matters), then reference strings ought to be simple such as a numeric mapping to specific suites. ASCII art makes it difficult to ensure correctness, even among knowledgeable individuals, as is evident by the examples already encountered. We should not be making standards intentionally more difficult to follow for less experienced individuals.

 

Britta

 

 

From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Wednesday, October 29, 2025 at 11:11 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: LAMPS WG <spasm@ietf.org>, CFRG <cfrg@irtf.org>, "hpke@ietf.org" <hpke@ietf.org>
Subject: [CFRG] Re: New labels in draft-irtf-cfrg-concrete-hybrid-kems-01

 

NPS WARNING: *external sender* verify before acting.

 

As as pointed out by Daniel Van Geest in another thread, the label for MLKEM1024-P384 is supposed to be " | /-\", but in the published version of the cfrg draft (both HTML and TXT), it displays as ` | /-` (note the missing backslash). So that means that the kramdown2rfc tooling is not handling this properly.

 

So when I said "This is GOING to lead to at least incompatibilities if not CVEs" I didn't realize that we already had one in the draft.

 

The point is this:

The LAMPS doc is already in WGLC (months later than we wanted), using the labels from YOUR -00 (minus the SHAKE256 component). I made that change in consultation with you guys as part of the CRFC Interim in Sept. Your doc is not in WGLC yet, so can you please change your labels to match?

 

On Wed, 29 Oct 2025 at 12:47, Eric Rescorla <ekr@rtfm.com> wrote:

I can't speak for what has or has not happened in terms of interop, but on the

substance of the labels I agree with Mike. I strongly prefer simple human-readable

labels to ASCII art Star Wars references, no matter how clever those references

might be.

 

-Ekr

 

On Wed, Oct 29, 2025 at 10:36 AM Mike Ounsworth <ounsworth+ietf@gmail.com> wrote:

draft-irtf-cfrg-concrete-hybrid-kems-01 publish on Oct 20 and made the following label changes:

 

 

"QSF-P256-MLKEM768-SHAKE256-SHA3256" -->  "|-()-|"

"QSF-P384-MLKEM1024-SHAKE256-SHA3256" --> " | /-"



Please tell me this is a joke. Then please remove this from the draft and put the labels back to sane alphanumeric. I'm sorry for strong language below, but this makes me mad.

I have been bending over backwards to make the LAMPS thing match the HPKE thing, including multiple rounds of interop-testing against your test vectors and changing the LAMPS draft, reference impl, and test vectors to match yours. This has resulted in delayed publication of the LAMPS draft by several months to accommodate interop with the HPKE draft. The LAMPS Composite-KEM doc went into WGLC on Oct 17 now using HPKE-style labels of the form "QSF-MLKEM768-P256-SHA3256" that we pulled FROM YOUR DRAFT instead of the OID-based labels we had before. Then on Oct 20 you publish a new version that goes and changes the labels to this nonsense. Can you guys please at least pretend like you care about interop between these two docs?

My specific objections to more ASCII art labels:

1. We're already having interop problems at the PQC hackathon group because of the backslash in the xwing label -- for example, in python you have to put the constant in your source code as "\\.//^\\" to prevent it from interpreting that as an escaped dot and double-quote. We've also had similar problems representing this label properly in HTML and markdown docs. Now you want more labels that have both backslashes and now spaces. This is GOING to lead to at least incompatibilities if not CVEs.

2. The label is not human-readable; it doesn't tell my anything useful about the content, nor will it be easy to debug mistakes in source code or config files. At this point, assigning a numeric codepoint would be preferable.

3. This does not establish a naming convention that is easily extensible to other hybrid combinations.

I have been doing everything in my power to work behind the scenes to get interop between these two documents, and it feels like you guys are doing everything in your power to obstruct it.


Can you please put your labels back so that they match the LAMPS draft using the pattern "QSF-MLKEM768-P256-SHA3256".

 

(PS this is a re-send from the correct email address)


-Mike

_______________________________________________
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org

_______________________________________________
hpke mailing list -- hpke@ietf.org
To unsubscribe send an email to hpke-leave@ietf.org


--

Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com


_______________________________________________
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
_______________________________________________
Spasm mailing list -- spasm@ietf.org
To unsubscribe send an email to spasm-leave@ietf.org
--------------3sW0WVXyJht1Z0QykpM0I1vE--