Hi Viktor, Your comments didn't go unnoticed.
I think that the changes to Sections 4 and 5 should be limited to replacing "MUST NOT" with "SHOULD NOT". That will provide clear guidance for implementers. I was then thinking of changing the Security Considerations section to the following: ---vvv--- 10. Security Considerations [BCP195] deprecates an insecure DTLS transport protocol from [RFC6012] and deprecates insecure cipher suits from [RFC5425] and [RFC6012]. This document specifies mandatory to implement cipher suites to those RFCs and the latest version of the DTLS protocol to [RFC6012]. The insecure cipher suites SHOULD NOT be offered. If a device currently only has an insecure cipher suite, an administrator of the network should evaluate the conditions and determine if the insecure cipher suite should be allowed so that syslog messages may continue to be delivered until the device is updated to have a secure cipher suite. ---^^^--- Please comment and suggest any further edits for WG review. Best regards, Chris On Sun, Sep 17, 2023 at 9:26 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > On Wed, Sep 06, 2023 at 12:53:39PM -0400, Chris Lonvick wrote: > > > 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. > > I do think that "SHOULD NOT" is a step in the right direction. And I > expect, based on prior experience with other IETF deprecation > activities, that this is likely the best bargain I can hope to reach. > > However, a close reading of my orignal post will show that I believe > that even that is needlessly prescriptive. > > Security improves primarily when we raise the ceiling, not the floor > (there are exceptions when not raising the floor opens opportunities for > downgrade or cross-protocol attacks). > > The outcome we're looking for is that stronger ciphers be implemented > and used. Punishing the long tail of slow adopters is rather a > secondary goal. > > And IMHO with syslog, where I would prioritise availability over maximal > channel security, if this were my text to write, I'd would say: > > * Peers MUST implement the new MTI ciphers (tautology given MTI). > > * Must negotiate the MTI ciphers in preference to the deprecated > ciphers (MAY also negotiate equally strong or stronger > alternatives to the MIT ciphers). > > Note, this does not say anything about requiring non-support of the > legacy ciphers. But it could be reasonable to add: > > * Operators SHOULD consider disabling the deprecated ciphers once > no longer needed to support any of the expected clients. > > In other words, an orderly transition with no disruptive removal of > interoperability before all the expected peers are ready. > > -- > 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
