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

[Mike Ounsworth <[e-mail]>]

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]
>>
>