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

[Valery Smyslov <[e-mail]>]

Hi Panos,

first, thank you for posting this draft. I think this is an important work. Few comments below.

First, you should not use in the draft any codepoints until IANA allocates them.
Just replace your self-allocated values for ML-KEM with "<TBA by IANA>"
whenever it is mentioned in the draft. Once codepoints are allocated by IANA
you will replace these placeholders with real values (that might be different
from what are you using now).

Then, I think that there is no need to repeat in this draft text from RFC 7296, RFC9242, RFC 9370 etc.
It is enough if you just reference these RFCs. This would eliminate Section 2 almost entirely,
making the draft shorter. The necessary information is:
- codepoints
- length and wire format of public key and ciphertext
- recipient tests

In addition, you may also consider using ML-KEM as drop-in replacement for DH in IKEv2.
ML-KEM has relatively short public key, that seems to make it possible to use it
in the IKE_SA_INIT without following IKE_INTERMEDIATE (at least in some situations,
e.g. when IKE over TCP is used). In this case this is a pure PQ and not a hybrid protocol. 
Note, that I'm not advocating not using hybrid key exchange in case of ML-KEM (quite the opposite), 
but you may want to mention this possibility for completeness.

Regards,
Valery.



> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec