> 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.
OOPS, code points are already allocated, they are just not mentioned in the draft that made me wrongly thinking that they are not yet requested. Sorry for confusion. Regards, Valery. > 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/ > > -- > > kivi...@iki.fi > > > > _______________________________________________ > > 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
