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
