Hi Viktor and all, I see your point.
How about if the phrases "MUST NOT offer TLS_RSA_WITH_AES_128_CBC_SHA" in Sections 4 and 5 be changed to "SHOULD NOT offer..."? This seems to be more consistent with Section 4.2.1 of RFC 9325 (BCP 195) and will continue to allow devices to offer that algorithm --and allow log messages to continue to be delivered during a transition. We're still looking for more reviews and discussion on this topic. Best regards, Chris On Thu, Aug 31, 2023 at 11:42 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Mon, Aug 21, 2023 at 07:16:01AM -0400, Chris Lonvick wrote: > > > We think that this version is ready for WG Last Call. Would the members > of > > the WG please review and let us know (on the WG list) if there are any > > objections? > > > > The draft looks clear enough. My main concern is not with readyness, > but with the statement that the previous MTI ciphers MUST NOT be used. > > Such a radical compatibility break does not on the face of it look > justified. It would I believe be sufficient to say that they MUST offer > and prefer the new MTI algorithms. Which is enough to ensure an orderly > transition to the new algorithms, without breaking interoperability. > > The availability of logs can be more important than their > confidentiality in transit. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
