[lamps] Re: AD comments on draft-ietf-lamps-pq-composite-kem

[Mike Ounsworth <[e-mail]>]

Hi Deb,

Thanks for the thorough review.

These are all easy to address. I'll get a new version up, maybe even today.

You asked:

> Section 3.5, para 1: Dumb AD question: If a mangled ciphertext going into ML-KEM.Decaps() returns a pseudo-random shared secret, the result will be a SS which doesn't match the other end, resulting in two different traffic keys, resulting in encrypted traffic that won't decrypt correctly. I'm guessing that while the SS is wrong, it is at least random, leading to proper strength encryption of traffic, even if that traffic won't decrypt. Is that correct, or am I missing something with the concept of 'implicitly rejecting'.

Yes, that's exactly right, and a very good observation. You know how the ML-DSA seed is 32 bytes but the ML-KEM seed is 64 bytes? Well it turns out that the actual ML-KEM seed that you use to run the keygen is also 32 bytes, and then there's another 32 byte seed called the rejection sampling value; basically it's a full-strength 32-byte nonce that's only used when you implicitly reject, hashed together with the ciphertext, so that you get a full-strength, unique-per-ciphertext bogus shared secret.

> Section 9.2.1, para 3: Spell out acronyms on first use: QSF framework? LEAK-BIND-K, and PK-CT.

That one is going to be tricky because none of those specific examples are acronyms. Well, technically Deirdre will say that "QSF" (which is defined in the X-Wing paper) stands for Quantum Superiority Fighter (a rather heavy-handed star wars joke), but I'm not sure that spelling it out will increase readability and understanding -- the X-Wing paper never spells it out; I only know because I know Deirdre 😆
Similarly LEAK-BIND-K, I suppose is an acronym for "LEAK-BIND-KEY", and PK-CT is "PublicKey-Ciphertext", but really, Cas Cramer's Bindings paper just treats them as labels.
None of those are acronyms, and they have long academic definitions in their respective papers, but I could do a better job of introducing them.

> Section 9.3: I did expect to see some words on the idea of 'reusing' private keys for both the PQ and trad algorithms, or for using the same hunks of random to generate both private keys. Weirdly, I'm guessing that XWING proposes this.

What words exactly do you want to see? Deirdre and Richard Barnes and the rest of the HPKE community pushed hard for this draft to contain the words "A common seed for both the PQ and Trad components is the only sensible and secure thing that a reasonable implementation would ever do because of LEAK-BIND-K and MAL-BIND-K".
I'm guessing those are not the words you had in mind?
This was one of those massive cans of debate that I'd rather not re-open.

> Section 9.3, para 2: PKI quibble: One does not normally change the key when one renews a certificate.

The purists would argue that keygens are cheap and all certs should have unique keys 😉

-Mike

"Knowing is a barrier which prevents learning" -- Frank Herbert, Dune.

"An expert is a person who has found out by his own painful experience all the mistakes that one can make in a very narrow field.” -- Niels Bohr

On Monday, June 22nd, 2026 at 7:06 AM, Deb Cooley <[e-mail]> wrote:

