On 23.02.26 13:34, Eric Rescorla wrote:
On Mon, Feb 23, 2026 at 12:20 AM Muhammad Usama Sardar
<[email protected]> wrote:
Since this draft clearly seems to be controversial, I am still
failing to see why chairs are not asking for expert review of FATT
to resolve the matter. So, I once again request the chairs to
initiate FATT process. Maybe chairs can collect all related
analysis and send these pointers along with the request.
It's not clear to me what you're hoping to learn from the FATT
analysis. Is there some question about the properties of the
combination of ML-KEM with TLS assuming that ML-KEM is
in fact IND-CCA secure? I understand the question to be
about the security of ML-KEM proper, which the FATT process
is not designed to assess.
I may be misunderstanding what you are saying here but as I have mentioned several references of my existing and ongoing works in my previous email, it breaks all of them. As Nadim has confirmed, it breaks his proofs too.
I am hoping the same as described in the process [0]: The FATT will be requested to provide an assessment of whether the document meets the claimed security properties. I believe they can provide useful input, as they did for RFC8773bis.
The question of key reuse seems orthogonal, as key reuse in this draft is allowed to essentially the same extent as it is allowed with traditional ECC algorithms. Again, what is it you're expecting formal review to tell us?
For "essentially the same extent": That's not my reading. RFC8446bis [1] seems to be using normative SHOULD NOT, whereas this draft [2] seems to be changing that to simply a non-normative recommendation "[...] recommended that implementations avoid reuse [...]". Did I miss something? Moreover, I am not convinced that ECC and ML-KEM will have exactly same implications under reuse.
I believe FATT can give some input here.
An Informational draft can still have normative language which tells you how toimplement the spec.
Thanks for the correction.
[0] https://www.netmeister.org/blog/images/kyber-kex-wireshark-ch.pngIt's the source for the text "If we look at John Schauman's helpful breakdown of a hybrid CH that"but I bungled the footnotes markers.
Thanks for the clarification. -Usama[0] https://github.com/tlswg/tls-fatt?tab=readme-ov-file#working-group-last-call-wglc
[1] https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html#appendix-C.4-3
[2] https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-07.html#section-5.3-2
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
