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

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

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

Regards

-éric


On 29/11/2022, 18:47, "Valery Smyslov" <[e-mail]> wrote:

    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.

EV> indeed, this feature escaped me

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

EV> no comment about AH deprecation ;-)

    > ### 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 :-)

EV> I should have better eyes... sorry

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

EV> I know about short abstract, but they should also give an idea of the content & purpose

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

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