Hi Éric,
> -----Original Message-----
> From: Eric Vyncke (evyncke) [mailto:[email protected]]
> Sent: Thursday, December 01, 2022 1:41 PM
> To: Valery Smyslov; 'The IESG'
> Cc: [email protected]; [email protected];
> [email protected];
> [email protected]; [email protected]; [email protected]
> 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"
> <[email protected] on behalf of
> [email protected]> 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
> > >
> >
> >
>
>
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
