Hi Tommy, Please see inline
On Thu, 20 Aug 2026 at 13:12, Tommy Jensen via Datatracker <[email protected]> wrote: > 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) > Please see if the PR https://github.com/tireddy2/ikev2-pqc-auth/pull/47/changes addresses your comment. > > 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. > The SHA-1 in Section 3.7 of RFC 7296 only fingerprints the trusted CA's public key to indicate which chain to offer; it doesn't hash or sign the authenticated data (that uses the Identity hash with pure ML-DSA/SLH-DSA), so it has no security impact. -Tiru > > 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]
