Re: [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-00.txt

[Ben S3 <[e-mail]>]

Hi Panos, 

Thanks for producing this draft, it'll obviously be very important going forward. A few thoughts on v01 below: 

Abstract states: 
> [...] theoretical weaknesses in ML-KEM as it is relatively new.
This line won't age well – it won't be "relatively new" in 10 years' time. Should this come with something saying "at time of writing" or similar?  

Section 2.1 states: 
> [ML-KEM-1024] SHOULD NOT be used in IKE_SA_INIT because they could often be introducing IP fragmentation which is not possible in IKE_SA_INIT exchanges. 
IP fragmentation is possible in IKE_SA_INIT exchanges, just not IKE fragmentation (as in RFC 7383). 

Is it worth registering a code point for ML-KEM-512 in this draft, for those that want to use it? Looking at the recent flurry of activity around diet-ESP, it seems to me there's interest in running IPsec in constrained settings, which may want to use the smallest secure option available.

This draft is focused almost entirely on using (EC)DH in the IKE_SA_INIT, and ML-KEM in the IKE_INTERMEDIATE.  This implicitly restricts the use case of using a non-(EC)DH algorithm in the IKE_SA_INIT (e.g. another future PQ-KEM). My view is that the draft should be agnostic on what the algorithm in the IKE_SA_INIT is. It also doesn't allow for using ML-KEM in an IKE_FOLLOWUP_KE as per RFC9370, which should be an option.

In fact, since I imagine any future PQ-KEMs will have similar hybrid requirements to ML-KEM, I wonder whether it would make sense for there to be two drafts – a very simple one for ML-KEM registering code points, and a generic draft along the lines of "Use of Post-Quantum Key Encapsulation Mechanisms in IKE". In my mind, this would include info on how KEMs work in a key exchange payload (as opposed to DH – i.e. the second paragraph of section 2.1), as well as recommendations on using a hybrid key exchange.

- Ben S

-----Original Message-----
From: Kampanakis, Panos <[e-mail]> 
Sent: Monday, November 13, 2023 2:22 AM
To: IPsecME WG <[e-mail]>
Cc: Ravago, Gerardo <[e-mail]>
Subject: [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-00.txt

Hi all,

https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/ 
This new draft brings ML-KEM to IKEv2 by using RFC 9370. It basically says how ML-KEM will be negotiated as an additional Key Exchange and requests codepoints for ML-KEM. The intention is not to get temporary codepoints like we did with Kyber in TLS. We are close to the final specs, so codepoints next year would suffice. 

It could be a standards track draft given that ML-KEM will see a lot of adoption, an AD sponsored draft, or even an individual stable draft which gets codepoints from Expert Review.  The approach is to be decided by the IPSECME WG.

Feedback is welcome. 

Thx,
Panos


~~~
A new version of Internet-Draft draft-kampanakis-ml-kem-ikev2-00.txt has been successfully submitted by Panos Kampanakis and posted to the IETF repository.

Name:     draft-kampanakis-ml-kem-ikev2
Revision: 00
Title:    Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)
Date:     2023-11-12
Group:    Individual Submission
Pages:    11
URL:      https://www.ietf.org/archive/id/draft-kampanakis-ml-kem-ikev2-00.txt
Status:   https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/
HTML:     https://www.ietf.org/archive/id/draft-kampanakis-ml-kem-ikev2-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-kampanakis-ml-kem-ikev2


Abstract:

   [EDNOTE: The intention of this draft is to get IANA KE codepoints for
   ML-KEM.  It could be a standards track draft given that ML-KEM will
   see a lot of adoption, an AD sponsored draft, or even a individual
   stable draft which gets codepoints from Expert Review.  The approach
   is to be decided by the IPSECME WG. ]

   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 additionall key exchange
   mechanism in IKEv2 along with traditional (Elliptic Curve) Diffie-
   Hellman.  This hybrid approach allows for negotiating IKE and Child
   SA keys which are safe against cryptanalytically-relevant quantum
   computers and theoretical weaknesses in ML-KEM as it is relatively
   new.



The IETF Secretariat