I like this protocol. It's reminiscent of the "encrypted nonce" method of
authentication in IKEv1 where you took a trusted public key, encapsed a
nonce with it, and the ability of the peer to prove knowledge of the nonce
authenticated it. While it *technically* wasn't a SIGMA protocol, it was
designed by the guy who wrote SIGMA while the ideas behind SIGMA were
being codified so it's "SIGMA adjacent".
Perhaps the draft could mention that the exchange of certificates is a
one-off and once a peer's public key is trusted this exchange isn't needed.
That might partially address the concern over the number of round trips.
Of course, then one has to determine the identity of the peer in a privacy
protecting manner. Perhaps, by using a key derived from ss_i to
protect a hash of the sender's public key/cert. Or something.
By the way, I'm proposing a similar PQ exchange for 802.11 primarily
due to the fact that PQC signature sizes exceed the MTU (with the
possible exception of falcon) and there is (currently) no way to do
fragmentation/reassembly of 802.11 authentication frames.
regards,
Dan.
On 6/16/25 11:48 PM, John Mattsson wrote:
Hi Uri,
Thanks for sharing. I think it is good to discuss the use of KEMs for
authentication, but one additional complexity of not using signatures
is that you also need changes to your PKIto support for
proof-of-possesion of KEM keys. The deployments of KEM authentication
so far, e.g., Rosenpass seem to be systems not using PKI.
https://rosenpass.eu/
I think the document it overstating is benefitsa bit. To keep the
current security properties of SIGMA-based protocols like IKEv2, TLS
1.3 and EDHOC you would, as Scott pointed out, more roundtrips than
today. And while ML-KEM has smaller encapsulations than ML-DSA has
signatures, this is not true for PQC algorithms in general with other
upcoming lattice- and multivariate signatures having less overhead
than ML-KEM.
https://blog.cloudflare.com/another-look-at-pq-signatures/
The draft has the name draft-uri-lake but only contains specifications
for IKEv2, not EDHOC. I think you should consider what you want, and
submit targeted drafts for the protocols (IKEv2, EDHOC, etc) that you
propose to extend. I think a EDHOC method with KEM authentication or
mixed KEM-signature authentication would be interesting, but likely
not the main way forward. Making EDHOC quatum-resistant is as simple
as registering new cipher suitesfor method 0(signature
authentication), and in the future cipher suites with ML-KEM and e.g.,
MAYO would have less overhead than KEM-based authentication such as
PQuAKE.
Cheers,
John
*From: *Blumenthal, Uri - 0553 - MITLL <[email protected]>
*Date: *Friday, 13 June 2025 at 18:29
*To: *[email protected] <[email protected]>
*Cc: *Wilson, David - 0553 - MITLL <[email protected]>, Luo,
Brandon - 0553 - MITLL <[email protected]>, [email protected]
<[email protected]>
*Subject: *[Lake] Re: Proposing Authenticated Key Exchange for
adoption consideration
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
Now, regarding
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.
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.
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)):
Post-Quantum Perfect Forward Security;
Post-Quantum Identity Hiding;
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!
_______________________________________________
IPsec mailing list [email protected]
To unsubscribe send an email [email protected]
--
"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
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
