Re: [IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

[Valery Smyslov <[e-mail]>]

Hi Éric,

> Hello Valery,
> 
> TL;DR:  Thanks for your reply and your comments. I agree with them ;-)
> 
> If you want a more detailed reply, then look for EV> below

OK, I snipped the text where we have an agreement.

> Regards
> 
> -éric

[snipped]

>     > The bullet 2) is a nice explanation about *why* there must be multiple key
>     > exchanges with different methods. Until reading that part, I was really
>     > wondering why this I-D was about the link with PQC and multiple key exchanges.
>     > Should this be mentioned in the abstract already ?
> 
>     I don't mind, but as far as I know, IESG wants abstract to be short :-)
>     If you (and other ADs) think it's a good idea, then we'll add this text.
> 
> EV> I know about short abstract, but they should also give an idea of the content & purpose

If it is OK with the IESG we'll extend the abstract with this text. It will look like:

        This document describes how to extend the Internet Key Exchange Protocol
        Version 2 (IKEv2) to allow multiple key exchanges to take place 
        while computing a shared secret during a Security Association (SA) setup.
	
        The primary application of this feature in IKEv2 is the ability to perform one or more 
        post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman (EC)DH key exchange,
        so that the resulting shared key is resistant against quantum computer attacks.
        Since there is currently no post-quantum key exchange that is trusted at
        the level that (EC)DH is trusted for against conventional (non-quantum)
        adversaries, performing multiple key exchanges with different post-quantum algorithms along
        with the well-established classical key exchange algorithms addresses this concern, since the
        overall security is at least as strong as each individual primitive.
	
        Another possible application for this extension is the ability to combine several key exchanges 
        in situations when no single key exchange algorithm is trusted by both initiator and responder.

       This document updates RFC7296 by renaming a transform type 4 from "Diffie-Hellman Group (D-H)"
        to "Key Exchange Method (KE)" and renaming a field in the Key Exchange Payload from "Diffie-Hellman Group Num"
        to "Key Exchange Method". It also renames an IANA registry for this transform type 
        from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to 
        "Transform Type 4 - Key Exchange Method Transform IDs". These changes generalize 
        key exchange algorithms that can be used in IKEv2.

Hope it's now clear and not *too* long :-)

>     > Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?
> 
>     I don't know, rely on my co-authors (actually it seems that
>     this is a well-known organization outside USA, but formally you are right).
> 
> EV> I live a in Federal state as well (Belgium), so while I understand that FIPS stands for the USA one, let's
> be inclusive. Up to you and the authors.

No problem, will change the text to:

        USA Federal Information Processing Standards (FIPS) compliance.  IPsec is widely used in Federal Information
        Systems and FIPS certification is an important requirement.
        However, at the time of writing, none of the algorithms that is believed
        to be post-quantum is FIPS compliant yet.  Nonetheless, it is possible to combine
        this post-quantum algorithm with a FIPS complaint key establishment method so that
        the overall design remains FIPS compliant [NISTPQCFAQ].

Is it OK that prefix "USA" is added once and not to every appearance of "FIPS" ?

The updated PR is available at:
 https://github.com/post-quantum/ietf-pq-ikev2/pull/22
 
Regards,
Valery.

>     > ## Notes
>     >
>     > This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
>     > [`ietf-comments` tool][ICT] to automatically convert this review into
>     > individual GitHub issues.
>     >
>     > [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
>     > [ICT]: https://github.com/mnot/ietf-comments
>     >
> 
>