[TLS] Re: Clarification on the FATT Process

[Muhammad Usama Sardar <[e-mail]>]

<https://github.com/tlswg/tls13-spec/pull/1408>

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
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/
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