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

[Deb Cooley <[e-mail]>]

This all looks good.

TYVM

Deb


On Wed, Jul 8, 2026 at 1:33 PM Mike Ounsworth <[e-mail]> wrote:

> Thanks again for the eagle-eyes, Deb. Changes made on github. I'll push to
> Datatracker when the freeze is lifted, or when we clear IESG review, or you
> know, when I remember haha.
>
> I'll commend back on two points:
>
> > [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()'
>
> Oops. That was a sloppy edit. Good catch. It should read:
>
> """
> Note: this specification uses `Encaps()` to conform to
>       [FIPS.203], while {{RFC9180}} uses `Encap()`.
> ...
> Note: this specification uses `Decaps()` to match [FIPS.203],
>       while {{RFC9180}} uses `Decap()`.
> """
>
>
>
> 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.
>
> I am going to choose to not do this because this draft uses 6 component
> algorithms and there is nothing particularly special about ML-KEM in this
> regard and I don't want this sentence to turn into a bibliography lol.
>
>
>
>
> -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 Sunday, July 5th, 2026 at 2:15 PM, Deb Cooley <[e-mail]>
> wrote:
>
> 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]
>>>
>>
>