Usama, On Fri, 29 May 2026 at 14:54, Muhammad Usama Sardar < [email protected]> 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/
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
