On Sun, May 25, 2025 at 10:55 PM tirumal reddy <kond...@gmail.com> wrote: > > On Wed, 21 May 2025 at 18:14, Watson Ladd <watsonbl...@gmail.com> wrote: >> >> 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? > > > Mike was referring to the constraint that SLH-DSA imposes a limit of 2⁶⁴ > signatures per key. I responded that the draft will address how deployments > can remain well below this limit by issuing new certificates with new key > pairs before the threshold is reached. The limitation relates specifically to > the number of times a key is used to produce signatures in the > CertificateVerify message during the TLS handshake and post-handshake > authentication.
And I'm taking about assertions that SLH-DSA improves authenticity in TLS connections for the *data carried over the connection*. It doesn't. > > -Tiru > >> >> > >> > 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 -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
