Return-Path: X-Original-To: spasm@mail2.ietf.org Delivered-To: spasm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id EE07910990290 for ; Sun, 28 Jun 2026 21:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782706543; bh=EqdbmaNTSPMjuoXF6rJewC33VWoDD27XDq4EqlyaqME=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=koqY46VuZXEDBvFV8X1vjo77DOKsnc2Gn6gpQByPT0C/8ThgNEweLIzOmvCZO/YTe wclL+NMnpcFUgj10W0eUVq3hAHezSa0kzLfZkPkKTp9qFu1QsppKKE936zbG138jKa IjcrvAscVNeCKOZXN45iNmdSC2CDNtUAZqRCxaM8= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BkBFw4DF_Yo for ; Sun, 28 Jun 2026 21:15:42 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 4B00510990230 for ; Sun, 28 Jun 2026 21:15:16 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-698562f10e7so1582666a12.0 for ; Sun, 28 Jun 2026 21:15:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782706515; cv=none; d=google.com; s=arc-20260327; b=hgLyfVlNspQhOyp+gVQo/cfm1R5i8SQmoHbqfQX6o4LZ9q4jqfmtLnCQr6DBVoTCuh 4zs/II54iDi7O5h+XdErXI5zP++o3rg58Wz07GQYkPWE13EgvMHrjnsy/MzynVu7rNhy JeuPBoWlaAHDDHFdhqZxpqyUYPva5K0diFj+burpTx/63HKWRDwwSa2yQfdHscnKLWXN LxXawUL8SLvl+qB8i0H4Lu4xnPh/jM/bmQgW+BjiJvUhGOsmS/XVoQhB6+aZEeAQ39Li itQJUJonlVuDBhWURQC78+UUr75RANpnkw87cltYeir37jF+mSI1/sn+zYy68hRMcu4P NXfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=Znghm/8FtrbxvF394q3eTQIDLiGiNrAupbu2yJVb3SY=; fh=I4o2rBl/OB6naQljzYpljetNwyc9d8FkA6bq8mEooMo=; b=ECh4FN9c1kFYEvV2TLGx4grLbseHMr2w5kmiiwgl1Md1J55UMl31dtb3Lsv0wZroTp 397diJh7epZBY7d0OiVyamK455lGHq5OtXgqWJb/2V48idzc6TNjW6Y1Yva19KONCgWq hBEZjdFadwUBR5GuCBKrb3G1fxnLQR5oEroNJdRWdhHFfwHRs5DS3X/hG8EE6krZ35Ao QUUFrwL5BTlxEojQk/CYHxvNNB6fAFoDtjrrNBf5S0uVFAWOgC8nb4OqSjooQyBNclgr WaUa3lfvvFQFwqvuwWUDX3ftlrr1RWCkHoHWQLQ48Yh4H2Rni1XOnkVGwL8bkoEswoce l5JA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782706515; x=1783311315; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Znghm/8FtrbxvF394q3eTQIDLiGiNrAupbu2yJVb3SY=; b=P84tPs+/kC14q9uB2Ep1P29VHTqktT6FsgyjndKBZ+ZlGwNftxFTzb324sE8DKCVHg o2mexUkXdzJV1mrGTZlb29WefGeDk9RXa3XbTjKQ9hGmN8phh0eW5ZIidbJXLGmw9pqD ht+Q28ekwElCOt9ThCiyxiXzm4JtAp/fvWwum/X5kCLgs6oYFlbo8FYju8rXVL9x68vK u0KXeBB2FHkM2IFLjE/lVlZ9OPHEur7xZX4fjA9lXvRBDYslS9i/gmtvgN5cdmtQEZNp aVDO0AJdIK8MdHjcqU398terPcnmpw+w3qX5tL2lj8zYyzIAWxmk+wWIp20DysSBPVCZ Do7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782706515; x=1783311315; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Znghm/8FtrbxvF394q3eTQIDLiGiNrAupbu2yJVb3SY=; b=tEjXgYmtu+CJxH4HjSLLvgmrFaXW55IKMQPbbYSYAFQ5st+zeuRlx0Aqmh2NzEEmwJ Qr19mCdq2t7KLmMi1FFDOaHhuJer9tWaNfkXTam6/dU0URfiwf6qXdh/oLc8cHH+IIUE H0C5x+Ay8SmlKyKJj0gkQwmYhJ9zNtHVKNPhIDRQLPfNU6DaA7uLEfRha7VOsVbVgiM4 97u7y2ZZL7lqBbAA+R/vbbogS1aTjHJNXZUKgjK9hgilvT7fBwgj9lNWDt+cDmq1hs3E IUN4L5DZA1zwVZMvb927NlPGPvf2JIg7YI54TwKDxFyRHPqphDkn+PcbbwWosuekSkIA IYHA== X-Forwarded-Encrypted: i=1; AHgh+RobdaP3tUu6wBLHvKAFGQ0EM8e5mMU7R58e7g5C+bcJ2dsOINFIX8qk+X96gp9SAqK3RaO9yw==@ietf.org X-Gm-Message-State: AOJu0Yz45tjH3L/sjHUoWgLrfeV0X/IQdK7byCQKgI0DJQgi66mCuEt/ HY6JWo/mpG13IkO10UNiEOt1J+lIBoK3aQCU3Wsj1BtdLYYpSL8uLktaktjMRQDMxWfUyDFgjjC vyBg84jJwpHvAo3b/C3rI0G3qAgJglqc= X-Gm-Gg: AfdE7ckIFpoWT9EVFdr7Abi2//u3rkmRCRqSxXWmhwQ3YAB9Ku3Mz7XE4/eeza+smIK ZPY2XrmEhlqbrzcWmG3ujJ3zV78s1p1lYM4ixiMLXHKIYzuNCDkl0KVZmWvtdCSpft1CFz4Gsjx z5Ba2xYKDW6L6+8mQGdiMwA2qyFLYHC/Q+k8cj3L6EcyCIst5Ji9s86mKUpwBRWwT5CmVfGSip8 QD/3Gapt80oOFigl6DmzcxQx0OZiJHWRp2O8F60WOKi5Vl6RsxFM0RdAcSrIiHLTg8H9hlHAXSD 04IKCzKCYA== X-Received: by 2002:a05:6402:51c8:b0:698:480b:2dd1 with SMTP id 4fb4d7f45d1cf-698480b2f66mr2280833a12.13.1782706514897; Sun, 28 Jun 2026 21:15:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike Ounsworth Date: Sun, 28 Jun 2026 23:15:03 -0500 X-Gm-Features: AVVi8CcaDhF6HWSCTU-oGlVDDd83Xmj_oKKpIWZM6l6u7KRw8mvP8LBDDljUeDo Message-ID: To: Deb Cooley Content-Type: multipart/alternative; boundary="0000000000008f306706555cb455" Message-ID-Hash: 3ITWVQAD2TQWMJJFBSWVCWHPKI5M25VU X-Message-ID-Hash: 3ITWVQAD2TQWMJJFBSWVCWHPKI5M25VU X-MailFrom: ounsworth@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spasm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Mike Ounsworth , David Benjamin , draft-ietf-lamps-pq-composite-kem.authors@ietf.org, LAMPS Chairs , LAMPS WG X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Blamps=5D_Re=3A_AD_comments_on_draft-ietf-lamps-pq-composite-kem?= List-Id: This is the mail list for the LAMPS Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000008f306706555cb455 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-p= rogram/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 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=E2=80=AFAM Mike Ounsworth 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.=E2=80=9D -- N= iels Bohr* >> >> On Monday, June 22nd, 2026 at 8:20 AM, David Benjamin < >> davidben@chromium.org> wrote: >> >> On Mon, Jun 22, 2026, 09:04 Mike Ounsworth > 40ounsworth.ca@dmarc.ietf.org> 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 correct= ly. >>> 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 decry= pt. >>> Is that correct, or am I missing something with the concept of 'implici= tly >>> rejecting'. >>> >>> Yes, that's exactly right, and a very good observation. You know how th= e >>> 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 sampl= ing >>> value; basically it's a full-strength 32-byte nonce that's only used wh= en >>> 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 =F0=9F=98=86 >>> 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 pape= r >>> 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 the= m. >>> >> >> Would it help to cite draft-irtf-cfrg-hybrid-kems and >> draft-irtf-cfrg-concrete-hybrid-kems for these? That may a more canonica= l >> 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 i= f >> I am. I did not follow all of what led to this constellation of document= s, >> so I don't know if there's some important reason this draft did not sett= le >> 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 th= at >>> 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 th= e >>> words "A common seed for both the PQ and Trad components is the only >>> sensible and secure thing that a reasonable implementation would ever d= o >>> 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-ope= n. >>> >>> > Section 9.3, para 2: PKI quibble: One does not normally change the ke= y >>> when one renews a certificate. >>> >>> The purists would argue that keygens are cheap and all certs should hav= e >>> unique keys =F0=9F=98=89 >>> >>> -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.=E2=80=9D -- = Niels Bohr* >>> >>> On Monday, June 22nd, 2026 at 7:06 AM, Deb Cooley >>> 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 Jul= y. >>> >>> 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 l= ike >>> (while Diffie-Hellman algorithms will be vulnerable, they are not use i= n >>> 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 vic= e >>> one of the ECDH options? Of all the options to eliminate, this seems li= ke >>> 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 wor= d 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 l= ike >>> 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 t= he >>> 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 correct= ly. >>> 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 decry= pt. >>> Is that correct, or am I missing something with the concept of 'implici= tly >>> 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 20= 3. >>> 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 describ= es >>> 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 b= e >>> normative. This draft leans on that work to show they are secure (at le= ast >>> in this way - sorry, retired security evaluator here). It should be fin= e >>> 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 th= at >>> XWING proposes this. This, of course, is catastrophic when one algorith= m is >>> compromised, as it leads immediately to both algorithms being compromis= ed. >>> 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 o= wn >>> 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 nee= d 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 -- spasm@ietf.org >>> To unsubscribe send an email to spasm-leave@ietf.org >>> >>> >> _______________________________________________ > Spasm mailing list -- spasm@ietf.org > To unsubscribe send an email to spasm-leave@ietf.org > --0000000000008f306706555cb455 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Deb,

