We actually have RECOMMENDED = Y/N/D and MTI = MUST/SHOULD. I agree wih EKR that this is enough.
Stephen Farrell wrote: >so we ought give such folks guidance to not turn that on I don't see any reason to give such guidance for the key exchange algorithms in draft-connolly-tls-mlkem-key-agreement, which are registered as RECOMMENDED=N. draft-farrell-tls-pqg-00 states: >We recommend taking no action at all at this point in time in relation to >signatures. I disagree with such a recommendation. I don't see any reason for such a recommendation and migrating PKI takes time. From: Eric Rescorla <e...@rtfm.com> Date: Sunday, 15 December 2024 at 21:24 To: Stephen Farrell <stephen.farr...@cs.tcd.ie> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS] Re: Fwd: New Version Notification for draft-farrell-tls-pqg-00.txt 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
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
