[CFRG] Re: New labels in draft-irtf-cfrg-concrete-hybrid-kems-01

["Hale, Britta (CIV)" <[e-mail]>]

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 <[e-mail]>
Date: Wednesday, October 29, 2025 at 11:11 AM
To: Eric Rescorla <[e-mail]>
Cc: LAMPS WG <[e-mail]>, CFRG <[e-mail]>, "[e-mail]" <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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 -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>