Agree with Watson here. Don’t see a use case, or a threat - within TLS context - that this would help with. — Regards, Uri
Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Jun 18, 2025, at 18:41, Watson Ladd <watsonbl...@gmail.com> wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside the Laboratory. > |-------------------------------------------------------------------! > >> On Wed, Jun 18, 2025 at 3:33 PM Mike Ounsworth >> <mike.ounswo...@entrust.com> wrote: >> >> Watson, >> >> >> >> There is currently no way to request that a server produce a >> CertificateVerify containing two signatures. This draft is adding a >> mechanism for 2 certificates -> 1 CertificateVerify. >> >> >> >> Basically, since draft-reddy-tls-composite-mldsa is on the table, we also >> wanted to write down the other obvious way of doing hybrid signatures so >> that we can have a complete discussion on the topic. Whether or not this is >> “needed” is exactly the discussion to have at 123 😊 > > It's much easier to make complex arguments over email than in a few > minutes of time at the mic line. > > More specifically, it's not clear to me why these are desirable > mechanisms. Unlike confidentiality mechanisms, authentication > mechanisms cannot be broken retrospectively. We already have a > mechanism for negotiation that has functioned to enable transition > from RSA to ECDSA, largely seamlessly. The scope in the document and > justification of a smooth transition is already demonstrably met with > no real change to libraries to implement this. I don't see anything > in the introduction of the draft that makes the case here, unlike the > one you cite as an alternative. > > Sincerely, > Watson >> >> >> >> --- >> >> Mike Ounsworth >> >> >> >> From: Watson Ladd <watsonbl...@gmail.com> >> Sent: Wednesday, June 18, 2025 5:29 PM >> To: Yaroslav Rosomakho <yrosomakho=40zscaler....@dmarc.ietf.org> >> Cc: <tls@ietf.org> <tls@ietf.org>; Hannes Tschofenig >> <hannes.tschofe...@gmx.net>; Mike Ounsworth <mike.ounswo...@entrust.com> >> Subject: [EXTERNAL] Re: [TLS] Dual certificates in TLS proposal >> >> >> >> On Wed, Jun 18, 2025, 3: 19 PM Yaroslav Rosomakho <yrosomakho=40zscaler. >> com@ dmarc. ietf. org> wrote: Dear TLS WG, We have just submitted a new >> proposal, draft-yusef-tls-dual-certs-00, that extends TLS 1. 3 to support >> authentication using two >> >> >> >> >> >> On Wed, Jun 18, 2025, 3:19 PM Yaroslav Rosomakho >> <yrosomakho=40zscaler....@dmarc.ietf.org> wrote: >> >> Dear TLS WG, >> >> We have just submitted a new proposal, draft-yusef-tls-dual-certs-00, that >> extends TLS 1.3 to support authentication using two certificate chains: one >> using traditional algorithms and one using post-quantum (PQ) algorithms. >> This approach, aimed at closed environments and staged post-quantum >> migration, enables stronger session authentication by requiring both >> signatures to validate. >> >> The proposal builds on existing TLS 1.3 mechanisms with minimal protocol >> changes. It introduces a dual signature algorithm extension and defines how >> dual certificate chains and signatures are structured, while preserving >> compatibility with Exported Authenticators. >> >> This mechanism complements existing proposals such as composite certificates >> (e.g., draft-reddy-tls-composite-mldsa), offering greater deployment >> flexibility, especially for systems that require support for independently >> validated classical and PQ credentials. It also helps with phased migration >> strategies where TLS endpoints have to deal with a mix of opinionated peers >> while limiting the need to create a zoo of PKI hierarchies to satisfy >> classic, pure PQ as well as all possible compositions of algorithms. >> >> We welcome your feedback and discussion on the proposal and the design >> specifics. >> >> >> >> Why is this needed given the existing signalling of client support for >> certificate signature algorithms? >> >> >> >> >> Best Regards, >> Hannes, Mike, Rifaat, Tiru, Yaron and Yaroslav >> >> >> >> >> >> ---------- Forwarded message --------- >> >> A new version of Internet-Draft draft-yusef-tls-pqt-dual-certs-00.txt has >> been >> successfully submitted by Yaroslav Rosomakho and posted to the >> IETF repository. >> >> Name: draft-yusef-tls-pqt-dual-certs >> Revision: 00 >> Title: Post-Quantum Traditional (PQ/T) Hybrid Authentication with Dual >> Certificates in TLS 1.3 >> Date: 2025-06-18 >> Group: Individual Submission >> Pages: 27 >> URL: >> https://www.ietf.org/archive/id/draft-yusef-tls-pqt-dual-certs-00.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-00.html >> HTMLized: >> https://datatracker.ietf.org/doc/html/draft-yusef-tls-pqt-dual-certs >> >> >> Abstract: >> >> This document extends the TLS 1.3 authentication mechanism to allow >> the negotiation and use of two signature algorithms to enable dual- >> algorithm hybrid authentication, ensuring that an attacker would need >> to break both algorithms to compromise the session. The two >> signature algorithms come from two independent certificates that >> together produce a single Certificate and CertificateVerify message. >> >> >> >> The IETF Secretariat >> >> >> >> >> >> This communication (including any attachments) is intended for the sole use >> of the intended recipient and may contain confidential, non-public, and/or >> privileged material. Use, distribution, or reproduction of this >> communication by unintended recipients is not authorized. If you received >> this communication in error, please immediately notify the sender and then >> delete all copies of this communication from your >> system._______________________________________________ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> >> Any email and files/attachments transmitted with it are intended solely for >> the use of the individual or entity to whom they are addressed. If this >> message has been sent to you in error, you must not copy, distribute or >> disclose of the information it contains. Please notify Entrust immediately >> and delete the message from your system. >> > > > -- > Astra mortemque praestare gradatim > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
