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

[Deb Cooley <[e-mail]>]

Yeah, 37 years of reading specs means I'm pedantic.  You are welcome.

I will note that it is indeed 5 July.  So, I'm good, no?

Comments inline w/ [DC]. since these are tiny little things to fix (up to
you whether you do it before the submission deadline tomorrow or not), I
will put the draft into IETF Last Call.  It will likely be a 3 week call,
because of the proximity to Vienna.

Deb

On Mon, Jun 29, 2026 at 12:15 AM Mike Ounsworth <[e-mail]>
wrote:

> Deb,
>
> Thanks for the thorough review! You caught a bunch of little
> cross-referencing mistakes that I'm surprised made it this far, considering
> how many eyes have been on this document. Bravo!
>
> Changes made in -17.
>
> Enjoy your vacation week. If I see you review this again before July 5,
> I'll _tisk tisk_ at you!
>
>
> Some responses:
>
> > 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?
>
> Yep. You're not wrong. I don't fully get this either. Certain people (whom
> I won't name in public) insisted on RSA combinations I think because they
> never got an EC module validated. I am 99.9% sure that what they wanted was
> PKCS#1v1.5 encryption, but since that fell off the FIPS allowed list Dec
> 31, 2023 [1], we're not giving it to them. Had someone raised this
> objection during WG, we could have pushed harder at removing the RSA's
> entirely and that would have made lots of IETFers happy (particularly the
> CFRG crowd), but alas, at this stage, as you say, rhetorical.
>
> [1]: FIPS 140-3 IG p. 177.
>
> https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf
>
> [DC] this is fine, obviously.

>
>
> > 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?
>
> This is editorially annoying because I can't do a real cross-reference
> from within a code block.
> Good suggestion to add a proper cross-ref outside the code block.
>
> [DC] that works

>
> > 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.]
>
> Sharp eyes! This was an unintentional, inconsistent, mess.
> RFC 9180 (CFRG's HPKE) uses "encap()" while FIPS 203 uses "encaps()", so
> it became inconsistent depending on where I sourced stuff from -- most of
> the doc aligns with FIPS 203, but the DHKEM stuff is straight out of 9180.
> So it's a question of whether we want to align with NIST or CFRG.
> I've changed them all to "encaps() / decaps()" to match NIST ;)
>
> [DC]  Check the definitions, both encaps and decaps mentions RFC 9180 and
NIST, but I think it is a tiny bit incorrect at the moment.  I'd make it '
Note: this specification uses Encap() *Encaps()* to conform to [FIPS.203],
but [RFC9180] uses Encap()'

>
> > 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.]
>
> Good point. I knocked that down to a much simpler sentence: "ensure that
> the security considerations of all component algorithms have been adhered
> to"
>

[DC]  I would re-add RFC 9935...  obviously for the ML-KEM part of it.

>
> The following have been moved from the Informative to the Normative list
> because they contain security analysis that is used normatively:
>
>    - [X-Wing]
>    - [Starhunters]
>    - [KWW2026]
>
>
[DC] good.  For the ref to the cfrg hybrid draft.  Add 'for example, see'
at the beginning of that sentence (Section 9.2.1.1).

[DC] Should there be a new heading after the 'mini glossary'?  Maybe
Section 9.2.1.2?  And you will need a title...

>
>
> > 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]
>
> I know this is common practice, so I'll remove that clause.
> But I will quibble back that the purists will say that you really
> shouldn't do this for two reasons: 1) because re-using the same key for
> multiple certs can make Revocation: Key Compromise tricky, especially if
> you've reused that key across PKIs that don't share revocation info, and 2)
> often cross-protocol attacks have only been analyzed for specific pairs of
> protocols; like it's ok to use the same key for signing S/MIME and as a TLS
> client cert, but reusing the same key for other protocols could have
> unknown or unstudied consequences. So best practice would be fresh keygen
> per cert and it just dodges the whole ball of potential issues.
>
> [DC]  looks good.

>
> > Section 10.1: FIPS Certification
>
> I agree that this is all completely non-authoritative, but also these
> considerations weighed heavily in why the combiner has exactly the shape
> that it does, and various other points that differentiate this spec from
> the parallel CFRG work (separate vs shared-seed keygens, for example).
> But I have demoted it to an appendix so that it is not part of the body of
> the document.
>

[DC] this works.

[DC]  in the nits from 10.5, 'particular' , is still spelled incorrectly.
Ha!

>
>
> Thanks for the very thorough review!
>
> -Mike
> On behalf of the composite authors.
>
>
> On Mon, 22 Jun 2026 at 14:51, Deb Cooley <[e-mail]> wrote:
>
>> The reason to not do that is if you need to reference them normatively.
>> Both are still in CFRG as rg drafts.  It would be a publication risk.
>>
>> The other references are published papers.  If they are defined in those,
>> just point to them (and maybe you did already).
>>
>> Deb
>>
>> On Mon, Jun 22, 2026 at 9:56 AM Mike Ounsworth <[e-mail]> wrote:
>>
>>> Good suggestion David.
>>>
>>> -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 8:20 AM, David Benjamin <
>>> [e-mail]> wrote:
>>>
>>> On Mon, Jun 22, 2026, 09:04 Mike Ounsworth <mike=
>>> [e-mail]> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Would it help to cite draft-irtf-cfrg-hybrid-kems and
>>> draft-irtf-cfrg-concrete-hybrid-kems for these? That may a more canonical
>>> reference at this point. More relevantly, they have different,
>>> non-Star-Wars names now. :-)
>>>
>>> (Hopefully I'm not stepping into a mess here. Feel free to ignore this
>>> if I am. I did not follow all of what led to this constellation of
>>> documents, so I don't know if there's some important reason this draft did
>>> not settle into citing the CFRG ones.)
>>>
>>> > 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.
>>>>
>>>> ---------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Spasm mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>>
>>> _______________________________________________
>> Spasm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>