And how to deal with downgrades in that case? On Wed, Jul 15, 2026 at 6:29 PM Deirdre Connolly <[email protected]> wrote:
> > If hybrid signatures are used, we strongly prefer non-composite hybrids, > as they simplify the PKI and provide greater flexibility. > > Like dual? > > On Wed, Jul 15, 2026, 7:22 AM John Mattsson <john.mattsson= > [email protected]> wrote: > >> >However, I don't believe that SLH-DSA would be considered a practical >> solution for TLS negotiation. >> >> I would disagree. Ericsson’s conclusion is that SLH-DSA is practical for >> all of our TLS, DTLS, and QUIC telecom use cases. >> >> Our conclusion is also that we prefer the modest performance overhead of >> standalone SLH-DSA over the significant PKI complexity introduced by hybrid >> signatures. If hybrid signatures are used, we strongly prefer non-composite >> hybrids, as they simplify the PKI and provide greater flexibility. >> >> Cheers, >> John Preuß Mattsson >> >> *From: *Scott Fluhrer (sfluhrer) <[email protected]> >> *Date: *Wednesday, 15 July 2026 at 12:58 >> *To: *John Mattsson <[email protected]>; >> [email protected] <[email protected]>; >> <[email protected]> >> *Subject: *Re: [TLS] Re: Fwd: New Version Notification for >> draft-yusef-tls-pqt-dual-certs-02.txt >> >> You are, of course, correct. >> >> However, I don't believe that SLH-DSA would be considered a practical >> solution for TLS negotiation. >> >> ------------------------------ >> *From:* John Mattsson <[email protected]> >> *Sent:* Wednesday, July 15, 2026 1:29 AM >> *To:* Scott Fluhrer (sfluhrer) <[email protected]>; >> [email protected] <[email protected]>; <[email protected]> < >> [email protected]> >> *Subject:* Re: [TLS] Re: Fwd: New Version Notification for >> draft-yusef-tls-pqt-dual-certs-02.txt >> >> >And the Europeans (or, at least their governments) have indicated that >> it is a requirement for their security profiles. >> >> No, all European government I know of approve standalone SLH-DSA. >> >> Cheers, >> John Preuß Mattsson >> >> *From: *Scott Fluhrer (sfluhrer) <[email protected]> >> *Date: *Tuesday, 14 July 2026 at 22:55 >> *To: *[email protected] <[email protected]>; >> <[email protected]> >> *Subject: *[TLS] Re: Fwd: New Version Notification for >> draft-yusef-tls-pqt-dual-certs-02.txt >> >> >> >> > -----Original Message----- >> > From: [email protected] <[email protected]> >> > Sent: Tuesday, July 14, 2026 4:12 PM >> > To: <[email protected]> <[email protected]> >> > Subject: [TLS] Re: Fwd: New Version Notification for >> draft-yusef-tls-pqt-dual- >> > certs-02.txt >> > >> > On Tue, Jul 14, 2026 at 06:01:55PM +0000, Scott Fluhrer (sfluhrer) >> wrote: >> > > Forgive my curiosity, but could you please expand on that? >> > > >> > > We designed the composite certificates/signatures to act like "just >> > > another signature algorithm" (if you don't peek into the innards and I >> > > don't know why anything other than the low level crypto would need >> > > to). >> > >> > Introducing a new algorithm requires creating a new line of >> certificates, and >> > most webservers just do not support any sane way of automatically doing >> that. >> > >> > And even if webserver does support it, there are all manner of nasty >> edge cases >> > making life hard for the ACME client. >> >> If introducing a new algorithm into ACME is an issue, I believe that >> should be fixed - not only for hybrid, but postquantum in general. We >> can't expect that we can rely on RSA, ECDSA and EdDSA for that many more >> years. We don't know when q-day will happen, but I've seen estimates from >> 2029 to "early 30's". Those guesses are from companies working on Quantum >> Computing, and so might reflect either marketing hype or overoptimistic >> hope, but I don't know if we want to make that a security assumption. >> >> > >> > >> > > My personal opinion: I see the need for both pure and hybrid >> > > authentication. However, the hybrid authentication needn't be >> > > composite certificates - dual (aka parallel) certificates would >> > > address the need just as well. >> > >> > My opinion is that hybrid authentication should be left to environments >> with >> > security profile standard specifying it. >> >> And the Europeans (or, at least their governments) have indicated that it >> is a requirement for their security profiles. Even if the situations that >> ACME supports need not consider those requirements, private CAs certainly >> would have to and those would be in scope for TLS. >> >> > >> > And while dual certificates are in theory simple (do both independently >> with >> > intersected algorithm list), in practice this causes major issues with >> APIs (since >> > there are now two EEs). >> >> Is EE == Encrypted Extension? If that's the correct acronym expansion, I >> don't see why we couldn't just use one. On the other hand, I do >> acknowledge that it would make things more difficult for the TLS protocol >> level - I'll let the people that actually work on that level to talk about >> how difficult it is (and if you're one of those guys, I would bow to your >> superior knowledge). >> >> > >> > With composite certificates, the combinatorial explosion occurs >> directly in >> > certificates, which is the absolutely worst place to have that in. >> >> The obvious way to address that is to not specify every combination, but >> only one (or a handful). There have been a huge number of elliptic curves >> published, however we appear to be quite happy with using a few. >> >> > >> > >> > > ________________________________ >> > > From: Ilari Liusvaara <[email protected]> >> > > Sent: Tuesday, July 14, 2026 1:44 PM >> > > To: <[email protected]> <[email protected]> >> > > Subject: [TLS] Re: Fwd: New Version Notification for >> > > draft-yusef-tls-pqt-dual-certs-02.txt >> > > >> > > As an operator, I can say that issuing composite certificate is a big >> > > deal, even with automation like ACME. Because it involves actions that >> > > can not be feasibly automated. >> > >> > >> > >> > >> > -Ilari >> > >> > _______________________________________________ >> > 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] >> > _______________________________________________ > 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]
