Thanks Scott for your comments, see my reply below inline as [HJ]
From: Scott Fluhrer (sfluhrer) <[email protected]>
Sent: Friday, February 27, 2026 1:11 PM
To: Jun Hu (Nokia) <[email protected]>; IPsecME WG <[email protected]>
Subject: Re: New Version Notification for
draft-hu-ipsecme-pqt-hybrid-auth-04.txt
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Two comments:
* In section 5, "the initiator chooses a combination from the responder's
SUPPORTED_AUTH_METHODS"; but no guidance is given about how to make this choice
(and similarly for the responder). Ultimately, the proper choice would depend
on the peer's policy, that is, what sets of signatures the peer would insist on
as a proper validation, and no mechanism exists for communicating that for
multiple certificates (currently, it is implied that any single supported
signature algorithm with a valid certificate is sufficient). When multiple
certificates are in play, then a peer might have either of these policies: "I'd
prefer an RSA cert and an ML-DSA cert, but I'll accept only an RSA cert" (which
the peer might do during a general upgrade), or your policy might be "You must
have an RSA cert and an ML-DSA cert, or I won't talk to you" *which might be
after you've upgraded all your peers). Now, I suppose you can say "choose the
maximal set of certificates, and if that'd not sufficient, the IKE negotiation
would fail" - I believe that a cleaner approach would be to inform the peer of
the policy up front (and if we can't abide by that, the error is more apparent).
[HJ] I think this is about the semantic of SUPPORTED_AUTH_METHODS as defined in
RFC9593; my understanding is the methods in SUPPORTED_AUTH_METHODS are the
methods sender expects receiver to use to authenticate itself (generate
receiver’s AUTH payload); e.g. if peer A include method-1 in its
SUPPORTED_AUTH_METHODS to peer B, then it means A expects B to use method-1 to
generate the AUTH payload it sends to A; there is no mechanism defined in
RFC9593 (or other RFC AFAIK) allows sender to also announce the methods of
generating sender’s AUTH payload.
This draft is only extending RFC9593, but not trying to (and I think it should
not) change this basic semantic of SUPPORTED_AUTH_METHODS.
As with you example "I'd prefer an RSA cert and an ML-DSA cert, but I'll accept
only an RSA cert", I assume it means e.g. peer A only authenticate B via RSA
but it prefer to use RSA+ML-DSA to authenticate itself. So A need to only
include method 1 in its SUPPORTED_AUTH_METHODS to B, and A will use RSA+ML-DSA
cert if B includes RSA+ML-DSA+type-2 in B’s SUPPORTED_AUTH_METHODS
For the other example "You must have an RSA cert and an ML-DSA cert, or I
won't talk to you", then A only includes RSA+ML-DSA +type-2 in A’s
SUPPORTED_AUTH_METHODS, and fail the setup if B doesn’t include same in B’s
SUPPORTED_AUTH_METHODS
* I personally disagree with bolting into the protocol any characterization
of a cryptographical algorithm beyond the minimal ("it's a signature
algorithm"). Your protocol makes an explicit distinction between "traditional"
and "PQC"; in the future, that understanding may change or get more nuanced. I
believe it would be wise if the protocol took a broader and more extensible
view.
[HJ] This is due to the driving use case is PQC hybrid authentication,
“traditional” and “PQC” are the terms used in such context. But I am open to
make it generic.
________________________________
From: Jun Hu (Nokia)
<[email protected]<mailto:[email protected]>>
Sent: Friday, February 27, 2026 3:22 PM
To: IPsecME WG <[email protected]<mailto:[email protected]>>
Subject: [IPsec] FW: New Version Notification for
draft-hu-ipsecme-pqt-hybrid-auth-04.txt
Hi,
Here is an update to draft-hu-ipsecme-pqt-hybrid-auth, review and comments are
appreciated
What's changed in v04:
* align to draft-ietf-lamps-pq-composite-sigs-14
* add text to clarify two setup types
* add text to describe the example exchange in section 5
* clarify using of pre-hash alg
* clarify sign operation in type-2
* ietf-lamps-cert-binding-for-multi-auth is now RFC9763
* ietf-lamps-dilithium-certificates is now RFC9881
* editorial changes
-----Original Message-----
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
Sent: Friday, February 27, 2026 11:20 AM
To: Guilin WANG <[email protected]<mailto:[email protected]>>; Guilin
Wang <[email protected]<mailto:[email protected]>>; Jun Hu (Nokia)
<[email protected]<mailto:[email protected]>>; Yasufumi Morioka (森岡 康史)
<[email protected]<mailto:[email protected]>>
Subject: New Version Notification for draft-hu-ipsecme-pqt-hybrid-auth-04.txt
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
A new version of Internet-Draft draft-hu-ipsecme-pqt-hybrid-auth-04.txt has
been successfully submitted by Jun Hu and posted to the IETF repository.
Name: draft-hu-ipsecme-pqt-hybrid-auth
Revision: 04
Title: Post-Quantum Traditional (PQ/T) Hybrid PKI Authentication in the
Internet Key Exchange Version 2 (IKEv2)
Date: 2026-02-27
Group: Individual Submission
Pages: 14
URL:
https://www.ietf.org/archive/id/draft-hu-ipsecme-pqt-hybrid-auth-04.txt
Status: https://datatracker.ietf.org/doc/draft-hu-ipsecme-pqt-hybrid-auth/
HTML:
https://www.ietf.org/archive/id/draft-hu-ipsecme-pqt-hybrid-auth-04.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-hu-ipsecme-pqt-hybrid-auth
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-hu-ipsecme-pqt-hybrid-auth-04
Abstract:
One IPsec area that would be impacted by Cryptographically Relevant
Quantum Computer (CRQC) is IKEv2 authentication based on traditional
asymmetric cryptographic algorithms: e.g RSA, ECDSA, which are widely
deployed authentication options of IKEv2. There are new Post-Quantum
Cryptographic (PQC) algorithms for digital signature like NIST
[ML-DSA], However, it takes time for new cryptographic algorithms to
mature, There is security risk to use only the new algorithm before
it is field proven. This document describes a hybrid PKI
authentication scheme for IKEv2 that incorporates both traditional
and PQC digital signature algorithms, so that authentication is
secure as long as one algorithm in the hybrid scheme is secure.
The IETF Secretariat
_______________________________________________
IPsec mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[email protected]>
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
