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

[Mike Ounsworth <[e-mail]>]

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



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


> 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 ;)


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


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]



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


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


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]
>