Guys, it’s been a bit more than a month since our response was posted – would greatly appreciate your feedback:
* Are you satisfied with the answers we provided? * Are there any more questions? * Are there any suggestions/recommendations regarding the protocol itself, or its areas of application? Would appreciate your response! Thank you! P.S. Copying to LAKE WG, because this protocol may be useful to them as well – and they may benefit from following our discussion in IPSECME. -- V/R, Uri From: Blumenthal, Uri - 0553 - MITLL <[email protected]> Date: Monday, May 5, 2025 at 13:17 To: [email protected] <[email protected]> Cc: Wilson, David - 0553 - MITLL <[email protected]>, Luo, Brandon - 0553 - MITLL <[email protected]> Subject: [EXT] [IPsec] Re: Proposing Authenticated Key Exchange for adoption consideration Responding on behalf of our Design Team. Scott and Panos, thank you for pointing out the extra round-trip times in our protocol, and rising other questions about the design. We would like to mention a few points to address your concerns: 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). You are correct, though in practice, IKEv2 does tend to involve more than the pure “three rounds”, e.g., when it wants to use “other” mechanisms: https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/images/g039013.png <https://www.juniper.net/documentation/us/en/software/junos/vpn-ipsec/images/g039013.png> Now, regarding 1. The protocol diagram we show presents a simplified and more symmetric version of the protocol. We can reduce the number of exchanges by combining the responder’s hello message with the responder’s certificate exchange message and by combining the initiator’s certificate exchange message with the initiator’s first key encapsulation message. If you agree with this approach, we’ll need to clarify this in the RFC draft. 2. We use the extra round-trip time to establish strong security properties such as post-quantum forward secrecy, identity hiding, and stronger mutual authentication via key confirmation: for some, the improved security may be worth the extra round-trip time. 3. While the total time to complete the exchange may be longer on links which have a larger bandwidth, for some uses cases reducing the extra computation and bandwidth needed would be more important, such as for servers or for embedded systems with slow links or limited computing power. 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). What I think you’re saying is that additional exchanges, while lighter on computation and bandwidth, add extra time to the total handshake duration. This is not only implementation-specific – e.g., see above for one way to reduce that by combining messages together – but application/use-case-specific. In some cases, the existing paradigm is good enough. In others (like ours), our paradigm works better overall. Are there any other reasons you believe that it might be "better" than the current proposed approach? Ours formally proves several important properties (see above: (2)): 1. Post-Quantum Perfect Forward Security; 2. Post-Quantum Identity Hiding; 3. Stronger mutual authentication via Key Confirmation. Interesting proposal. It reminds me of KEMTLS. It certainly does (and we are familiar with it, though as you see, ours is simpler – bare-bones, while theirs is fully geared towards TLS) – and both of them remind (or, at least should remind) of MQV and its children HMQV, FHMQV, and a couple more in the same key. 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. While we cannot speak for all the IPsec users – there is a large enough community that operates over constrained/austere links. So, many as in “percent of the total IPsec users”? Don’t know, can’t claim. Many as in “enough to choose to accommodate them”? Yes. Re. tunnels “staying up for a long time” – some do (e.g., my home VPN 😉), and some don’t. As Scott asked, could there be more motivations for such a drastic change in ikEv2? The proofs, anything else? Advantages of our proposal include: (a) formal proofs, (b) avoiding computation of digital signature (instead of one signing and two verifications by each peer ), we only need one verification by each peer), (c) saving on computation and bandwidth (which may matter much more to the server that deals with many IPsec connections simultaneously, than to a client that needs to perform IKEv2 handshake once in a while/rarely). Also, we are not proposing to change IKEv2, in the sense of “replacing what it does”. We propose an alternative, a complementary path , that can be negotiated and accepted or declined during IKE_INIT. Some user communities (that I know of) are likely to appreciate and accept this option, others (e.g., those that rarely need to establish a new SA, and when they do – it’s over 10+Mbps reliable link) would simply say “Thanks, but no”. And that’s fine with us. 😉 Fragmented UDP, 10K is no more likely to avoid a fragment drop than 15KB in my opinion. More round trips with smaller packets is probably a win in my opinion. (It might push us back to thinking about the puzzles/RFC8019 again) Exactly! Also, depends on the specific use case. E.g., are larger packets more likely to get corrupted by the medium? If it’s a fiber link, probably not. But my users employ other links. 😉 But, probably draft-smyslov-ipsecme-ikev2-reliable-transport is the better answer. For some users – absolutely. For others, that cannot offload everything to TCP – maybe not so… As in the medical science, the correct answer is – it depends. 😉 Thank you!
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
