[TLS] Re: Fwd: New Version Notification for draft-usama-tls-risks-of-mlkem-01.txt

[Nathanael Ritz <[e-mail]>]

Usama,

On Fri, 29 May 2026 at 14:54, Muhammad Usama Sardar <
[e-mail]> wrote:

> Thanks all for the comments. Some thoughts inline:
>
> [snip]
>
> Based on the results of the idealized KEM model variant (that I remain
> open to collaborate further on), I found nothing from the verification
> output that gives me any reason for concern compared to the DH model
> evaluating the same properties.
>
> FWIW, from a quick look, ISTM that it simply replaces ideal DHKE by ideal
> ML-KEM but IMHO we instead need to focus on the more security-critical
> questions about integration, as Nadim has mentioned. I'll submit a thorough
> review of nits later off-list but a few high-level observations to consider
> for security considerations of draft-ietf-tls-mlkem:
>
>
>    1. ISTM that Yaakov's point quoted below does not seem to be addressed
>    because client and server are assigned static roles in the model. When it
>    will be modeled as non-static, I would be interested to see whether the
>    asymmetry issue becomes visible in at least a couple of properties. I
>    consider it very critical for security considerations of
>    draft-ietf-tls-mlkem and this is the key point of my draft.
>
>    So, you are not really using the fact that either side could have initiated the TLS [...]
>
>    2. ISTM that the failure modes proposed by Yaakov and Nadim are also
>    not modeled.
>    3. A large part of the problem is the careful investigation of what to
>    model, under what threat model, under what system model, under what
>    implementation scenarios etc. I believe all of that needs to be clearly
>    fleshed out in the repo. I think some of this is important for security
>    considerations of draft-ietf-tls-mlkem. I was not able to find much about
>    any of those in readme of repo.
>    4. I would have liked to see some analysis about any subtle cases
>    where hybrid ML-KEM in TLS is *not better* than standalone ML-KEM in
>    TLS. My understanding is that some participants would like to see some
>    statement.
>    5. I believe brainstorming about some robustness (vs. security)
>    properties would also be useful. Even if the security properties hold, does
>    it make side-channel leakage easier?
>
>

The chairs made it clear [0] that we are to take such "detailed discussion"
off the TLSWG list. I suggest and welcome your engagement on the UFMRG list
[1] if you would like to collaborate on the model with me and others.

Thank you,

Nathanael

[0] https://mailarchive.ietf.org/arch/msg/tls/SG10yIg7zjl5dJP06p6LlK-slQ0/
[1] https://mailarchive.ietf.org/arch/msg/ufmrg/xu1V-kSxZM_CC2keFFzwiO_oGZ4/