| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Jay, Please do explain what my “misunderstanding” is. Also, a recommendation means that there are circumstances in which the recommended feature would not be performed. Since it is not a requirement, there are obviously times when PFS is not strictly necessary in TLS! If 802.11 does as you suggest, which is to follow the *recommendation* of TLS then PFS would not be required in 802.11 but would merely be recommended.
I would also like to hear what is wrong with the analysis in [1] and [2] regarding reuse of an ML-KEM encapsulation key. If there is nothing wrong then the No Sig exchange is not “unsafe” as you stated. Please do explain this as well. Regards, Dan.
[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:
Jay Yang <yang.zhijie@xxxxxxxxxx> Hi Mark, Happy new year! Sorry for my delay response in holiday season. The description in this paragraph do confusing, and there is also some misunderstanding from Dan via his interpretation via several emails. But something is clear. TLS 1.3 owns PFS property, and a new peerkey is required for each session, it is recommended that when using ML-KEM in TLS 1.3 that a fresh keypair be generated
for each session, which is confirmed by the Author via some offline discussion. We asked the author to reword this paragraph in the later revision. Back to 802.11, how do you (or other members) think about the PFS feature in WIFI ? If you agree that 802.11 also features PFS , please follow the recommendation from IETF TLS . Thanks Best Regards Jay Yang (杨志杰)
Original From: MarkHamilton <mark.hamilton2152@xxxxxxxxx> To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx>; Date: 2025年12月10日
00:54 Subject: Re: [STDS-802-11-TGBT] Insecurity of "no sig " exchange in 11-25/1592r6 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 |