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

[Tim Hollebeek <[e-mail]>]

Yes, please, everyone just agree on something mutually acceptable and stick with it. I don’t care what it is.

 

-Tim

 

From: Rohan Mahy <[e-mail]> 
Sent: Thursday, October 30, 2025 8:42 AM
To: Mike Ounsworth <[e-mail]>
Cc: Samuel Lee (ENS/Crypto) <Samuel.Lee=[e-mail]>; Sophie Schmieg <sschmieg=[e-mail]>; Mike Ounsworth <Mike.Ounsworth=[e-mail]>; CFRG <[e-mail]>
Subject: [CFRG] Re: [hpke] Re: [EXTERNAL] [lamps] Re: Re: Re: New labels in draft-irtf-cfrg-concrete-hybrid-kems-01

 

Mixing hex and ASCII labels is certainly inconvenient, however if we ditch the "new" spaceships, LAMPS could use the ASCII version of the labels (with the hex next to it) for everything except XWing.

 

-rohan

 

On Thu, 30 Oct 2025, 12:25 Mike Ounsworth, <[e-mail] <mailto:[e-mail]> > wrote:

Oh, there are typos. Here, with the three "QSF-"s that I missed removed.

 

- id-MLKEM768-RSA2048-SHA3-256
  - Label: "MLKEM768-RSAOAEP2048-SHA3256"

- id-MLKEM768-RSA3072-SHA3-256
  - Label: "`MLKEM768-RSAOAEP3072-SHA3256`"

- id-MLKEM768-RSA4096-SHA3-256
  - Label: "`MLKEM768-RSAOAEP4096-SHA3256`"

- id-MLKEM768-X25519-SHA3-256
  - Label: `0x5C2E2F2F5E5C` (hex)
  
- id-MLKEM768-ECDH-P256-SHA3-256
  - Label: `0x7C2D28292D7C` (hex)

- id-MLKEM768-ECDH-P384-SHA3-256
  - Label: "`MLKEM768-P384-SHA3256`"

- id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256
  - Label: "`MLKEM768-BP256-SHA3256`"
  
- id-MLKEM1024-RSA3072-SHA3-256
  - Label: "`MLKEM1024-RSAOAEP3072-SHA3256`"

- id-MLKEM1024-ECDH-P384-SHA3-256
  - Label: `0x207C202F2D5C` (hex)

- id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256
  - Label: "`MLKEM1024-BP384-SHA3256`"
  
- id-MLKEM1024-X448-SHA3-256
  - Label: "`MLKEM1024-X448-SHA3256`"

- id-MLKEM1024-ECDH-P521-SHA3-256
  - Label: "`MLKEM1024-P521-SHA3256`"



 

On Thu, 30 Oct 2025 at 06:19, Mike Ounsworth <[e-mail] <mailto:[e-mail]> > wrote:

 

DEEP BREATH

(frustrated rant below, but I want to focus on the productive content first)

 

OK

 

If I rev the LAMPS doc today to change the labels to these, so that we have something stable for the hackathon this weekend, then can we all promise that we're done, and this can go into RFC Publication Queue and there will be no more changes to Labels or Construction, or Public Key Encoding or anything that will break the test vectors??


@Richard Barnes <mailto:[e-mail]>  , @Deirdre Connolly <mailto:[e-mail]>  , @Sophie Schmieg <mailto:[e-mail]>  , @Filippo Valsorda <mailto:[e-mail]>  I'm looking for a commitment from you that you respect that LAMPS has run out of time to bikeshed this, that the LAMPS version is past its WGLC and cannot change any more. Yes? Agree?

 

Can someone please double-check that I have not made any typos in the list below?

 

 

- id-MLKEM768-RSA2048-SHA3-256
  - Label: "MLKEM768-RSAOAEP2048-SHA3256"

- id-MLKEM768-RSA3072-SHA3-256
  - Label: "`QSF-MLKEM768-RSAOAEP3072-SHA3256`"

- id-MLKEM768-RSA4096-SHA3-256
  - Label: "`MLKEM768-RSAOAEP4096-SHA3256`"

- id-MLKEM768-X25519-SHA3-256
  - Label: `0x5C2E2F2F5E5C` (hex)
  
- id-MLKEM768-ECDH-P256-SHA3-256
  - Label: `0x7C2D28292D7C` (hex)

- id-MLKEM768-ECDH-P384-SHA3-256
  - Label: "`MLKEM768-P384-SHA3256`"

- id-MLKEM768-ECDH-brainpoolP256r1-SHA3-256
  - Label: "`MLKEM768-BP256-SHA3256`"
  
- id-MLKEM1024-RSA3072-SHA3-256
  - Label: "`MLKEM1024-RSAOAEP3072-SHA3256`"

- id-MLKEM1024-ECDH-P384-SHA3-256
  - Label: `0x207C202F2D5C` (hex)

- id-MLKEM1024-ECDH-brainpoolP384r1-SHA3-256
  - Label: "`QSF-MLKEM1024-BP384-SHA3256`"
  
- id-MLKEM1024-X448-SHA3-256
  - Label: "`MLKEM1024-X448-SHA3256`"

- id-MLKEM1024-ECDH-P521-SHA3-256
  - Label: "`QSF-MLKEM1024-P521-SHA3256`"



 

 

 

<frustrated rant>

As others have said, the actual content of the labels is completely immaterial. What matters is that they are unique and that we converge quickly. And by "quickly", I mean today because LAMPS Composite-KEM finishes its WGLC tomorrow, and we have the hackathon starting Saturday, which is our last good chance to get board interop testing among the LAMPS community.

