Quick clarification of my last email. The points, briefly: - Publish -08 as-is: ok - Do not merge #25: it reroutes a failed Section 7.2 encapsulation-key check from illegal_parameter to internal_error, away from -08 (and the approved draft-ietf-tls-ecdhe-mlkem). - Minor, non-blocking: probabilistic wording in Section 4.3, the DTLS freshness clarification, and a note that implicit rejection is not an error.
Nick On Thu, Jun 25, 2026 at 12:00 PM Nick Sullivan <[email protected]> wrote: > > To: [email protected] > Subject: Re: WG Last Call: draft-ietf-tls-mlkem-08 > > I support advancing this document as Informational, subject to the > changes below, with the registrations marked Recommended: N. Under RFC > 9847, N records no IETF statement about the suitability of these > groups. > > > Martin opened a seam in the error handling logic with #25, let's > stitch it up. I agree with the approach but would not merge it as-is, > and I suggest three changes. > > First, the client need not repeat the decapsulation-key checks on > every operation when it already has assurance that the key was validly > generated and protected from modification. That is Bas's point. FIPS > 203 Section 7.3 says so directly: "checking of the decapsulation key > need not be performed by the decapsulating party, nor with every > execution of ML-KEM.Decaps. Instead, assurance that this check has > been performed can be acquired through other means." SP 800-227 > Section 3.2 gives the concrete case: a module that generated the key > with KeyGen and stored it against modification. The ciphertext check, > by contrast, is required on every decapsulation. I would replace: > > "Prior to decapsulation, the client MUST perform the decapsulation > input check from Section 7.3 of {{FIPS203}}." > > with: > > "Prior to decapsulation, the client MUST have assurance that the > decapsulation-key checks from Section 7.3 of {{FIPS203}} have been > satisfied. As permitted by that section, this assurance MAY be > obtained by other means. The ciphertext check from Section 7.3 MUST be > performed on every invocation of ML-KEM.Decaps." > > This relaxes only the client's check of its own key, not the server's > Section 7.2 check of the peer's encapsulation key. > > Second, #25 maps three different failures to a single internal_error, > but RFC 8446 and FIPS 203 treat them differently: a peer-input > failure, a local error, and implicit rejection. After the input > checks, ML-KEM.Decaps returns a 32-byte shared secret. A ciphertext > that fails the internal re-encryption comparison takes the > implicit-rejection path and returns a replacement secret, and FIPS 203 > Section 6.3 keeps that implicit-reject flag secret and forbids > returning it in any form, so it is not a Decaps error. RFC 8446 > Section 6.2 reserves internal_error for failures unrelated to the peer > and uses illegal_parameter for a semantically invalid peer value, so a > failed Section 7.2 encapsulation-key check should be > illegal_parameter. I would replace: > > "If ML-KEM checks, encapsulation, or decapsulation fail for any other > reason, the connection MUST be aborted with an internal_error alert." > > with: > > "If the server's encapsulation-key check from Section 7.2 of > {{FIPS203}} fails, the server MUST abort with an illegal_parameter > alert. If an ML-KEM operation returns an explicit error, the > connection MUST be aborted with an internal_error alert. ML-KEM.Decaps > returns a shared secret on every invocation, so its implicit-rejection > path is not an error and produces no alert." > > If implicit rejection leaves the peers with different secrets, the > mismatch is caught by ordinary TLS protected-record processing, not by > a distinct decapsulation error. > > Third, Section 4.3 states agreement as a certainty, where FIPS 203 > states it probabilistically. I would rewrite the sentence rather than > append a qualifier. Replace: > > "The fixed-length shared secret output from the ML-KEM Encaps and > Decaps algorithms over the appropriate keypair and ciphertext results > in the same shared secret shared_secret as its peer, which is inserted > into the TLS 1.3 key schedule in place of the (EC)DHE shared secret, > as shown in {{Section 7.1 of RFC8446bis}}." > > with: > > "For (pk, sk) output by the applicable ML-KEM parameter set's KeyGen > algorithm and (ct, shared_secret) output by Encaps(pk), Decaps(sk, ct) > returns shared_secret with overwhelming probability. Each peer inserts > its resulting shared secret into the TLS 1.3 key schedule in place of > the (EC)DHE shared secret." > > Separately, the freshness language needs a DTLS clarification. The > groups are registered DTLS-OK: Y, and Section 4.2 states without > qualification that ML-KEM ciphertexts MUST NOT be reused. The > requirement is fresh randomness on each ML-KEM.Encaps invocation, per > FIPS 203, not uniqueness of the resulting ciphertext, and RFC 9147 > requires the retransmitted handshake bytes to stay unchanged. I would > clarify: > > "The server MUST invoke ML-KEM.Encaps using fresh randomness for each > distinct TLS or DTLS handshake. Retransmission of an unchanged > handshake message within the same DTLS handshake is not reuse for this > purpose. The original ciphertext MUST be retransmitted, and > ML-KEM.Encaps MUST NOT be invoked again for the retransmission." > > Nick > > On Thu, Jun 25, 2026 at 8:52 AM Bas Westerbaan > <[email protected]> wrote: > > > > > > > > On Thu, Jun 25, 2026 at 7:51 AM Martin Thomson <[email protected]> wrote: > >> > >> I think that this is good to go, with nits. > >> > >> I opened a few pull requests, a pair of which demonstrate that the fuss > >> over this draft did seem to get in the way of doing the work. > >> > >> The question in https://github.com/tlswg/draft-ietf-tls-mlkem/pull/24 and > >> https://github.com/tlswg/draft-ietf-tls-mlkem/pull/25 is perhaps worth > >> discussing. > > > > > > I think neither are necessary. > > > > The expanded decapsulation key caches the hash of the encapsulation key. > > The decapsulation key check is whether that hash is correct. FIPS 203 only > > requires that check if the key is from an untrusted source. In the case of > > TLS, you generate the key yourself earlier, so you know the hash is correct. > > > > > > > >> > >> The draft currently asks the client to run a FIPS validation check, but > >> the server only checks the length of the encapsulation key. That > >> asymmetry seemed wrong to me. > >> > >> I think that the right plan (#25) is to limit checking at the TLS layer > >> (which will be visible through the type of alert) to length only. > >> However, I also opened #24, which includes the FIPS checks at the TLS > >> layer. The reason I think that is less desirable is that, were I to > >> implement this, I would want to pass an opaque byte string to the > >> cryptographic code, which would not report on why it failed. Whereas #24 > >> requires that you have a separate validation API. That validation is easy > >> enough, but not something you want in your TLS code, as there are hash > >> function invocations on the client and modulus checks on the server. > >> > >> There is another option, which is to remove all checks (and any > >> requirement to use `illegal_parameter`) from the spec, but that is not > >> consistent with other TLS usage, which generally checks size. I didn't > >> write that option up. > >> > >> On Thu, Jun 25, 2026, at 01:00, Joseph Salowey via Datatracker wrote: > >> > This message initiates a new Working Group Last Call for > >> > draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key > >> > establishment for TLS 1.3. The main question before the working group > >> > is: "Should the working group publish a document specifying stand alone > >> > ML-KEM?". If there is rough consensus then we will push to refine and > >> > publish the document; otherwise, we will stop discussing the draft and > >> > not progress it. Please respond to this call indicating whether you > >> > support publishing a document specifying a stand alone ML-KEM. Please > >> > refrain from further discussion on this topic as most arguments have > >> > been discussed multiple times. > >> > > >> > Why are we holding this consensus call now? > >> > > >> > Significant developments have occurred both within this document and in > >> > the broader TLS ecosystem to address the concerns raised in the last > >> > WGLC. Therefore, the third consensus call is warranted. We ask the > >> > working group to consider document publication in light of these recent > >> > changes: > >> > > >> > - Promotion of Hybrids in draft-ietf-tls-ecdhe-mlkem: Following a > >> > separate consensus call, the WG agreed to promote the X25519MLKEM768 > >> > hybrid group to Recommended: Y in the IANA registry. Consequently, the > >> > IANA registry will reflect a clear community preference for a hybrid > >> > because Recommended: Y clearly indicates this while the standalone > >> > ML-KEM groups defined in this draft remain Recommended: N. The updated > >> > security considerations in [1] reference the IANA registry to emphasize > >> > this preference. > >> > > >> > - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG > >> > recently reached consensus to explicitly prohibit key share reuse > >> > across connections in TLS 1.3. The new text changes the guidance from > >> > SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding > >> > static key reuse and its associated privacy and forward-secrecy risks > >> > for ML-KEM. > >> > > >> > - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and > >> > hybrid KEM groups in TLS 1.3. This supports other results which show > >> > that KEMs are secure when used in TLS 1.3 and that hybrid groups are > >> > secure even if one of the components is compromised. > >> > > >> > - Liaisons: We received liaison statements from multiple SDOs including > >> > O-RAN[2], IEEE 802.11[4] and from 3GPP[3] expressing support for the > >> > publication of draft-ietf-tls-mlkem as an RFC as they rely on the IETF > >> > to provide a stable normative reference. > >> > > >> > Please note that a third-party IPR disclosure exists [5] against this > >> > document regarding patents related to the underlying ML-KEM algorithm. > >> > This IPR declaration has not changed since the last WGLC. As a > >> > reminder, per BCP 79, the IETF takes no stance on the validity of > >> > patent claims, and the working group may decide to proceed with a > >> > technology despite IPR disclosures if it decides that such use is > >> > warranted. > >> > > >> > Conduct Reminder: Given the heated nature of previous discussions on > >> > this topic, participants are strongly reminded to adhere to the IETF > >> > Code of Conduct (BCP 54) and the TLS WG's Mail List Procedures. Keep > >> > feedback professional, technical, and focused on the document's text. > >> > > >> > This working group last call will end on 2026-07-08. > >> > > >> > Joe and Sean > >> > > >> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/ > >> > [2] https://datatracker.ietf.org/liaison/2198/ > >> > [3] https://datatracker.ietf.org/liaison/2151/ > >> > [4] https://datatracker.ietf.org/liaison/2148/ > >> > [5] > >> > https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-tls-mlkem > >> > > >> > _______________________________________________ > >> > TLS mailing list -- [email protected] > >> > To unsubscribe send an email to [email protected] > >> > >> _______________________________________________ > >> TLS mailing list -- [email protected] > >> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
