Hi Scott,
thank you for your review.
Comments:
This draft nowhere states what is actually in the Frodo KEi, KEr payloads.
Now, you might say that this is profoundly obvious (and yeah, I would tend
to agree with you) - I believe that you should state that explicitly.
This is true and the authors are aware of this. We think that the
normative reference to the FrodoKEM specification in the draft
(https://frodokem.org/files/FrodoKEM_standard_proposal_20241205.pdf)
contains the necessary information, but we agree that
it is better to explicitly mention the format and encoding of the content of
KE payloads in case of FrodoKEM.
You have 3 parameter sets with the AES version of Frodo, and 3 with the
SHAKE version of Frodo. Why?
That's what current specification of FrodoKEM has.
Can you cite use cases where:
* The AES version is clearly better suited
* The SHAKE version is clearly better suited
If you can't (in both directions), then there is no reason to have both sets
of parameter sets - it gives more possibilities of incompatibly (because one
side selected the AES version and the other the SHAKE version).
We discussed a bit whether it makes sense to reduce the number of
variants to only 3. So far no agreement on this was achieved.
But we agree that it would be better to reduce the number of
options.
Or clearly state what the advantages and disadvantages of different
parameter sets (as you suggested above).
In addition, it appears that Frodo key generation is considerably faster
than Frodo decapsulation - hence, doing truly ephemeral Frodo is fairly
cheap. With this in mind, would it make sense to prohibit reuse of the
Frodo private key? There is text in 3.2 which states that this is
"expected"; however, that comes short of a MUST NOT reuse statement.
That's true. We will think how to better resolve this (core IKEv2
draft doesn't have such a requirement).
In the security section, you write:
In additon, due to the fragmentation of public key and cipthertext of
the IKE message when FrodoKEM is hybrided, the performance of the
IKEv2 may be affected and the chance of re-transmision of IKE packet
could become higher in some networking secnarios.
Apart from the typos additon, cipthertext, re-transmision, secnarios (and
hybrided, but that clause could just be removed), this really is about
performance, not security (and hence belongs somewhere else).
Good point, thank you.
Regards,
Valery.
_____
From: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org>
Sent: Tuesday, July 8, 2025 4:48 AM
To: ipsec@ietf.org <ipsec@ietf.org>; ipsecme-cha...@ietf.org
<ipsecme-cha...@ietf.org>
Cc: leonie.bruck...@secunet.com <leonie.bruck...@secunet.com>;
smyslov.i...@gmail.com <smyslov.i...@gmail.com>; Wang Guilin
<wang.gui...@huawei.com>
Subject: [IPsec] FW: New Version Notification for
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
Dear all,
Our draft "Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM" has
been updated to v01. Here are the two main changes made, as a response to
comments received at 122 meeting:
* Restructured the draft.
* Reduced the point codes from 12 to 6 (eFrodoKEM).
Also, we would like to ask group adoption, based on the mostly positive
discussions in mailing list, which were summarized on my presentation slides
at IETF 122
https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-q
uantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00
The original discussion are also available at
https://mailarchive.ietf.org/arch/search/?q=Frodo
<https://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec>
&f_list=ipsec
Dear chairs,
We will appreciate if a time slot could be assigned for us to present this
draft at Mardid.
Thanks,
Guilin (On behalf of Leonie and Valery as well)
-----Original Message-----
From: internet-dra...@ietf.org <internet-dra...@ietf.org>
Sent: Monday, 7 July 2025 7:13 pm
To: Wang Guilin <wang.gui...@huawei.com>; Wang Guilin
<wang.gui...@huawei.com>; Leonie Bruckert <leonie.bruck...@secunet.com>;
Leonie Bruckert <leonie.bruck...@secunet.com>; Valery Smyslov
<smyslov.i...@gmail.com>
Subject: New Version Notification for
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt
A new version of Internet-Draft
draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt has been successfully
submitted by Guilin Wang and posted to the IETF repository.
Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo
Revision: 01
Title: Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM
Date: 2025-07-07
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01
.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-01
.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-fr
odo
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev
2-frodo-01
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 -- 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
