Before this goes any further, perhaps I should clarify the context of my comment.
Me: >>> I agree that there’s an argument for using SLH-DSA >>> in root certificates, but I’m surprised it’s being >>> proposed for the full chain. Tiru: >> SLH-DSA is not proposed for the end-entity certificates, >> it is preferred for CA certificates (please see the 3rd >> paragraph in [draft-section 2]). Me: > if you are not proposing SLH-DSA end-entity certificates > then you need to be more explicit that it is not recommended > for use in signature_algorithms. Yes, I’m surprised but at no point am I suggesting that SLH-DSA should be withheld, just that the draft should be explicit about what is or is not being proposed. The conditional in the final quote is fairly important. Thanks, Peter From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> Sent: 04 November 2024 17:37 To: tls@ietf.org Subject: [TLS] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt On Mon, Nov 4, 2024 at 6:31 PM D. J. Bernstein <d...@cr.yp.to<mailto:d...@cr.yp.to>> wrote: Speaking for myself, not on behalf of the SPHINCS+ team (or other teams potentially relevant here). Peter C writes: > Under realistic network conditions, TLS handshakes with full SLH-DSA > certificate chains seem to be about 5-10 times slower than traditional > certificate chains and, in some cases, can take on the order of > seconds. For, e.g., sphincsf128shake256simple, a quad-core 3GHz Intel Skylake from 2015 handles 85 signatures per second and 1300 verifications per second. (Source: dividing 12 billion cycles/second by the cycle counts given in https://bench.cr.yp.to/results-sign/amd64-samba.html.) Sure, one can come up with scenarios where this isn't fast enough or where 17KB for a signature is a problem. But there are also environments where these costs are negligible compared to the transmission and processing of user data. Agreed. That SLH-DSA is clearly not suited for all use cases for TLS, doesn't mean we should withhold it for those where it's acceptable.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