<= /div>
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 eye= s have been on this document. Bravo!

Changes made in -17.

Enjoy your vacation week. If I see you review this a= gain before July 5, I'll _tisk tisk_ at you!


Some responses:

>=C2=A0Section 2.1, last para: Largely rhetorical, but... If RSA OAEP has limited=20 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=20 vice one of the ECDH options?

Yep. You're not wrong. I don't fully get this either. Certain people (w= hom I won't name in public) insisted on RSA combinations I think because the= y 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=20 list Dec 31, 2023 [1], we're not giving it to them. Had someone raised= =20 this objection during WG, we could have pushed harder at removing the=20 RSA's entirely and that would have made lots of IETFers happy=20 (particularly the CFRG crowd), but alas, at this stage, as you say,=20 rhetorical.

[1]: = FIPS 140-3 IG p. 177.



>=C2=A0Section 3.2 and 3.3, Label: Can we be more explicit for 'see section on KEM= =20 Combiner Labels below', like what section? Maybe add a note below like= =20 is done for the actual process?

This is editorially annoying because I can't do a real c= ross-reference from within a code block.
Good suggestion to add a proper cross-ref out= side the code block.


&g= t;=C2=A0Section 3.5, para 2: Can you check to be sure you have your Encap/Encaps,=20 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= =20 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=20 the doc aligns with FIPS 203, but the DHKEM stuff is straight out of=20 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 ;)


