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

[Sophie Schmieg <[e-mail]>]

I honestly just want something stable that can be shipped. ASCII art (or
their hex equivalent) allow us to circumvent the known hardest problem in
computer science, and decouple shippable code from naming things. If the
LAMPS labels were stable (which it seems they aren't if I'm reading
Richard's mail right), I'd happily go with those.

On Wed, Oct 29, 2025 at 2:37 PM Richard Barnes <[e-mail]> wrote:

> Someone pointed out to me that I was looking at the wrong draft of the
> LAMPS document, and that there are ASCII labels in the latest draft, e.g.,
> "QSF-MLKEM768-RSAOAEP2048-SHA3256":
>
>
> https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-08.html#name-algorithm-identifiers-and-p
>
> That said, I'm sorry to say to Mike that "just use the LAMPS labels" is
> basically the pessimal option here -- it appears to be semantic, but
> isn't.  "QSF" is not a thing you can instantiate with RSA-OAEP.  We defined
> a thing that you can, but it's called "CK" (C2PRI + KEM), not QSF.  So the
> LAMPS doc is going to need an update anyway if they want to align with the
> CFRG doc, regardless of what direction the CFRG doc takes.
>
> --Ricahrd
>
>
> On Wed, Oct 29, 2025 at 10:59 AM Richard Barnes <[e-mail]> wrote:
>
>> So first, a couple of high-level points:
>>
>> 1. This is a CFRG issue, so trimming to the CFRG list.
>>
>> 2. "This is insane" is out of order, Mike.  If you look at the PR, the
>> intent of all involved was to get things done faster by decoupling names
>> from labels [1].  Folks are working in good faith here.
>>
>> Now, on the substance:
>>
>> I'm confused about what exactly the proposal is here.  In particular, I
>> don't understand what LAMPS labels we're talking about -- looking at that
>> document [2], it looks like the Domain values are playing the role that
>> we're talking about, and those are opaque hex things (OIDs?).
>>
>> I'm also not sure what you're remembering about the CFRG interim.  I
>> would be surprised if there were agreement to any fixed labels there, since
>> it was still TODO to update the concrete doc to match the generic one at
>> that point.  If what you're thinking of got recorded somewhere, that would
>> be helpful.  I'm not seeing it in the GitHub issues.
>>
>> Personally, I have no religion here, I also just want this done.  I
>> appreciate the interop concern about special characters, but I think that's
>> adequately addressed by removing the ASCII and just presenting hex (as the
>> LAMPS doc does).  I don't think there's a ton of benefit to human-readable
>> labels.  We basically only have strings because they get us
>> arbitrary-length labels without having to invent a bigint syntax.
>>
>> --Richard
>>
>> [1] https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/28
>> [2]
>> https://www.ietf.org/archive/id/draft-ietf-lamps-pq-composite-kem-07.html#name-domain-separator-values
>>
>> On Wed, Oct 29, 2025 at 10:35 AM Mike Ounsworth <Mike.Ounsworth=
>> [e-mail]> wrote:
>>
>>> Sophie, your argument is self-defeating. The LAMPS document has been in
>>> WGLC since Oct 17 using the labels from the cfrg-00. Those new spaceships
>>> only showed up on Oct 20, now we're talking about blowing up the LAMPS WGLC
>>> and starting over with breaking changes to the test vectors.
>>>
>>> So "stop holding things up on discussions on naming" means take the
>>> labels that we agreed to at the CFRG interim in Sept, that are already in
>>> the LAMPS WGLC version. This is insane.
>>>
>>> ---
>>> Mike Ounsworth
>>>
>>> ------------------------------
>>> *From:* Sophie Schmieg <sschmieg=[e-mail]>
>>> *Sent:* Wednesday, October 29, 2025 3:12:49 p.m.
>>> *To:* Hale, Britta (CIV) <britta.hale=[e-mail]>
>>> *Cc:* Mike Ounsworth <[e-mail]>; Eric Rescorla <
>>> [e-mail]>; LAMPS WG <[e-mail]>; CFRG <[e-mail]>;
>>> [e-mail] <[e-mail]>
>>> *Subject:* [EXTERNAL] [lamps] Re: [hpke] Re: [CFRG] Re: New labels in
>>> draft-irtf-cfrg-concrete-hybrid-kems-01
>>>
>>> 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
>>> 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=
>>> [e-mail]> 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 <[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]> 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]> 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]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> hpke mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>>>
>>> --
>>>
>>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>>> [e-mail]
>>>
>>>
>>> *Any email and files/attachments transmitted with it are intended solely
>>> for the use of the individual or entity to whom they are addressed. If this
>>> message has been sent to you in error, you must not copy, distribute or
>>> disclose of the information it contains. Please notify Entrust immediately
>>> and delete the message from your system.*
>>>
>>> _______________________________________________
>>> hpke mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[e-mail]