<https://github.com/tlswg/tls13-spec/pull/1408>
Hi John, On 01.03.26 13:16, John Mattsson wrote:
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 made a PR based on my mail https://github.com/tlswg/tls13-spec/pull/1408
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.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.
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.If static keys are allowed, RFC8446bis should tone down statements like “all public-key based key exchange mechanisms now provide forward secrecy."
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.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/
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]
