Tommy Jensen has entered the following ballot position for
draft-ietf-ipsecme-ikev2-pqc-auth-11: 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-pqc-auth/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

+1 to Mike on the suggestion of requiring PMTUD (even if he wasn't trying to go
so far, I am)

I see that you define requesting certificates reusing IKEv2's existing
mechanism (Section 3.7 of RFC 7296). I note that this uses SHA-1 hashes, which
seems a bit odd as a dependency for a PQC draft. This might be fine because
SHA-1 is clearly good enough for a current BCP, but I just want to double check
that this is intentional for this draft and the reliance on SHA-1 in this case
doesn't introduce any unintended consequences.

I know it's tradition for us to encourage more use of MUST, but I see the
following MUST from Section 3.2.1 as a SHOULD in disguise. Given you've already
provided the "SHOULD unless <foo>" logic in the same sentence, I would
recommend doing a single word replacement of MUST with SHOULD.

>   IKEv2 peers supporting the PQC authentication mechanism defined in
>   this specification MUST implement IKEv2 message fragmentation
>   [RFC7383], unless IKEv2 runs over a reliable transport (e.g.,
>   [RFC9329]) or the underlying network is known to support sufficiently
>   large MTUs without fragmentation issues, since PQC public keys and
>   signatures can be significantly larger than those used in traditional
>   algorithms.



_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to