[TLS] Re: Confirming PQ+T Signatures Consensus

[tirumal reddy <[e-mail]>]

On Wed, 30 Sept 2026 at 18:59, Watson Ladd <[e-mail]> wrote:

> On Tue, Sep 29, 2026 at 11:18 PM tirumal reddy <[e-mail]> wrote:
> >
> > Hi Stephen,
> >
> > Deployability should be judged against the deployments that need PQ/T
> authentication, not only the Web PKI. In 3GPP and Enterprise networks,
> device identities and trust anchors are provisioned at manufacture, used
> for several years, and often cannot be replaced quickly.
> > Rapid key rotation is not a remediation these deployments can rely on.
> 3GPP TR 33.703 recently decided to consider composite ML-DSA certificates
> for normative work.
>
> This is exactly where hash based signatures would make a lot of sense.
>

3GPP TR 33.703 treats SLH-DSA as a backup for cryptographic diversity.
SLH-DSA complements composite; it does not replace it. SLH-DSA also has no
support in TPMs; TPM 2.0 (v1.85) adds ML-DSA but not SLH-DSA.


> >
> > Cheers,
> > -Tiru
> >
> > On Tue, 29 Sept 2026 at 17:03, Stephen Farrell <stephen.farrell=
> [e-mail]> wrote:
> >>
> >>
> >> Hiya,
> >>
> >> On 28/09/2026 17:52, Sean Turner wrote:
> >> > 1. Should the WG work on PQ + T Hybrid Signatures for TLS?
> >>
> >> Yes, but... the work should be aiming for something that has
> >> a chance of wide deployment, for random web sites, including
> >> esp. self-hosted ones, who need to work with standard browsers
> >> and other standard clients.
> >>
> >> If that's not possible, the WG should slow-peddle until we
> >> find a scheme that does meet that requirement. So maybe do
> >> start the work, but don't progress anything until we think we
> >> can meet this could-be-widely-deployed requirement.
> >>
> >> I'd prefer the approach we took with encrypted SNI, to work
> >> first on a document akin to RFC 8744.
> >>
> >> > 2. Should the WG only work on one: -pqt-dual-certs or
> -composite-ml-dsa?
> >>
> >> Too early to say, given my answer to #1. Having >1 way to
> >> achieve the goal would be a bad plan, but neither of those
> >> drafts seems likely sufficiently useful to me.
> >>
> >> > 3. Should the WG work on: -pqt-dual-certs?
> >>
> >> In the longer term, I think a dual approach is better, but I
> >> don't see sufficient support for this draft now, so: no to
> >> this one from me, for now. (I'm also not keen on the specifics
> >> of the mechanism in the draft as-is.)
> >>
> >> > 4. Should the WG work on: -composite-ml-dsa?
> >>
> >> Despite this being easy to spec, I don't think it's really
> >> that useful, if browsers/root-stores don't want it, and if
> >> the biggest web-PKI CA has said they also won't be going
> >> there. So, also a no from me for that, for now.
> >>
> >> I also don't think that having N people say "yes" to these
> >> questions is a good basis on which to proceed, given that
> >> it seems such schemes won't be widely deployable. (The
> >> regulatory justifications for doing this won't be satisfied
> >> if nobody can really use it.) So, I'd encourage the chairs
> >> to not just count responses as the way to decide this. (And
> >> there's been too much of that in this WG recently anyway:-)
> >>
> >> Cheers,
> >> S.
> >>
> >>
> >> >
> >> > Cheers,
> >> > spt (for the chairs)
> >> >
> >> > [1] https://datatracker.ietf.org/doc/polls-126-tls-202607241600/
> >> > [2] https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
> >> > [3] https://datatracker.ietf.org/doc/draft-yusef-tls-pqt-dual-certs/
> >> > [4] https://www.youtube.com/watch?v=Qp1s1UMmhTI
> >> > [5]
> https://datatracker.ietf.org/meeting/126/materials/slides-126-tls-framing-pq-t-signatures-for-tls-00
> >> > _______________________________________________
> >> > TLS mailing list -- [e-mail]
> >> > To unsubscribe send an email to [e-mail]
> >>
> >> _______________________________________________
> >> TLS mailing list -- [e-mail]
> >> To unsubscribe send an email to [e-mail]
> >
> > _______________________________________________
> > TLS mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>
>
>
> --
> Astra mortemque praestare gradatim
>