Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBT] Insecurity of "no sig" exchange in 11-25/1592r6



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>
To: STDS-802-11-TGBT@xxxxxxxxxxxxxxxxx <STDS-802-11-TGBT@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