On Fri, Jun 12, 2026 at 7:43 AM Ilari Liusvaara <[email protected]> wrote:
> On Thu, Jun 11, 2026 at 11:45:08AM -0400, David Benjamin wrote: > > > Implementations should not rely on the protcool layer for security. > > > And protocol layer should not rely on implementation internals. > > > > I agree with this. Just as we don't rely on the protocol layer to secure > > the implementation of the underlying algorithm, we also don't need to > rely > > on the protocol layer to specify the underlying algorithm. > > The second part is not about "need", but about what REALLY SHOULD NOT be > done. Placing requirements on implementations beyond the underlying > specifications is a Really Bad Idea. That one would "need" to do so is a > Major Red Flag (either that the protocol or the algorithm is bad). > > And in the first part, there is difference between implementation > relying on protocol (which is bad, and the implementation should be > fixed) and underlying specification relying on the protocol, which is > another Major Red Flag. > I *think* we're agreeing but I'm not sure? I don't think PR #36 makes sense since I don't see any reason to *weaken* FIPS 204's requirements on account of TLS's randomness. I also didn't see a reason, myself, to strengthen FIPS 204's requirements, but.... > > Practically speaking, the TLS layer does not implement ML-DSA directly. > It > > calls into the ML-DSA implementation. If the ML-DSA spec failed to > capture > > this, by the time the TLS implementor goes to look at the TLS spec, > we're a > > few layers past ML-DSA. Decisions about hedged vs deterministic have > > probably already been made. > > > > Happily, FIPS 204 talks about this *already* in section 3.4: > > Yes, However, at least three people were still confused, thinking that > deterministic vs. hedged somehow matters for TLS. Which would be really > bad if true. > I mean, I don't think it TLS has any special considerations that warrant deviating from FIPS 204, but perhaps something like this would make people happy? (Unless I'm completely misunderstanding your point.) https://github.com/tlswg/tls-mldsa/pull/39 David
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
