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

[Valery Smyslov <[e-mail]>]

Hi Éric,

thank you for your comments. Please see inline.

> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:[e-mail]]
> Sent: Tuesday, November 29, 2022 12:38 PM
> To: The IESG
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
> CC @evyncke
> 
> Thank you for the work put into this document. Even if my IPsec knowledge is
> now very dated, I find it relatively easy to read.

Thank you.

> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
> 
> Special thanks to Tero Kivinen for the shepherd's write-up including the WG
> consensus *but* the justification of the intended status is missing.
> 
> Other thanks to Geoff Huston for his Last Call DNS directorate review at:
> https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/
> 
> Please note that Charles Perkins is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir reviews as well when Charles
> will complete the review (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> Out of all Paul Wouters's points, I support the last one about AH (I am not
> experience enough to appreciate the other ones). It is also related to bullet
> 3) of section 2.

I have already commented this in my response to Paul.
So, the document focuses on PQ security, but also has
another application in mind - the ability to combine 
several different key exchange methods so, that the resulting
shared secret depends on all of them. This can be useful 
without any PQ algorithms - e.g. in a situation
when each of the peers trust only its favorite
key exchange algorithms, so that there is no any single
one that is trusted by the both. In this case the draft 
allows to use two, so that each peer will be sure
that its favorite algorithm is used.

In this context AH still may be used
(well, it is not deprecated yet?).

> ### Missing reference RFC 8247
> 
> As indicated by idnits tool, RFC 8247 is used as a reference but is not defined
> ;-)

Ah, we managed to confuse idnits (which in fact is not too difficult) :-)

This document does not reference RFC 8247, but it contains 
the text to be placed at the IANA registry page as a Note,
and this text contains a "[RFC8247]", but this reference 
is in the context of IANA page :-)

> ### Section 2
> 
> 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.

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

> ## NITS
> 
> ### Section 1.2
> 
> `payloads longer than 64k` suggest to specify the units of measure.

Changed to 64 Kbytes.

Thank you!

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
>