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