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

[Richard Barnes <[e-mail]>]

FWIW, here's a PR that does just that:

https://github.com/cfrg/draft-irtf-cfrg-concrete-hybrid-kems/pull/37


On Wed, Oct 29, 2025 at 11:02 AM Dennis Jackson <ietf=
[e-mail]> 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.
>
> 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 <[e-mail]> 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 <[e-mail]>
>> 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=
>>> [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]
>>>
>>>
> _______________________________________________
> 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]
>