[TLS] Re: WG Adoption Call for Use of SLH-DSA in TLS 1.3

[Watson Ladd <[e-mail]>]

On Sun, May 25, 2025 at 10:55 PM tirumal reddy <[e-mail]> wrote:
>
> On Wed, 21 May 2025 at 18:14, Watson Ladd <[e-mail]> wrote:
>>
>> On Mon, May 19, 2025 at 2:30 AM tirumal reddy <[e-mail]> 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 <[e-mail]> 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=[e-mail]> 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 -- [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



-- 
Astra mortemque praestare gradatim