On Mon, May 19, 2025 at 08:08:27AM -0000, D. J. Bernstein wrote:
> Viktor Dukhovni writes:
> > For this to be urgent the devices in question would need to have a
> > very long shelf-life with no opportunity for software updates once
> > provisioned.
>
> Isn't this also an argument to delay the ML-DSA draft?
Yes, a similar argument can be made that ML-DSA is not urgent. However,
it seems prudent to prioritise the algorithms and pipeline the process.
Since ML-DSA is much more "TLS-friendly" algorithm than SLH-DSA, it
makes some sense to consider it first, and SLH-DSA some time later.
> I realize that the current call is regarding SLH-DSA, but ensuring
> consistency requires comparing multiple decisions. We heard "Are we
> likely to produce a materially different spec if this is delayed and for
> how long?" regarding ML-DSA, but this also seems applicable to SLH-DSA.
> Now we're hearing software updates as an argument in the opposite
> direction regarding SLH-DSA, but this also seems applicable to ML-DSA.
It seems unlikely that SLH-DSA will gain much traction in TLS outside
some niche deployments, hence the view that it (potentially up to 12
variants) can be considered some time after we get ML-DSA throug the
process.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