>=C2=A0Section 9, para 1: Either phrase the ref to=20 draft-fluhrer-cfrg-ml-kem-security-considerations like RFC 9935 did, or=20 perhaps remove it altogether, since RFC 9935 does make the ref already.=20 [because this is an individual draft, it has to be informational.]

Good point. I knocked th= at down to a much simpler sentence: "ensure that the security co= nsiderations of all component algorithms have been adhered to"<= /div>

<= div style=3D"font-family:Arial,sans-serif;font-size:14px">
The following have been moved from the Informative to the Normative list=20 because they contain security analysis that is used normatively:
  • [X-Wing]=
  • [Starhunters]
  • [KWW2026]


&= gt;=C2=A0Section 9.3, para 2: PKI quibble: One does not normally change the key when=20 one renews a certificate. Do you mean 'rekey a certificate'? [yes= ,=20 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=20 certs can make Revocation: Key Compromise tricky, especially if you've= =20 reused that key across PKIs that don't share revocation info, and 2)=20 often cross-protocol attacks have only been analyzed for specific pairs=20 of protocols; like it's ok to use the same key for signing S/MIME and a= s a TLS client cert, but reusing the same key for other protocols could=20 have unknown or unstudied consequences. So best practice would be fresh=20 keygen per cert and it just dodges the whole ball of potential issues.


= > Section 10.1:=C2=A0FIPS Certification

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


=
Thanks for= the very thorough review!

-Mike
On behalf of the composite authors.


On Mon, 22 Jun 2026 at 14:51, Deb Cooley &= lt;debcooley1@gmail.com> wro= te:
The reason to not do that is if you need to reference them normat= ively.=C2=A0 Both are still in CFRG as rg drafts.=C2=A0 It would be a publi= cation risk.

The other references are published pa= pers.=C2=A0 If they are defined in those, just point to them (and maybe you= did already).

Deb

On Mon, Jun 22, 2026 at 9:= 56=E2=80=AFAM Mike Ounsworth <mike@ounsworth.ca> wrote:
Good suggestion David.

-Mike=C2=A0

"Knowing is a barrier which prevents learni= ng" -- Frank Herbert, Dune.

"An expert is a person who has f= ound out by his own painful experience all the mistakes that one can make i= n a very narrow field.=E2=80=9D -- Niels Bohr
=20
=20

