Thank you for your rapid response. I was thinking there was a potential attack here with convincing a peer to accept a root it shouldn't, but so long as this is something y'all have considered, I am not worried about it.
> > On Aug 20, 2026 at 03:58, tirumal reddy <[email protected]> wrote: > > > > 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]
