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

[Deb Cooley <[e-mail]>]

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.

---------------------------------------------