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

Hi Nick,

I agree that making this document depend on a CFRG publication would be 
overkill.

That said, I think this discussion is worthwhile. While it is certainly 
relevant to TLS, it is not specific to TLS; other protocols using ML-KEM 
face the same considerations. That's why I thought it would be 
appropriate to capture this guidance in a more general document, such as 
draft-sfluhrer-cfrg-ml-kem-security-considerations (or any other, that 
one just looks like right place).

Probably it's reasonable for this guidance to appear in both places: in 
the TLS drafts and a CFRG document, so that it can serve as common 
guidance for other protocols.

Cheers,
Kris

On 12/07/2026 13:44, Nick Sullivan wrote:

> Hi Kris,
>
> I think we agree, but I want to be clear on one point: we should 
> restrain ourselves from creating a hard dependency on the CFRG 
> publishing a draft for this document. The security considerations 
> document for ML-KEM has been discussed in the CFRG but is has not yet 
> been adopted (discussion is ongoing). Given the targeted nature of 
> this suggestion and the attention it has from experts participating in 
> this WG, having to block on a CFRG publication for one recommendation 
> would be overkill. Working groups are free to make their own 
> cryptographic decisions.
>
> I agree that entropy and RNG compromise should be taken into 
> consideration in a CFRG draft on this topic if adopted so that other 
> working groups can benefit from this type of advice, but not as a 
> blocker for this document. The TLS WG chairs always have the option to 
> solicit an expert review from the Crypto Review Panel on any sensitive 
> cryptographic elements of a protocol if they deem it necessary.
>
> Best,
> Nick
>
> On Sun, Jul 12, 2026 at 12:07 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]