What frustrates me is that the LAMPS doc delayed a month to wait for the CFRG interim on Sept 29. We went into WGLC on Oct 17 with what I thought we had agreed to at the interim. Richard, you and I have been emailing back and forth privately about interop the entire time. On Oct 20 you guys went and changed your labels to spaceships AND NOBODY SAID ANYTHING TO ME. Not in the private interop email thread, not on the LAMPS WGLC thread. Nothing.

That's the frustrating part here: I am bending over backwards for collaboration here, and you guys seem to be doing whatever you want with no regard for the impact that causes on LAMPS. Remember when you guys forked HPKE WG out of CFRG because CFRG wasn't collaborative enough or moving fast enough for you? Yeah. Same.

</frustrated rant>

 

Carl, actually, the OIDs are not stable; they change every draft when we roll over the prototype OIDs, and they will change again after WGLC when we get real IANA OIDs. In that regard, the HPKE-style ASCII labels are better.

 

 

@Richard Barnes <mailto:[e-mail]>  :

""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."

 

Where is "CK" defined? Who is "we"? I do not see this defined in draft-irtf-cfrg-concrete-hybrid-kems-01. This is the first time I am hearing about a thing with the name "CK", which surprises me since I am writing the proof paper about the RSA variant with Deirdre and Dougles Stebila, and in there we call it "QSH". This is also, to me, rather pedantic since we use the same physical construction for the EC and RSA variants, so whether you call it "CK" or "QSH" or "QSF", it's the same physical construction. The only requirement for the Label is that it's a unique string.

Whatever, in the interest of compromise, I will just remove the framework identifier from the label. If a second MLKEM+EC or MLKEM+RSA gets standardized in the future (which I can't honestly imagine happening), then that can choose new unique label for itself (adding a "1" to the end would be sufficient; we absolutely do not need to bikeshed the name of the framework).

 

 

 

On Wed, 29 Oct 2025 at 20:10, Tushar Patel <[e-mail] <mailto:[e-mail]> > wrote:

One recommendation on names is to make sure that it exceeds the PQC uniqueness space for format preserving encryption SP800-38G without which it could become an issue for inline functionality, captive portal, cert transparency and other similar elements & techniques.

 

The primary technique is to reach the correct HSM partition, load balancing or decryption fast path quickly.

 

On Wed, Oct 29, 2025 at 3:45 PM Samuel Lee (ENS/Crypto) <Samuel.Lee=[e-mail] <mailto:[e-mail]> > wrote:

The technical outcome that I want to see is that the labels to are consistent between lamps-pq-composite-kem (for CMS) and irtf-cfrg-concrete-hybrid-kems (for HPKE) for the ML-KEM + ECC combinations.

I have no strong opinion on what those labels should be provided they are unique per combination, and interoperable between the two.

 

100% agree that exclusively using hex encoding in the drafts is a great way to avoid confusion.

It is trivial for implementors to check they got the labels right with appropriate test vectors and basic interop testing.

 

 

I am not opposed to the labels in either draft-irtf-cfrg-concrete-hybrid-kems-00 or draft-irtf-cfrg-concrete-hybrid-kems-01 as long as we converge quickly.

 

Best,

Sam

  _____  

From: Carl Wallace <[e-mail] <mailto:[e-mail]> >
Sent: 29 October 2025 15:37
To: Sophie Schmieg <sschmieg=[e-mail] <mailto:[e-mail]> >; Richard Barnes <[e-mail] <mailto:[e-mail]> >
Cc: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:[e-mail]> >; CFRG <[e-mail] <mailto:[e-mail]> >


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

 

The OIDs are stable and now that everyone agrees copying pasting hex is fine then the old approach of encoded OIDs should be in play. It’s probably a better option than randomly generated values or counters.

 

From: Sophie Schmieg <sschmieg=[e-mail] <mailto:[e-mail]> >
Date: Wednesday, October 29, 2025 at 5:40 PM
To: Richard Barnes <[e-mail] <mailto:[e-mail]> >
Cc: Mike Ounsworth <Mike.Ounsworth=[e-mail] <mailto:[e-mail]> >, CFRG <[e-mail] <mailto:[e-mail]> >
Subject: [CFRG] Re: [hpke] Re: [EXTERNAL] [lamps] Re: Re: Re: New labels in draft-irtf-cfrg-concrete-hybrid-kems-01

 

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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]> >
Sent: Wednesday, October 29, 2025 3:12:49 p.m.
To: Hale, Britta (CIV) <britta.hale=[e-mail] <mailto:[e-mail]> >
Cc: Mike Ounsworth <[e-mail] <mailto:[e-mail]> >; Eric Rescorla <[e-mail] <mailto:[e-mail]> >; LAMPS WG <[e-mail] <mailto:[e-mail]> >; CFRG <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]> >
Cc: LAMPS WG <[e-mail] <mailto:[e-mail]> >, CFRG <[e-mail] <mailto:[e-mail]> >, "[e-mail] <mailto:[e-mail]> " <[e-mail] <mailto:[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 "\\.//^\\ <file://.//%5e/> " 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]> 

_______________________________________________
hpke mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 




 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto | [e-mail] <mailto:[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] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
CFRG mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 




 

-- 


Sophie Schmieg | Information Security Engineer | ISE Crypto | [e-mail] <mailto:[e-mail]> 

 

_______________________________________________ CFRG mailing list -- [e-mail] <mailto:[e-mail]>  To unsubscribe send an email to [e-mail] <mailto:[e-mail]>  

_______________________________________________
CFRG mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
CFRG mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

_______________________________________________
CFRG mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]>