On Mon, May 19, 2025 at 2:30 AM tirumal reddy <kond...@gmail.com> wrote: > > Including TLS WG mailing list. > > Thanks Mike for the feedback. The long-lived TLS connections will undergo > periodic re-authentication to check the certificate validity. In a typical > 3GPP deployment, the certificate will expire and be replaced with a new > certificate with a new key pair well before the SLH-DSA signature limit is > approached. For example, if a server certificate is valid for 1 year and each > connection re-authenticates every 12 hours, this results in approximately 730 > signatures per client connection. Even when scaled to many clients, the total > number of signatures generated over the lifetime of a single key remains > vastly below the SLH-DSA signature limit > > It is an important security aspect to be discussed in the draft. I will raise > PR to address it.
What's the actual assumption about the authenticity of the data on that connection? This obviously is dependant on some cryptomania, even if the handshake authentication is in minicrypt, because we don't sign data going over the connection in TLS. So what's the actual gain from SLH-DSA? > > Cheers, > -Tiru > > On Sat, 17 May 2025 at 19:30, Mike Ounsworth <ounsworth+i...@gmail.com> wrote: >> >> (my messages are not making it to the list; hoping someone will reply-all to >> get it on the record) >> >> @Martin, would you object to adoption less if there were fewer algorithms >> being registered ... like 1 or 2? >> >> @Tiru, @JohnMattsson -- My objection to this draft in its current form is >> that there is a lack of discussion about that 2^64 signature limit. I am >> aware of the size of the number "2^64", and that this simply won't be >> reached in a long-lived TLS connections, but once we allow SLH-DSA in TLS, >> it's allowed, and Moore's Law scaling over the coming decades could make it >> conceivable to see 2^64 handshakes on a single key, especially with massive >> horizontal scaling and CSR key reuse across cert renewals. How do you solve >> that? Do we require operators to roughly track the number of signatures >> performed? How? So IMO this draft NEEDS a well-worded Security Consideration >> about this limit and I want to see at least roughly what that text looks >> like as part of adoption because to me SLH-DSA is appropriate for TLS if and >> only if we can find something reasonable to say about this. >> >> On Sat, 17 May 2025 at 07:23, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> >> wrote: >>> >>> So far we’ve heard that 3GPP is considering using this (presumably for >>> thinks like station-to-station, as it were), but they need a stable >>> reference like an RFC. I’d say that “stable reference” is their problem. Do >>> they consider the TLS registries a stable reference? >>> >>> _______________________________________________ >>> TLS mailing list -- tls@ietf.org >>> To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
