Hi Panos, fine with me, thank you.
Regards, Valery. > Thanks again Valery. This https://github.com/csosto-pk/pq-mlkem- > ikev2/commit/0cc0b25d2d8613c554b09f5cbfbc6da3ca658924 should cover it. > > -----Original Message----- > From: Valery Smyslov <[email protected]> > Sent: Wednesday, September 10, 2025 2:56 AM > To: Kampanakis, Panos <[email protected]>; [email protected] > Subject: RE: [EXTERNAL] [IPsec] WGLC for draft-ietf-ipsecme-ikev2-mlkem > > 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, > > > Hi Valery, thank you. > > > > I incorporated all of these in https://github.com/csosto-pk/pq-mlkem- > > ikev2/commit/b627d392eaccd3ee1f82e77ac618867ee2358efa (minor some nits > > which I fixed afterwards). > > thank you for this update. I think we are almost there. Just a few more > concerns, please see below. > > > Note I trimmed down the last paragraph of the Sec Considerations as > > suggested but I did not remove it. I wanted to keep the option for > > cases where the initiators and responder must co-exist with legacy and > > there is predistributed knowledge of the identities that have been > > upgraded. It is not a flexible option, but I > wanted to lay out the option for large deployments. > > OK. > > > Also, please confirm that you are OK with the existing text. > > > > > If the checks fail, the responder SHOULD send a Notify payload of > > > type INVALID_SYNTAX as a response to the request from initiator. > > This is OK. > > > which I kept as is. > > Regarding the text: > > <xref target="I-D.ietf-ipsecme-ikev2-qr-alt"> also enables a > negotiation of PPK and ML-KEM > in a single message without an aditional round-trip penalty. > > I think that it somewhat lacks a context for readers (my fault, I was too > brief proposing it). > I propose to use the following text (something along the lines): > > As alternative, <xref target="I-D.ietf-ipsecme-ikev2-qr-alt"> can > also be used for mixing > pre-shared keys in IKEv2, as it provides better security properties > than <xref target="RFC8784" /> > and, since negotiation of PPK can be combined with additional key > exchange performing ML-KEM, > extra round trip penalty can be avoided. > > > Regarding the text: > > Afterwards the peers can perform more IKE_INTERMEDIATE key exchanges > if necessary > and then continue to the IKE_AUTH exchange [...] > > Please, remove "key" from this sentence - IKE_INTERMEDIATE exchanges can be > used for various purposes > besides key exchange. > > > Regarding the text: > > The initiator <bcp14>MAY</bcp14> also send a Delete Payload in a new > INFORMATIONAL > exchange for the responder to remove the SA. > > This needs a clarification. If the error occurs before IKE SA is created > (i.e. in the IKE_INTERMEDIATE), then the > initiator cannot start INFORMATIONAL exchange with Delete payload - it just > does not have session keys yet. It > can start unprotected INFORMATIONAL, but it will be ignored by responder. > Thus, it is not possible to (and there is no point) to do this in this case. > > On the other hand, if the error occurs in the IKE_FOLLOWP_KE during a rekey > or establishing an additional Child > SA, then the Initiator can delete existing IKE SA in this case. > I believe that it even MUST do this: otherwise some unpleasant situations may > happen, if, for example, the error > occurs in the last IKE_FOLLOWP_KE message, so that the responder has already > created a new SA. In this case > the initiator must delete the current IKE SA. And if this was an IKE SA > rekey, then the initiator should also delete a > new IKE SA, but it cannot - due to the error it cannot calculate the keys for > a new IKE SA. This is unpleasant > situation for which IKEv2 provides no good ways to recover from (it may > happen even in base IKEv2 with sole > CREATE_CHILD_SA). > The only way to recover is to start creating IKE SA from scratch sending > INITIAL_CONTACT. > > I don't think all these speculations must be in the draft, just clarify, that > in case the error occurs in the > CREATE_CHILD_SA or IKE_FOLLOWUP_KE exchanges, then the initiator MUST delete > existing IKE SA by > sending a Delete payload in a new INFORMATIONAL exchange. > > (similar text is present in the draft, but is commented out). > > Regards, > Valery. > > > -----Original Message----- > > From: Valery Smyslov <[email protected]> > > Sent: Thursday, August 28, 2025 4:40 AM > > To: 'Tero Kivinen' <[email protected]>; [email protected] > > Cc: [email protected] > > Subject: RE: [EXTERNAL] [IPsec] WGLC for > > draft-ietf-ipsecme-ikev2-mlkem > > > > 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, > > > > I read the document and I think it is ready for publication. > > I also strongly believe that it is the time to request official code points > > from IANA. > > > > There are still some issues that should be addressed before requesting of > > publication. > > > > 1. Abstract. > > > > The abstract is not consistent with the body of the document - it only > > talks about using ML-KEM as an additional KE method, while the document > > allows both standalone and hybrid > use of ML-KEM. > > > > 2. Section 1. > > > > To address this concern, the Mixing Preshared Keys in IKEv2 > > specification [RFC8784] introduced Post-quantum Preshared Keys as a > > temporary option for stirring a pre-shared key of adequate entropy in > > the derived Child SA encryption keys in order to provide quantum- > > resistance. This specification can be used in conjunction with PPK > > as defined in [RFC8784]. > > > > I think that draft-ietf-ipsecme-ikev2-qr-alt should also be referenced > > in this para, as it has advantages over > > RFC8784 and is even more suited for use with hybrid PQ KE, since > > negotiation of PPK and ML-KEM KE can be combined in a single > > IKE_INTERMEDIATE - no additional round trip > penalty. > > > > 3. Section 1.2. > > > > ML-KEM-512, ML-KEM-768 and ML-KEM-1024 key exchanges will not have > > material performance impact on IKEv2/IPsec tunnels which usually stay > > up for long periods of time and transfer sizable amounts of data. > > > > Perhaps s/material/significant? Or noticeable? > > > > 4. Section 2.1. > > > > Afterwards the peers continue to the > > IKE_AUTH exchange phase as defined in Section 3.3.2 of the > > Intermediate Exchange in IKEv2 specification [RFC9242]. > > > > This sentence must be corrected since peers may have more > > IKE_INTERMEDIATE exchanges to perform after completing the one with ML-KEM > > before going to IKE_AUTH. > > > > 5. Section 2.1. > > > > ML-KEM can also be used to create or rekey a Child SA or rekey the > > IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA > > message. > > > > s/message/exchange (2 times) > > > > 6. Section 2.1. > > > > ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP > > packet sizes larger typical network MTUs (1500 bytes). > > ^^^^ > > > > Is not "than" is missed here? > > > > 7. Section 2.1. > > > > 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. > > > > A clarification should be added along the lines "unless IP > > fragmentation is known not to be an issue (e.g., when reliable transport is > > used for IKE [RFC9329], [draft- > smyslov-ipsecme-ikev2-reliable-transport])". > > > > 8. Section 2.3. > > > > If the check fails, the initiator MUST > > reject the ciphertext and MUST fail the exchange. In this case, the > > initiator MAY send a Notify payload of type INVALID_SYNTAX to the > > responder as a separate INFORMATIONAL exchange, usually with no other > > payloads. This is an exception for the general rule of not starting > > new exchanges based on errors in responses. > > > > I think this is a bad idea, not only because it violates RFC 7296 > > Section 2.21, but also because the responder has no clue to associate > > the received error notification with the exchange containing the > > ciphertext, which it thinks is completed with no > error. > > I think that the proper way to handle this situation for the initiator > > is to log the error and just to stop creating new IKE SA if it is not > > yet created (i.e. not to initiate IKE_AUTH or next IKE_INTERMEDIATE) > > or to send a Delete payload in a new INFORMATIONAL exchange if the IKE > > SA is deemed to be already created by responder (e.g. if an error occurred > > in the last IKE_FOLLOWUP_KE > message when no more exchanges are expected to complete the rekey). > > > > 9. Section 3. > > > > Likewise, if the initiator knows > > out-of-band that a responder supports ML-KEM, it SHOULD abort the > > negotiation if the responder selects a proposal that doesn't include > > ML-KEM. > > > > If the initiator knows beforehand that the responder supports ML-KEM, > > then the easier way for the initiator to handle this situation is to > > include _only_ proposals with ML-KEM into the SA payload (thus, restricting > > the possible responder's choice). > > > > 10. Section 3, last para. > > > > I'd rather to remove this para (or at least to shorten it). The > > initiator usually knows (or at least assumes) who responder is, it even > > sends the perceived responder's identity in > IKE_AUTH. > > In this case, if the initiator knows the responder's capabilities > > beforehand, then it can avoid all this hassle with postponed PQ KE by > > simply only offering proposals with ML-KEM. The downgrade attack is > > only possible if the initiator does not know the responder's capabilities > > when it starts creating IKE SA and thus > offers wider options (including those w/o ML-KEM). > > > > 11. Section 4. > > > > Since official code points are already allocated, please replace > > TBD35, TBD36 and TBD37 with actual values (35, > > 36 and 37). This also should be done throughout the document. > > > > Also please remove the last row from the table: > > > > +---------+-------------+--------+-------------------+------------+ > > | 38-1023 | Unassigned | | | | > > > > +---------+-------------+--------+-------------------+------------+ > > > > as this is now what is requested (range of unassigned values are > > maintained by IANA and can be consumed before this draft is published). > > > > Regards, > > Valery. > > > > > This will start two week WGLC for the draft-ietf-ipsecme-ikev2-mlkem > > > [1]. This last call will end at 2025-09-07. If you have any comments > > > about the draft send them to the WG list. > > > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/ > > > -- > > > [email protected] > > > > > > _______________________________________________ > > > IPsec mailing list -- [email protected] To unsubscribe send an email to > > > [email protected] _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
