I’m with Ekr on this – his points are right on. And disagree with Stephen – Eric explained why clearly enough.
On Sun, Dec 15, 2024 at 12:13 PM Stephen Farrell <stephen.farr...@cs.tcd.ie <mailto:stephen.farr...@cs.tcd.ie>> wrote: Hiya, Answering a few points at once: On 15/12/2024 17:05, Eric Rescorla wrote: > I don't think it's a good use of the WG's time to put out this kind > of guidance statement. Rather, we should simply adopt some subset of > the proposed drafts. The Recommended column in the code point > registry serves as the TLS WG's recommendation. I don't think that mechanism is quite sufficient here, for at least two reasons: 1) if we e.g. add recommended=y for X25519MLKEM768, that'd mean we now have 5 such groups all with recommended=y so we're still missing guidance required amongst those which becomes a thing we do care about whereas we more or less didn't when we only had 4. 2) if someone can do X25519MLKEM768, then they can also do MLKEM768 which (let's assume) remains recommended=n, so we ought give such folks guidance to not turn that on (if we end up with consensus to say that). I don't agree with either of these points. We already have MTI and Recommended=Y, which are sufficient to (1) provide interop and (2) to indicate what the TLS WG thinks is safe. I don't think it's helpful for us to try to make ever finer-distinctions of either Recommended=Y or Recommended=N. Moreover, as the discussion so far shows, trying to draw these distinctions has a high risk of being an attractive nuisance. -Ekr
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
