On Fri, 9 May 2025, Kampanakis, Panos wrote:
[ speaking as individual ]
Good catch! I could not find any IKEv2 drafts with normative language regarding
ephemeral keys. And indeed section 2.12 of RFC7296 allows for reuse. I think we
have since moved to a world where ephemeral is cheap and PFS is required.
I am leaning towards taking your suggested text and using "RECOMMENDED" instead of
"REQUIRED" and referencing RFC7296 section 2.12 about why. Other WGs have had long discussions
about normative language on this topic and I think pointing it out and "RECOMMENDing" it is the
important thing. The actual normative language, I don't have strong feelings about.
Doesn't FIPS already require it? I understand TLS servers might want to
allow re-use, but IKEv2 has its own anti-ddos build-in and doesn't get
as many connections to it as a TLS server does. I'd much rather nudge
people to REQUIRED.
I'd like to keep PFS out of this discussion though. I am not sure the
world is moving towards more PFS for IPsec, as it makes hardware
offloading more complicated and it is generally accepted that the inner
protocols already handle retransmits (eg TCP or applications already
needing to handle UDP retransmits in their protocol)
Paul
-----Original Message-----
From: Rebecca Guthrie <rmgu...@uwe.nsa.gov>
Sent: Thursday, May 8, 2025 2:26 PM
To: ipsec@ietf.org; Kampanakis, Panos <kpa...@amazon.com>; Ravago, Gerardo
<g...@amazon.com>
Subject: RE: [EXTERNAL] [IPsec] I-D Action:
draft-ietf-ipsecme-ikev2-mlkem-00.txt
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.
Hi all,
Glad to see this document adopted by the WG.
One small question- in Section 3, the draft reads, "As with (EC)DH keys today,
generating an ephemeral key exchange keypair for ECDH and ML-KEM is still REQUIRED per
connection by this specification (IND-CPA security)."
However, my understanding of RFC7296 (Section 2.12) is that it doesn't actually
prohibit the re-use of ephemeral keys." Is there guidance other than 7296 that
explicitly prohibits ephemeral key re-use?
Or is it better to rephrase to something like: "Generating an ephemeral key exchange
keypair for ECDH and ML-KEM is REQUIRED per connection by this specification, as is
common practice for (EC)DH keys today."
Thanks,
Rebecca
Rebecca Guthrie
she/her
Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center
(CCC) National Security Agency (NSA)
-----Original Message-----
From: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: Thursday, May 1, 2025 6:14 AM
To: i-d-annou...@ietf.org
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-mlkem-00.txt
Internet-Draft draft-ietf-ipsecme-ikev2-mlkem-00.txt is now available. It is a
work item of the IP Security Maintenance and Extensions (IPSECME) WG of the
IETF.
Title: Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key
Exchange Protocol Version 2 (IKEv2)
Authors: Panos Kampanakis
Gerardo Ravago
Name: draft-ietf-ipsecme-ikev2-mlkem-00.txt
Pages: 10
Dates: 2025-04-29
Abstract:
NIST recently standardized ML-KEM, a new key encapsulation mechanism,
which can be used for quantum-resistant key establishment. This
draft specifies how to use ML-KEM as an additional key exchange in
IKEv2 along with traditional key exchanges. This Post-Quantum
Traditional Hybrid Key Encapsulation Mechanism approach allows for
negotiating IKE and Child SA keys which are safe against
cryptanalytically-relevant quantum computers and theoretical
weaknesses in ML-KEM.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-mlkem-00.html
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
