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

[Dennis Jackson <[e-mail]>]

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=[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.
>
>
> 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 <[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]
>>                 <mailto:[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]
>>                     <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]
>>                         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 [e-mail]
>     _______________________________________________
>     Spasm mailing list -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>