On Tue, 27 May 2025 at 23:57, Watson Ladd <watsonbl...@gmail.com> wrote:
> 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. > To clarify, the draft does not make any claims that SLH-DSA improves the authenticity of the data transmitted over the TLS connection. If any part of the text appears to imply otherwise, we’re happy to revise it. -Tiru > > > > > -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
