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

[Kampanakis, Panos]

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

Re: [IPsec] WGLC of draft-ietf-ipsecme-multi-sa-performance

[Yoav Nir]

Hi.

I’ve read the draft. Overall, it’s similar to a non-standardized solution we 
did at Check Point several years ago, so I agree that it is a solution that 
works.  Of course, since there *are* a bunch of working implementations, that 
is not particularly insightful.

With a lot of flows, it’s likely that in most situations the number of parallel 
SAs is going to be about the same as the number of “resources”. The text in 
section 4 does mention the issue of having peers with a different number of 
CPUs. In practice these can be very different. It’s not unheard of to have a 
center office with dozens of CPUs working with a branch office machine with 
one. The way this protocol seems to work is that the center office will attempt 
to create dozens of SAs, only to be stopped by the branch office which at some 
point will return the TS_MAX_QUEUE notification.  I’m not a big fan of creating 
as many SAs as you can until the peer fails you, but the alternative would be 
to pre-negotiate the ts_max_queue value.

A couple of editorial comments:
- Although it is implied, it should be stated explicitly that TS_MAX_QUEUE does 
not mean no more child SAs with these TS ever. As some child SAs get deleted 
and perhaps not rekeyed if they’re idle, if traffic picks up again, new child 
SAs with these TS can be created until the peer again blocks you with a 
TS_MAX_QUEUE.
- With a single SA pair per TS, implementations can expect that all packets in 
a flow (such as a TCP connection) will go through the same SA pair. This is 
especially important in implementations that are combined with firewalls. I 
think we need explicit text that says packets for any flow may come on any of 
the SAs from the logical group of child SAs. Perhaps:

“implementations MUST NOT assume that all packets of a particular flow will be 
encrypted with a particular SA in the logical group of child SAs.”

Yoav



> On 25 Oct 2023, at 1:40, Tero Kivinen  wrote:
> 
> This will start three week working group laste call for
> draft-ietf-ipsecme-multi-sa-performance. The working group last call
> will end at 2023-11-15.
> 
> Please review the document and send comments to the list if you think
> it is ready for publication.
> -- 
> kivi...@iki.fi
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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