RSA key exchange are the worst ciphersuites you can possibly use, they
should
be MUST NOT as anything else is an improvement.
If that's the only interoperable ciphersuite that's available in the
environment
that the administrator is configuring, they'll ignore any guidance anyway.
On Wednesday, 6 September 2023 22:14:54 CEST, Chris Lonvick wrote:
Hi Ilari,
If a syslog server MUST NOT offer the only cipher suite that an
associated client has available then the client will not be able
to securely convey syslog messages to that server. That would
break things. Changing that to "SHOULD NOT" allows an
administrator to evaluate the risks. The administrator would
then be able to decide if the client has to be upgraded to use a
secure cipher suite, or if it acceptable for a time to continue
using a cipher suite with known problems.
Best regards,
Chris
On Wed, Sep 6, 2023 at 1:07 PM Ilari Liusvaara
<ilariliusva...@welho.com> 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.
How would having a MUST NOT break things? Servers are already required
to ignore any unsupported or disabled ciphersuites.
-Ilari
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
