Hi Uri, Interesting proposal. It reminds me of KEMTLS.
In a typical network scenario, the smallish RTTs are 20-30ms. Let’s say 20ms. 2 extra RTTs mean 40ms. Now, we can crudely say that an overestimated size of an ML-DSA sig+cert chain is 15KB (these certs typically do not include SCTs) whereas carrying the certs as per PQuAKE we can say the size is 10KB (assuming the peer cert and the issuing CA certs are carried). That means an additional 5KB=40Kbits on the wire for the typical IKEv2 with ML-DSA case vs PQuAKE. That is 40Kbits each direction or a total of 80Kbits bidirectionally. Then, only when the network bandwidth between the peers is >80/40=2Mbps, will ML-DSA in typical IKEv2 be slower than PQuAKE. I am not sure if there are many IKEv2 negotiations taking place under <2MBps connections. Let me know if there is an issue in this logic. Admittedly, even then, the speed will not matter for these negotiations because the tunnels stay up for a long time. As Scott asked, could there be more motivations for such a drastic change in ikEv2? The proofs, anything else? From: Scott Fluhrer (sfluhrer) <[email protected]> Sent: Friday, April 25, 2025 4:16 PM To: Blumenthal, Uri - 0553 - MITLL <[email protected]>; [email protected] Subject: [EXTERNAL] [IPsec] Re: Proposing Authenticated Key Exchange for adoption consideration CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. At first glance, this (from section 5.1, 5.2) appears to be a five round protocol. That is, each side sends five messages (and wait for five responses). Currently, IKEv2 negotiation is a three round protocol (counting the intermediate exchange you need with ML-KEM). Now, ML-KEM is computationally and bandwidth cheaper than ML-DSA - however adding two additional rounds is also expensive (and while it obviously would be implementation dependent, my feeling is that that expense may be greater than the computation/bandwidth costs). Are there any other reasons you believe that it might be "better" than the current proposed approach? ________________________________ From: Blumenthal, Uri - 0553 - MITLL Sent: Friday, April 25, 2025 3:16 PM To: [email protected]<mailto:[email protected]> Subject: [IPsec] Proposing Authenticated Key Exchange for adoption consideration We’d like IPSECME WG to consider the following Internet Draft as a less-expensive (and formally-proven 😉) candidate Post-Quantum authenticated exchange within IKEv2. In our opinion, it is “better” than the current approach of “explicit” signatures – we follow the MQV/HMQV design. Basically, PQuAKE is a Hybrid PQ Authenticated Key Exchange – it uses IKE_INIT ECC step to provide Classic protection. (As you can see, I’m also “shopping” it to the LAKE WG, because their very title says “Lightweight Authenticated Key Exchange – exactly what our protocol offers.) Here are the details – would love to have it discussed, and (hopefully!) accepted here: Name: draft-uri-lake-pquake Revision: 00 Title: PQuAKE - Post-Quantum Authenticated Key Exchange Date: 2025-04-22 Group: Individual Submission Pages: 17 URL: https://www.ietf.org/archive/id/draft-uri-lake-pquake-00.txt Status: https://datatracker.ietf.org/doc/draft-uri-lake-pquake/ HTML: https://www.ietf.org/archive/id/draft-uri-lake-pquake-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-uri-lake-pquake Abstract: This document defines the Post-Quantum Authenticated Key Exchange (PQuAKE) protocol that addresses the needs of bandwidth- and/or power-constrained environments, while maintaining strong security guarantees. It accomplishes that by minimizing the number of bits that need to be exchanged and by utilizing an implicit peer authentication approach similar to Menezes-Qu-Vanstone (MQV) design. This protocol is suitable for integration into protocols that establish dynamic secure sessions, such as Extensible Authentication Protocol (EAP), Internet Key Exchange Version 2 (IKEv2), or Secure Communications Interoperability Protocol (SCIP). This protocol has proofs in the verifiers Verifpal and CryptoVerif for security properties such as secrecy of the session key, mutual authentication, identity hiding with a pre-shared secret, and forward secrecy of the session key. The authors are in the process of publishing the proofs. Thank you! -- V/R, Uri Blumenthal
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
