Hi Usama,
>If you could please state your three categories as pure non-PQ (without the >MLKEM thingy) I don't think quantum-resistance in itself is important unless you want to model how an CRQC breaking an algorithm will affect the security properties of the protocol. You get non-PQC reuse cases by just replacing ML-KEM with secp256r1, but note that TLS does not have the hybrid X25519secp256r1 registered. With a NIKE like secp256r1, also the server can use a static key. --- 1. Reuse of ephemeral key within a CH: - Session A: ClientHello with secp256r1 KeyShareEntry1 and X25519secp256r1 KeyShareEntry2 both containing the same secp256r1 public key. 1b. Reuse of ephemeral key within a session with HRR: - Session Ab: ClientHello with secp256r1 KeyShareEntry1b. Sever sends HRR and picks X25519secp256r1. Client sends second ClientHello with X25519secp256r1 KeyShareEntry2b containing the same secp256r1 public key as KeyShareEntry1b. 2. Reuse of ephemeral key across sessions: - Session B1. ClientHello with secp256r1 KeyShareEntry3 and X25519 KeyShareEntry4. Sever picks X25519 KeyShareEntry4. - Session B2. ClientHello with secp256r1 KeyShareEntry3 and X25519 KeyShareEntry5. 3. Client using a static key - Session C1. ClientHello with secp256r1 KeyShareEntry6. Sever picks secp256r1 KeyShareEntry6 - Session C2. ClientHello with secp256r1 KeyShareEntry6. Sever picks secp256r1 KeyShareEntry6 4. Server using a static key - Session D1. ClientHello with secp256r1 KeyShareEntry7. Sever picks secp256r1 KeyShareEntry7 and sends Serverhello with secp256r1 KeyShareEntry8. - Session D2. ClientHello with secp256r1 KeyShareEntry9. Sever picks secp256r1 KeyShareEntry9 and sends Serverhello with secp256r1 KeyShareEntry8. 5. Client and Server using static keys - Session E1. ClientHello with secp256r1 KeyShareEntry10. Sever picks secp256r1 KeyShareEntry10 and sends Serverhello with secp256r1 KeyShareEntry11. - Session E2. ClientHello with secp256r1 KeyShareEntry10. Sever picks secp256r1 KeyShareEntry10 and sends Serverhello with secp256r1 KeyShareEntry11. --- Reuse of information is a recurring failure in protocol design and implementation, repeatedly turning otherwise secure constructions into trivially exploitable systems. Cheers, John From: Muhammad Usama Sardar <[email protected]> Date: Sunday, 1 March 2026 at 16:38 To: John Mattsson <[email protected]> Cc: Joseph Salowey <[email protected]>, [email protected] <[email protected]> Subject: Re: [TLS] Re: Clarification on the FATT Process Hi John, On 01.03.26 13:16, John Mattsson wrote: I made a PR based on my mail https://github.com/tlswg/tls13-spec/pull/1408 <7494131a-10ad-45ac-87f1-72bc62bcbbae> I believe anything that helps avoid misunderstandings (see below) is valuable, so I support this PR. Since RFC8446bis is going through open heart surgery anyway, this small stitch should not hurt. I do not agree that RFC 8446 permits static keys, but I do agree that it is unclear. I have no use of static keys for visibility, but clearly describing the security consequences is better than the current situation. It's always good to clarify in RFC, because such ambiguities may have security and privacy implications. In this specific case, it seems to have such implications. If static keys are allowed, RFC8446bis should tone down statements like “all public-key based key exchange mechanisms now provide forward secrecy." Well, the quoted statement of RFC8446bis is wrong anyway. I believe key exchange mechanism is not the only thing which determines forward secrecy. I believe one could have public-key based key exchange mechanisms and still no forward secrecy. What I mean is that it depends on the overall protocol design and not just these mechanisms. I have proposed a small change in your PR. It would be good if RFC8446bis could clarify what this 'key reuse' means. As discussed earlier, this term can have at least three very different meanings. Many formal analysis experts have understood TLS 1.3 as specifying that keys should be used for only one execution of key establishment. https://mailarchive.ietf.org/arch/msg/tls/MOqSAplAYQuA6AwkKfHCphQUlKU/ <96958373-1fbf-4f8b-888b-cfb0b5df7892> As I agreed before, this would be very helpful to avoid talking past each other. Unfortunately, Ekr does not understand me [0] and I do not understand him, and the discussion could not continue. Apparently you and the senior IETF participant you mention in your email also had a misunderstanding. If you could please state your three categories as pure non-PQ (without the MLKEM thingy) in a little bit more detail from a protocol perspective, I can do the formal analysis for all the three categories and hopefully propose something for security considerations of RFC8446bis. If 'key reuse' includes using the same key in more than one execution of key establishment, RFC 8446bis should explain that such 'key reuse' undermines forward secrecy and makes exploitation of side-channel attacks and implementation flaws much easier. I can attest to that. While RFC 8446 fails to define the term 'ephemeral', specifications using ML-KEM points normatively to FIPS 203, which in turn points normatively to SP 800-227, which has very precise definitions for 'ephemeral' and 'static'. Since X25519MLKEM768 is already the de facto standard for TLS key exchange, TLS specifications should avoid using the terms 'ephemeral' and 'static' in ways that conflict with FIPS 203. I thought we wanted to keep RFC8446bis free from MLKEM thingies. If we want to add MLKEM thingies into RFC8446bis, we should make a very careful pass over the whole RFC8446bis, in particular security considerations. -Usama
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