> Thanks for the work on this draft. Here are my comments. If it makes sense to chat about these, I'm available through 25 June or after 5 July.
>
> Deb
>
> --------------------------------------------
> Section 1, para 1: DH is mentioned in this paragraph (clearly it will vulnerable), but it isn't used as a component of a composite algorithm (good). Can we add a tiny short parenthetical stating that? Something like (while Diffie-Hellman algorithms will be vulnerable, they are not use in this specification as a component of a composite algorithm). I'll take shorter, if you can do it. I'd also be happy to have this in section 2.2 where DHKEM is used, but means EC DH KEM.
>
> Section 1, para 1 and 3: Spell out RSA-OAEP and ECDH. And if you ever use DH, add '(DH)' to para 1.
>
> Section 2, Decap: 'distinguished error value'? What makes it distinguished? [apologies if this has been used in the past and I haven't noticed it - in fact, if it has, tell me.]
>
> Section 2.1, last para: Largely rhetorical, but... If RSA OAEP has limited deployment, then how does it satisfy paras 4&5 of Section 1? If one were making a change from PKCS1v1.5, why would one move to RSA OAEP vice one of the ECDH options? Of all the options to eliminate, this seems like the obvious. Now, if one suspects that an RSA-type scheme will 'stand longer', that would change an enterprise's plans? Like I said, this is largely rhetorical, but if there is easy rationale at hand, maybe a word or two might be useful.
>
> Section 2.2, DH: Maybe clarify that this is just ECDH.
>
> Section 3.2 and 3.3, Label: Can we be more explicit for 'see section on KEM Combiner Labels below', like what section? Maybe add a note below like is done for the actual process?
>
> Section 3.3, tradPK: 'see the Decapsulation Requires the Public Key section' where? In this specification? Possibly ref Step 4, which has the note already.
>
> Section 3.5, para 1: Dumb AD question: If a mangled ciphertext going into ML-KEM.Decaps() returns a pseudo-random shared secret, the result will be a SS which doesn't match the other end, resulting in two different traffic keys, resulting in encrypted traffic that won't decrypt correctly. I'm guessing that while the SS is wrong, it is at least random, leading to proper strength encryption of traffic, even if that traffic won't decrypt. Is that correct, or am I missing something with the concept of 'implicitly rejecting'.
>
> Section 3.5, para 2: Can you check to be sure you have your Encap/Encaps, Decap/Decaps all correct. [BTW, I find it a tiny bit confusing to see a one letter difference between this draft and FIPS 203. I'm assuming there has to be a good reason for that.]
>
> Section 9, para 1: Either phrase the ref to draft-fluhrer-cfrg-ml-kem-security-considerations like RFC 9935 did, or perhaps remove it altogether, since RFC 9935 does make the ref already. [because this is an individual draft, it has to be informational.]
>
> Section 9.1, last sentence: Make this more 'guidance', perhaps 'More guidance on FIPS certification...'. [because we cannot be authoritative here.]
>
> Section 9.2.1, para 2: 'FO transform'? spell out FO the first time, please.
>
> Section 9.2.1, para 3: Spell out acronyms on first use: QSF framework? LEAK-BIND-K, and PK-CT.
>
> Section 9.2.1, last para: As opposed to this draft that only binds the pk and ct of the traditional algorithm? Recognizing that the 'first KEM' is ML-KEM... Can we make this two sentences, and add a phrase that describes what this draft proposes vs. the 'more cautious approach'?
>
> Section 9.2.1 and 9.2.2: X-Wing and the other analysis papers need to be normative. This draft leans on that work to show they are secure (at least in this way - sorry, retired security evaluator here). It should be fine since they are published.
>
> Section 9.3: I did expect to see some words on the idea of 'reusing' private keys for both the PQ and trad algorithms, or for using the same hunks of random to generate both private keys. Weirdly, I'm guessing that XWING proposes this. This, of course, is catastrophic when one algorithm is compromised, as it leads immediately to both algorithms being compromised. What am I missing?
>
> Section 9.3, para 2: PKI quibble: One does not normally change the key when one renews a certificate. Do you mean 'rekey a certificate'? [yes, this is picky]
>
> Section 9.3, last para: This is a CA requirement, buried in a specification on 'how to use'. Where else are CA requirements discussed? Almost an update to RFC 3647... I think at a minimum, it deserves its own section head. Opinions?
>
> Section 10.1: There is a lot here, which is not authoritative. Do we really need all of this? I almost want the order of Section 10 modified to put this last or make it an appendix. Or put it last, and point to an appendix...
>
> Appendix D.1: This is all about MLKEM and X25519, where does the parenthetical '(for example, getting the RSA component from an existing smartcard)' come into play? To make it at all applicable, maybe you need to make it a X25519 component stored on a smartcard?
>
> Nits:
> 10.5: s/expenent/exponent. s/particilar/particular, s/variation/variations?
>
> From idnits (just here for completeness - they have been addressed):
> removed - claims that FIPS 204 is in the references but never referenced. Seems odd...
> corrected - the kyber certs draft has been published - RFC 9935
>
> I didn't check -3 lines longer than 72 characters.
>
> ---------------------------------------------