On Monday, June 22nd, 2026 at 8:20 AM, David Benjamin <davidben@chromium.org> wrote:
On Mon, Jun 22, 2026, 09:04 Mike Ounsworth= <mike=3D40ounsworth.ca@dmarc.ietf.org&= gt; wrote:
Hi Deb,

Thanks for the thorough review= .

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


You asked:

> Section 3.5, para 1: Dumb AD que= stion: 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 o= f 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 actua= l ML-KEM seed that you use to run the keygen is also 32 bytes, and then the= re's another 32 byte seed called the rejection sampling value; basicall= y it's a full-strength 32-byte nonce that's only used when you impl= icitly 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 acrony= ms on first use: QSF framework? LEAK-BIND-K, and PK-CT.

That one is going to be tricky beca= use none of those specific examples are acronyms. Well, technically Deirdre= will say that "QSF" (which is defined in the X-Wing paper) stand= s for Quantum Superiority Fighter (a rather heavy-handed star wars joke), b= ut I'm not sure that spelling it out will increase readability and unde= rstanding -- the X-Wing paper never spells it out; I only know because I kn= ow Deirdre =F0=9F=98=86
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-cfr= g-hybrid-kems and draft-irtf-cfrg-concrete-hybrid-kems for these? That may = a more canonical reference at this point. More relevantly, they have differ= ent, non-Star-Wars names now. :-)

(Hopefully I'm not stepping into a mess here. Feel free to ig= nore this if I am. I did not follow all of what led to this constellation o= f 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 w= ords 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 t= o 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 reasona= ble 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 o= f 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 key= gens are cheap and all certs should have unique keys =F0=9F=98=89

-Mike

"Knowing is a barrier which prevents learning&qu= ot; -- 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 v= ery narrow field.=E2=80=9D -- Niels Bohr

On Monday, June 22nd, 2026 at 7:06 AM, Deb Cooley <debcooley1@gmail.com> 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
<= br>
--------------------------------------------
Section 1, = para 1: DH is mentioned in this paragraph (clearly it will vulnerable), bu= t 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 specificat= ion as a component of a composite algorithm). I'll take shorter, if yo= u 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 R= SA-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&#= 39;t noticed it - in fact, if it has, tell me.]

Section 2.1, last pa= ra: Largely rhetorical, but... If RSA OAEP has limited deployment, then ho= w 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 o= ne 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 usef= ul.

Section 2.2, DH: Maybe clarify that this is just ECDH.

S= ection 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 spe= cification? Possibly ref Step 4, which has the note already.

Sectio= n 3.5, para 1: Dumb AD question: If a mangled ciphertext going into ML-KE= M.Decaps() returns a pseudo-random shared secret, the result will be a SS w= hich doesn't match the other end, resulting in two different traffic ke= ys, 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 p= roper strength encryption of traffic, even if that traffic won't decryp= t. Is that correct, or am I missing something with the concept of 'imp= licitly rejecting'.

Section 3.5, para 2: Can you check to be su= re 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 F= IPS 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-secu= rity-considerations like RFC 9935 did, or perhaps remove it altogether, sin= ce RFC 9935 does make the ref already. [because this is an individual draf= t, it has to be informational.]

Section 9.1, last sentence: Make th= is more 'guidance', perhaps 'More guidance on FIPS certificatio= n...'. [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 framewo= rk? 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? Re= cognizing that the 'first KEM' is ML-KEM... Can we make this two s= entences, 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 an= d 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 securi= ty evaluator here). It should be fine since they are published.

Sect= ion 9.3: I did expect to see some words on the idea of 'reusing' p= rivate keys for both the PQ and trad algorithms, or for using the same hunk= s of random to generate both private keys. Weirdly, I'm guessing that = XWING proposes this. This, of course, is catastrophic when one algorithm i= s compromised, as it leads immediately to both algorithms being compromised= . What am I missing?

Section 9.3, para 2: PKI quibble: One does n= ot 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 u= se'. Where else are CA requirements discussed? Almost an update to RF= C 3647... I think at a minimum, it deserves its own section head. Opinion= s?

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 modif= ied 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, wh= ere does the parenthetical '(for example, getting the RSA component fro= m 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 ha= s been published - RFC 9935
I didn't check -3 lines longer than= 72 characters.

----------------------------------= -----------

_______________________________________________
Spasm mailing list -- spasm@ietf.org
To unsubscribe send an email to spasm-leave@ietf.org

_______________________________________________
Spasm mailing list -- s= pasm@ietf.org
To unsubscribe send an email to spasm-leave@ietf.org
--0000000000008f306706555cb455--