On Wed, 21 May 2025 at 18:14, Watson Ladd <[email protected]> wrote:
> On Mon, May 19, 2025 at 2:30 AM tirumal reddy <[email protected]> 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. -Tiru > > > > Cheers, > > -Tiru > > > > On Sat, 17 May 2025 at 19:30, Mike Ounsworth <[email protected]> > 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= > [email protected]> 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 -- [email protected] > >>> To unsubscribe send an email to [email protected] > > > > _______________________________________________ > > TLS mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > -- > Astra mortemque praestare gradatim >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
