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

Hi Ben, 

Good catch. You are right. I was reading rfc9370 wrong
" For the methods that require multiple round trips, a separate document should define how such methods are split into several IKE_FOLLOWUP_KE exchanges. "

But that applies to IKE_INTERMEDIATE as well and it is not related to IKEv2 fragmentation. I fixed it in the git repo. It will now read 

   ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts can exceed
   typical network MTUs (1500 bytes).  Thus, IKE_INTERMEDIATE or
   IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts
   may be IKEv2 fragmented as per [RFC7383]. [ EDNOTE: Consider adding
   ML-KEM-512 which would fit in one packet. ]

   Although, this document focuses on using ML-KEM as the second key
   exchange in a PQ/T Hybrid KEM
   [I-D.ietf-pquip-pqt-hybrid-terminology-02] scenario, ML-KEM-768 Key
   Exchange Method identifier TBD36 MAY be used in IKE_SA_INIT as a
   quantum-resistant-only key exchange because the encapsulation key is
   1184 bytes, which assuming an additional 250 bytes of IKE header
   data, can fit in typical network MTUs of 1500 bytes.  [EDNOTE:
   Confirm it fits the MTU with captures.]  ML-KEM-1024 Key Exchange
   Method identifier TBD37 SHOULD NOT be used in IKE_SA_INIT messages
   which could exceed typical network MTUs and cannot be IKEv2
   fragmented. [ EDNOTE: Consider adding ML-KEM-512 which would fit in
   one packet. ]

It will be in the next -03 version. 

-----Original Message-----
From: Ben S3 <ben.s3@ncsc.gov.uk> 
Sent: Tuesday, February 20, 2024 4:17 AM
To: Kampanakis, Panos <kpanos@amazon.com>; ipsec@ietf.org
Cc: Ravago, Gerardo <gcr@amazon.com>
Subject: RE: [EXTERNAL] [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-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 Panos,

Looks good! And perhaps we can discuss the last point in Brisbane.

Just looking at section 2.1:
> IKE_FOLLOWUP_KE messages carrying ML-KEM public keys and ciphertexts cannot be IKEv2 fragmented.

Is this true? RFC7383 Section 2.2 states: "the original message can be fragmented if and only if it contains an Encrypted payload", and IKE_FOLLOWUP_KE exchanges contain such an Encrypted payload protected with the previously-established SKs, as per RFC9370 Section 2.2.4.

- Ben S

-----Original Message-----
From: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>
Sent: Tuesday, February 20, 2024 4:26 AM
To: Ben S3 <ben.s3@ncsc.gov.uk>; ipsec@ietf.org
Cc: Ravago, Gerardo <gcr@amazon.com>
Subject: RE: [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-00.txt

[You don't often get email from kpanos=40amazon.com@dmarc.ietf.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

Hi Ben,

In the just submitted -02 version, I fixed (I think) all points you brought up except for the last one. https://datatracker.ietf.org/doc/html/draft-kampanakis-ml-kem-ikev2-02

I do not think we need a new draft for a IKEv2 combiner.

I also added EDNOTEs about adding ML-KEM-512 in the future if the WG converges that direction.

Thank you for the feedback. Hopefully IPSECME will discuss this draft in Brisbane.

-----Original Message-----
From: IPsec <ipsec-bounces@ietf.org> On Behalf Of Ben S3
Sent: Thursday, January 25, 2024 4:48 AM
To: Kampanakis, Panos <kpanos@amazon.com>; ipsec@ietf.org
Cc: Ravago, Gerardo <gcr@amazon.com>
Subject: RE: [EXTERNAL] [IPsec] New Version Notification for draft-kampanakis-ml-kem-ikev2-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 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 <kpanos@amazon.com>
Sent: Monday, November 13, 2023 2:22 AM
To: IPsecME WG <ipsec@ietf.org>
Cc: Ravago, Gerardo <gcr@amazon.com>
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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec