| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Furthermore, there is this paragraph in the I-D that Jay referred to: TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy. Care must be taken to ensure that keys
are only re-used if the algorithms from which they are derived are designed to be secure under key-reuse. ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the
security of the keys. However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy. TLS does not prohibit reuse because ML-KEM’s IND-CCA security is satisfied when the key is reused without being compromised. So if re-use is not prohibited then either TLS is also “unsafe”—per Jay—or Jay is wrong in his assertion. I maintain
it is the latter. Regards, Dan. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius From:
"Harkins, Dan" <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> Mark, There’s no contradiction. TLS has very clearly defined security properties (as opposed to 802.11!) and everything they do has to continue to guarantee those properties. One of these properties is IND-CCA which is that the resulting shared secret will be indistinguishable
from a random number in the presence of a chosen ciphertext attack. The first statement is saying that reusing an ML-KEM encapsulation key will continue to provide IND-CCA. Re-use satisfies the requirement. But TLS does key establishment and signature(s) authentication in a very specific way. And if the sole key establishment for a subsequent TLS connect was a single re-used ML-KEM encapsulation key then there would not be perfect forward
secrecy. So it *recommends* to not do that. For TLS. Note that it doesn’t *forbid* it which would be to require an ephemeral ML-KEM exchange each time. A recommendation is like a “should” and a requirement is a “shall”.
Now what Jay was saying that was because the no-sig exchange reused an ML-KEM encapsulation key, that it was “unsafe”. Now when asked he did not define “unsafe” or explain what he meant, just that I had to go discuss it with the IETF.
But if one can still achieve IND-CCA with a reused ML-KEM encapsulation key then there is nothing “unsafe” about it. Let me also point you to [1] which discusses the acceptability of reuse of ML-KEM encapsulation keys and also [2] which also mentions the acceptability of reuse of ML-KEM keys, in fact it mentions it quite explicitly: “It is secure to
reuse a public key multiple times.” If one wants to move the goal posts and say the issue is PFS then keep in mind that this is not TLS (which I mentioned in a post-script to Jay) and there are 2 MK-KEM keys in this exchange. Furthermore, the PMK caching feature being proposed
has sufficient key separation to provide PFS because the original PTK for the no sig exchange is derived from a PMK and salt while the PTK in a subsequent cached exchange will derive the PTK from the PMK and an ephemeral secret.
There may be ways to increase the security of the no sig exchange but that was not what was said. All that was said was it is “unsafe” which is clearly wrong.
Regards, Dan. [1]
https://datatracker.ietf.org/doc/html/rfc9629 [2]
https://www.ietf.org/archive/id/draft-sfluhrer-cfrg-ml-kem-security-considerations-01.html -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius From:
Mark Hamilton <mark.hamilton2152@xxxxxxxxx> OK, I’m trying to learn something from this exchange. But, I am now confused by the text in the IETF draft. In particular, the two cited sentences: ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term
or re-used without compromising the security of the keys.
and However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect
forward secrecy. seem to be almost directly contradictory, or at least are making a distinction that is too subtle for me to understand. Can one (or both) of you (Dan and Jay) explain why the first sentence seems to clearly say such long-term use is okay, but the second sentence seems to clearly say that it is
not recommended, anyway? Mark From: Harkins, Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx>
Hi Jay, You’re highlighting the wrong part. Note how it says, “the public key/secret key pair can be treated as a long-term key or reused” and the IND-CCA property applies? That is exactly what I’m doing in the No Sig authentication exchange. So, you were incorrect when you said my proposal is “unsafe” because I’m reusing an ML-KEM encapsulation key.
Dan. P.S. this is not TLS. -- “the object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane.” – Marcus Aurelius From:
"yang.zhijie@xxxxxxxxxx" <yang.zhijie@xxxxxxxxxx> Hi Dan, Thanks for initiating this mail thread proactively. See it in the following paragraph, especially on the highlight part. Let me know your thought on this. The whole TLS -ML-KEM draft can be downloaded via the link at the end of this mail. 5. Security Considerations 5.1. IND-CCA The main security property for KEMs is indistinguishability under adaptive chosen ciphertext attack (IND-CCA), which means that shared secret values should be indistinguishable from random strings even given the ability to have other arbitrary ciphertexts decapsulated . IND-CCA corresponds to security against an active attacker, and the public key / secret key pair can be treated as a long-term key or reused. ML-KEM satisfies IND-CCA security in the random oracle model [KYBERV ]. TLS 1.3 does not prohibit key re-use; some implementations may use the same ephemeral public key for more than one key establishment at the cost of limited forward secrecy. Care must be taken to ensure that keys are only re-used if the algorithms from which they are derived are designed to be secure under key-reuse. ML-KEM's IND-CCA security satisfies this requirement such that the public key/secret key pair can be used long-term or re-used without compromising the security of the keys. However, it is still recommended that implementations avoid re-use of any keys (including ML-KEM keys) to ensure perfect forward secrecy. Implementations MUST NOT reuse randomness in the generation of ML-KEM ciphertexts . draft-ietf-tls-mlkem-05
- ML-KEM Post-Quantum Key Agreement for TLS 1.3 Thanks Best Regards Jay Yang (杨志杰)
Original From: Harkins,Dan <00003862fd143b8a-dmarc-request@xxxxxxxxxxxxxxxxx> Date: 2025年12月09日
01:51 Subject: [STDS-802-11-TGBT] Insecurity of "no sig " exchange in 11-25/1592r6 Hi Jay, Can you elaborate on your statement that it is “unsafe” to do what I’m doing in the No Signature Authentication exchange in 11-25/1592r6? What is unsafe and why is it unsafe? You said I should go talk to the IETF but that is not an appropriate
response. If you have an issue with the security of a proposal you need to explain what the issue is. Making a claim and then saying other people need to go on wild chases tracking down people in other SDOs over vague and unattributed statements is not right.
If you can’t explain the issue then retract the statement. So? What’s the issue? Dan. -- “the object of life is not to be on the side of the majority, but to Escape finding oneself in the ranks of the insane.” – Marcus Aurelius To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 To unsubscribe from the STDS-802-11-TGBT list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBT&A=1 |