[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 20 26-07-08)

Hi John,

On 7/12/26 17:49, John Mattsson wrote:
> David Stainton wrote:
>> No. Let’s not move the discussion away from the draft and from the
>> extremely relevant context of TLS.
> 
> I do not understand why draft-ietf-tls-ecdhe-mlkem, random fields in
> TLS and other IETF protocols, all key transport protocols, and the
> use of various algorithms (ML-KEM, RSA-OAEP, RSA-PSS, RSA-KEM) in
> other IETF protocols would not be considered equally important. I
> think modern RSA algorithms also reveals randomness to the peer
> similar to ML-KEM.
> 
> David Stainton wrote:
>> I am going to update the golang hpqc library and the katzenpost
>> mixnet project will take the defense in depth route.
> 
> That actually seems compatible with the view that securing the
> randomness should be done by the application and not the algorithm.
> Note that just hashing gives a very poor protection against
> compromised RNGs. If possible you should include some additional
> entropy in the hash m = H(m, additional entropy).
> 

Restoring Kyber's hash is safer. The issue is not related to entropy but 
structure. I am concerned that you don't accept this distinction and 
continue to confuse the two issues. This attack strategy works when the 
RNG in question has been fed as much entropy as you'd like to give it.

> Simon Josefsson wrote:
>> If you deviate, such as by taking the defense-in-depth approach to
>> hash m
> 
> Inserting a NIST-approved DRBG such as Hash_DRBG, HMAC_DRBG between
> your potentially compromised entropy source and ML-KEM seems
> conformant to NIST specifications.

This again mistakes the issue at hand for entropy when it is about 
hidden algebraic structure.

Your suggestion is deficient in that the issue is that ML-KEM's `m` is 
not robust against different kinds of failures in _the DRBG itself_ 
including issues such as intentionally hiding structure it the output. 
Hashing `m` is more robust than not hashing it against this exact concern.

I appreciate that you have full confidence in the remaining NIST DRBGs 
and depending on your threat model(s), they may indeed be sufficient.

I am confident that they are not sufficient in all threat models. I 
would rather use a better fast-key erasure design in any case.

Kind regards,
Jacob Appelbaum

> 
> Cheers, John Preuß Mattsson
> 
> From: David Stainton <[email protected]> Date: Sunday, 12 July
> 2026 at 16:03 To: Kris Kwiatkowski <[email protected]> Cc:
> [email protected] <[email protected]> Subject: [TLS] Re: WG Last Call: draft-
> ietf-tls-mlkem-08 (Ends 2026-07-08)
> 
> Hi Kris, No. Let’s not move the discussion away from the draft and 
> from the extremely relevant context of TLS.
> 
> Restoring the hash is reasonable and NIST’s removal wasn’t well 
> motivated or justified, their silence to reasonable questions now is 
> suspicious when we consider the relevant history.
> 
> There may be better designs but they will only slow down deployment. 
> The best course of action is restoring the hash over m. It lasted
> for three rounds without a security issue being found by NIST or
> NSA.
> 
> I am going to update the golang hpqc library and the katzenpost
> mixnet project will take the defense in depth route.
> 
> David Stainton Founder and core developer, Katzenpost post quantum
> mixnet
> 
> On Sun, Jul 12, 2026 at 1:08 PM Kris Kwiatkowski
> <[email protected]> wrote:
>> 
>> 
>> On 12/07/2026 09:06, John Mattsson wrote:
>> 
>> 
>> Regarding Jakob Appelbaum's suggested text, I agree that wording
>> along the lines of "the m value is recoverable by the
>> decapsulating peer" should be added to draft-ietf-tls-ecdhe-mlkem,
>> draft-ietf-tls-mlkem, and likely to future IETF KEM specifications
>> as well.
>> 
>> 
>> I agree with the points below, including that the broader CSPRNG
>> guidance discussion belongs in a wider IETF context such as an
>> RFC4086bis effort.
>> 
>> On where the suggested text about 'm' being recoverable by the
>> decapsulating peer should go: I think draft-sfluhrer-cfrg-ml-kem-
>> security-considerations is the proper home for it, rather than the
>> documents that merely define code points for TLS. The TLS drafts
>> could then simply reference it. Duplicating ML-KEM security
>> considerations across draft-ietf-tls-ecdhe-mlkem, draft-ietf-tls-
>> mlkem, and every future KEM code point document seems fragile, and
>> a single CFRG document keeps the guidance consistent. This follows
>> the same logic as your RFC4086bis suggestion: put the guidance
>> where it can be referenced, not in each protocol-specific draft.
>> 
>> For the same reason, the discussion itself belongs in CFRG, where
>> it would get review from the crowd focused on cryptographic
>> mechanisms.
>> 
>> Cheers, Kris
>> 
>> _______________________________________________ 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]