Hi Guilin, Leonie, and Valery,
FrodoKEM instead of eFrodoKEM is fine imo. The impact would be negligible 
especially for these long-lived tunnels. I suggest to consider aligning the Sec 
Considerations with 
draft-ietf-ipsecme-ikev2-mlkem<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-mlkem-03>
 which explains the difference between CCA and CPA security for KEMs and has 
normative language for ephemeral keypairs.


From: Wang Guilin <[email protected]>
Sent: Wednesday, December 24, 2025 6:19 AM
To: ipsec <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; Wang Guilin 
<[email protected]>
Subject: [EXTERNAL] [IPsec] FW: New Version Notification for 
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.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.

Dear all,

We have just updated our ikev2-frodo draft to version 03. All comments are 
welcome!

In this draft, we have switched 4 variants of eFrodoKEM (ephemeral mode) to 
those of FrodoKEM (standard mode). The mains reasons are here:

  *   IKEv2 [RFC 7296] does not require that the public keys for key exchange 
never repeat.
  *   We have aligned with the authors of FrodoKEM draft in CFRG, and they also 
recommended us to use FrodoKEM (not eFrodoKEM) in IKEv2. Here is their helpful 
reply on Nov 9:

"I think I would tend to agree with you that choosing the standard FrodoKEM 
variants is best suitable for your draft.

The overhead is negligible and it is the default option now. We kept the 
eFrodoKEM variants (previously known as FrodoKEM variants) mostly for backwards 
compatibility of the standard."


The detailed explanation for this change is given in Section 3.2.

At 124 meeting, Scott asked what the performance difference between AES and 
SHAKE variants. Now, experiments by one of our colleague show that AES variant 
with hardware acceleration is about 6 times faster than SHAKE variant without 
hardware acceleration. We are trying to get the number how SHAKE variant is 
faster than AES variant, if both have no hardware acceleration. It should be a 
few times. We will try to show these numbers a little later.

Dear chairs,

We think our draft is ready for the Group Adoption Call. It would be great if 
this can be considered after new year. If there is any aspect to improve our 
draft now, please let us know.

Marry Christmas!

Guilin, Leonie, and Valery.


===================

A new version of Internet-Draft

draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt has been successfully 
submitted by Guilin Wang and posted to the IETF repository.



Name:     draft-wang-ipsecme-hybrid-kem-ikev2-frodo

Revision: 03

Title:    Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM

Date:     2025-12-24

Group:    Individual Submission

Pages:    15

URL:      
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.txt

Status:   
https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/

HTML:     
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.html

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-frodo

Diff:     
https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03



Abstract:



   Multiple key exchanges in the Internet Key Exchange Protocol Version

   2 (IKEv2) [RFC9370] specifies a framework, which supports multiple

   key encapsulation mechanisms (KEMs) in IKEv2 by allowing up to 7

   layers of additional KEMs to derive the final shared secret keys for

   IPsec protocols.  The primary goal is to mitigate the "harvest now

   and decrypt later" threat posed by Cryptographically Relevant Quantum

   Computers(CRQCs).  For this purpose, one or more post-quantum KEMs

   are usually performed in addition to the traditional (EC)DH key

   exchange.  This draft specifies how the post-quantum KEM algorithm

   FrodoKEM is instantiated for IKEv2 as an additional key exchange

   mechanism.



   [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as

   the code points for ML-KEM has been considered in [W-D.K25]. ]


From: Wang Guilin <[email protected]<mailto:[email protected]>>
Sent: Wednesday, 5 November 2025 12:08 am
To: ipsec <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; 
[email protected]<mailto:[email protected]>; Wang Guilin 
<[email protected]<mailto:[email protected]>>
Subject: [IPsec] Fw: New Version Notification for 
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt


Dear all,



We just updated our FrodoKEM for IKEv2 draft to version 02.

 https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/


Here are the main changes:

  *   Reduced code points from 6 in v01 to 4 now (revised Sections 3.3 and 6).

*       Explained why variants for both AES and SHAKE are necessary (revised 
Section 3.2).

*       Added Section 4.2 to describe the KEi(1) and KEr(1) payloads.

*       Also, Section 4.1 has been expanded to describe the main procedures of 
running FrodoKEM (or any PQ KEM) via ADDKE.

Those changes have addressed all comments received from July 2025. Particular 
thanks go to Scott Fluhrer, Kev Kitchen, and Christopher Patton.

The authors of this draft are applying for consideration of group adoption at 
or just after IETF 124 meeting, based on that the current version is quite 
mature, and also previous extensive discussions on FrodoKEM (as recalled below).
    - Summarized discussions available on my presentation slides at IETF 122 
https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-quantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00
   - Over 20 discussions, most supportive, based on the recommendation from EU 
authorities.
    - The original discussion are also available at 
https://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec

New comments and/or reviews are highly appreciated.

Best wishes,

Guili, Leonie, and Valey.
________________________________
From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 4, 2025 8:47 PM
To: Wang Guilin; Wang Guilin; Leonie Bruckert; Leonie Bruckert; Valery Smyslov
Subject: New Version Notification for 
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt

A new version of Internet-Draft
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt has been successfully
submitted by Guilin Wang and posted to the
IETF repository.

Name:     draft-wang-ipsecme-hybrid-kem-ikev2-frodo
Revision: 02
Title:    Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM
Date:     2025-11-04
Group:    Individual Submission
Pages:    15
URL:      
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.txt
Status:   
https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/
HTML:     
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-frodo
Diff:     
https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-02

Abstract:

   Multiple key exchanges in the Internet Key Exchange Protocol Version
   2 (IKEv2) [RFC9370] specifies a framework that supports multiple key
   encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol
   Version 2 (IKEv2) by allowing up to 7 layers of additional KEMs to
   derive the final shared secret keys for IPsec protocols.  The primary
   goal is to mitigate the "harvest now and decrypt later" threat posed
   by cryptanalytically relevant quantum computers (CRQC).  For this
   purpose, usually one or more post-quantum KEMs are performed in
   addition to the traditional (EC)DH key exchange.  This draft
   specifies how the post-quantum KEM FrodoKEM is instantiated in the
   IKEv2 as an additional key exchange mechanism.

   [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as
   the code points for ML-KEM has been considered in [I-D.KR24]. ]



The IETF Secretariat
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to