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
