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

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

Valery, it works fine for me.

Obtenir Outlook pour Android<https://aka.ms/AAb9ysg>

________________________________
De : Valery Smyslov <[e-mail]>
Envoyé : jeudi 1 décembre 2022, 12:25
À : Eric Vyncke (evyncke) <[e-mail]>; 'The IESG' <[e-mail]>
Cc : [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Objet : RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)

Hi Éric,

> -----Original Message-----
> From: Eric Vyncke (evyncke) [mailto:[e-mail]]
> Sent: Thursday, December 01, 2022 1:41 PM
> To: Valery Smyslov; 'The IESG'
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
>
> 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.

I think in this text an important consideration is missing - that we now have enough trust in (EC)DH
against conventional computers, but we don't have this level of trust in most post-quantum
algorithms (both against conventional and quantum adversaries). That's why we want
to combine them.

Ah, I can see now that the original text can be interpreted, that we don't trust
post-quantum key exchange only against conventional adversaries...
We can modify the text as follows (make it more concise, less precise, but still correct, IMHO):

        Since there is currently no post-quantum key exchange that is studied at
        the level that (EC)DH is studied, 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.

Is it OK?

Regards,
Valery.

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