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

["Eric Vyncke (evyncke)" <[e-mail]>]

Hello Valery,

Thanks for your suggested text for the abstract, may I suggest a little more concise (albeit less precise) text for the 2nd paragraph (up to the authors of course):

            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 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 against conventional (non-quantum)
            adversaries, performing multiple key exchanges with different post-quantum algorithms along
            with the classical key exchange algorithms addresses this concern, since the
            overall security is at least as strong as each individual primitive.

Hope this helps

-éric


On 30/11/2022, 08:48, "iesg on behalf of Valery Smyslov" <[e-mail] on behalf of [e-mail]> wrote:

    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
    >     >
    > 
    >