On Tue, Jul 14, 2026 at 5:11 AM Rifaat Shekh-Yusef <[email protected]> wrote: > > Hi Ekr, > > Thanks for the detailed review and comments. > See a few comments inline. > > Regards, > Rifaat > > > On Thu, Jun 25, 2026 at 12:52 PM Eric Rescorla <[email protected]> wrote: >> >> Document: draft-yusef-tls-pqt-dual-certs-02.txt >> >> Overall, if we are to support the simultaneous use of PQ and >> traditional signatures in TLS, I think that composites are a superior >> approach. > > > Can you elaborate on what you mean by "superior" in this case? > > There are pros and cons to each approach. > Take a look at the following document that has a comparison between these two > approaches: > https://www.ietf.org/archive/id/draft-reddy-pquip-pqc-signature-migration-01.html > > >> As far as I can tell, the only real benefit of this design >> is that it allows you to perform a transition of the form traditional >> -> simultaneous PQ/T -> pure PQ while avoiding the need to issue >> separate composite certificates. >> > > Note that the use cases we are trying to address are enterprise use cases, > not Web. > > Composite - requires 3 PKIs: the existing traditional, composite, and pure > pqc. > Dual - requires 2 PKIs: traditional and pure pqc.
What's the point of having a composite transition step here? Remember TLS signatures are worthless to break after the connection finishes. > > The transition from one mode to another in the dual case is much simpler and > smoother than the composite, relying on changing some configuration to drop > the traditional certificate when the time comes. The configuration is the client no longer accepting or indicating a preference for the legacy algorithm. We already have a proven model for this with RSA/ECC, it's going to be a tall order to say that this doesn't work for PQ. > Dual provides a better backward compatibility with legacy products making it > simpler for organizations to gradually transition their systems. > The decoupling of the PKIs allows for a lifecycle independence with different > validity periods, renewals, revocation, etc. > Dual utilizes existing standards PKI infrastructure and standalone > certificates allows for easier future replacement of algorithms without > waiting for a new composite specification to define how to combine the > signatures of these algorithms. > From an operational perspective, you need to update your TLS library whether > using composite or dual. Because of that composite has no advantage over dual. > > >> >> The cost of this savings is quite a bit of additional complexity in >> TLS. I'd like to see some analysis that shows that cost is worth >> paying. > > > We agree that this adds complexity to TLS. > Because of that we are looking for more parties that might be interested in > such a mechanism to help with the analysis. > > >> >> Given modern automation (ACME) and shortened certificate >> lifetimes, it's hard to believe just issuing the certificates is a big >> deal, though perhaps technically being able to make the composites is? > > > I am not sure I understand this comment. Can elaborate on this? > > Regards, > Rifaat > > >> >> In any case, I'd like to see much stronger arguments than have been >> advanced here before we absorb this complexity. >> >> With that said, even on its own terms I think this draft is trying >> to get too clever. Specifically by: >> >> - Overloading the signature scheme code points to indicate that >> you are sending multiple certificate chains. >> - Only signing a partial transcript. >> >> >> >> At a high level, it's not clear to me that this encodes the right >> semantics. As covered in quite a bit of detail in Chrome's roadmap >> [0], we have to distinguish between the algorithm encoded in the EE's >> certificate and the algorithms used to sign that certificate and other >> certificates in the chain, and there are benefits to requiring a PQ >> PKI even if you don't have PQ keys (stage 3 in Google's roadmap). >> >> >> >> >> >> # Signature schemes >> >> You state in S 4.1. >> >> Dual code points are advertised and negotiated using the existing >> signature_algorithms extension defined in Section 4.2.3 of [TLS], >> exactly as for any other SignatureScheme. A client that supports >> dual authentication includes the relevant dual code points in its >> signature_algorithms list. The server selects one code point from >> the client's list, just as in standard TLS 1.3 negotiation. >> >> The message in which the server's choice is conveyed is in >> CertificateVerify, but the client needs to parse the Certificate prior >> to seeing CertificateVerify, which means that it doesn't know whether >> a dual code point is in in use or not at the time it processes the >> Certificate. Instead, it must parse either version and then fail if >> (for instance) the server sent two certificate chains but then signs >> with a single algorithm. This is possible but kind of unfortunate, >> especially because of the way you handle the transcript. >> >> Second, these code points have narrower semantics than ordinary >> signature schemes, because (for instance) you cannot use them to sign >> the certificate. The result of both of these design choices is a >> bunch of special case state keeping associated with these special >> signature schemes. >> >> Finally, it's not clear to me what the semantics of this extension >> actually are. Suppose that I advertise the following signature >> algorithms: >> >> [ >> ecdsa_secp256r1, >> sha256_mldsa44 >> ] >> >> This allows the server to supply me with a P-256 certificate signed >> with an MLDSA key (or vice versa). Now if I add >> ecdsa_secp256r1_sha256_mldsa44, what does this say about the >> certificate in the PQ chain. Can it be signed by a P-256 key? If not, >> what text forbids this and what is the general rule? >> >> I recognize that it's tricky to actually design something with the >> right semantics here, but I don't think this is quite there and >> overloading this extension seems to make the problem harder. >> >> >> # Only Signing a Partial Transcript >> >> Instead of signing the whole transcript, as everything else in >> TLS does, each algorithm just signs the transcript corresponding >> to its own certificates. As I understand it, you are doing this >> for domain separation reasons, but the consequence is that we >> are in uncharted territory about the security of TLS, and in >> particular that neither signature is endorsing the other's >> certificates. Do you have any analysis for what this does >> to the security of TLS? >> >> In addition, it's an implementation problem because it means that the >> RP needs to maintain two transcripts rather than just hashing in the >> Certificate message as received. Incidentally, the way you have >> specified this seems to remove the Certificate message's headers, >> which would otherwise be in the transcript, as per S 4.4.1 of RFC >> 8446. >> >> It seems like there ought to be some other way to provide >> domain separation. >> >> -Ekr >> >> [0] >> https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ >> >> >> On Wed, Jun 24, 2026 at 11:24 PM tirumal reddy <[email protected]> wrote: >>> >>> Hi all, >>> >>> The draft https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/ >>> has been revised to address the comments received from the WG during the >>> presentation at IETF-123. >>> >>> The draft no longer defines any new TLS extension. Dual authentication is >>> signaled entirely through new SignatureScheme code points, negotiated with >>> the existing signature_algorithms extension; the negotiated code point >>> determines how the existing Certificate and CertificateVerify messages >>> carry the two chains and two signatures. >>> >>> Further comments and suggestions are welcome. >>> >>> Regards, >>> -Tiru >>> >>> ---------- Forwarded message --------- >>> From: <[email protected]> >>> Date: Wed, 24 Jun 2026 at 13:59 >>> Subject: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt >>> To: Tirumaleswar Reddy.K <[email protected]>, Hannes Tschofenig >>> <[email protected]>, Hannes Tschofenig <[email protected]>, >>> Mike Ounsworth <[email protected]>, Rifaat Shekh-Yusef >>> <[email protected]>, Yaroslav Rosomakho <[email protected]> >>> >>> >>> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-02.txt has >>> been >>> successfully submitted by Tirumaleswar Reddy and posted to the >>> IETF repository. >>> >>> Name: draft-yusef-tls-pqt-dual-certs >>> Revision: 02 >>> Title: Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual >>> Certificates in TLS 1.3 >>> Date: 2026-06-24 >>> Group: Individual Submission >>> Pages: 20 >>> URL: >>> https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.txt >>> Status: https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/ >>> HTML: >>> https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-02.html >>> HTMLized: >>> https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs >>> Diff: >>> https://author-tools.ietf.org/iddiff?url2=draft-yusef-tls-pqt-dual-certs-02 >>> >>> Abstract: >>> >>> The anticipated emergence of cryptographically relevant quantum >>> computers (CRQCs) poses a threat to the authentication mechanisms >>> used in TLS 1.3. This document defines a hybrid authentication >>> mechanism that uses two independent certificates, one traditional and >>> one post-quantum, ensuring that an attacker must break both >>> algorithms to compromise a TLS connection. The two certificate >>> chains are carried in a single Certificate message and two >>> independent signatures are encoded in the CertificateVerify message. >>> >>> >>> >>> The IETF Secretariat >>> >>> >>> _______________________________________________ >>> TLS mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
