Updates to the Cipher Suites in Secure Syslog
updates
Extracted elements (15)
Because many deployed syslog implementations use TLS_RSA_WITH_AES_128_CBC_SHA as mandated by RFC 6012, a sudden deprecation is undesirable. Both cipher suites are therefore permitted during migration, but TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 MUST be preferred to allow gradual transition.
Early data (0-RTT) is prohibited in secure syslog because syslog lacks replay protection (per Section 8.4 of RFC 5424) and the security properties of early data are weaker—specifically, it is not forward secret and provides no protection against replay between connections.
Moving to an ECDHE cipher suite does not require replacing existing RSA-based certificates, since ECDHE cipher suites exist for both RSA and ECDSA certificates. This lowers the migration barrier for deployed devices.
TLS_RSA_WITH_AES_128_CBC_SHA does not provide forward secrecy, which is highly desirable for securing event messages. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 provides forward secrecy and is a currently RECOMMENDED algorithm per RFC 8447bis.
RFC 8996 (BCP 195) deprecates DTLS 1.0, which was the mandatory-to-implement transport per RFC 6012; this document therefore mandates DTLS 1.2 as the new minimum, breaking backward compatibility with DTLS 1.0-only implementations.
To maintain interoperability across implementations, both TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA are mandatory-to-implement; either may be used, but the ECDHE suite must be preferred so that implementations interoperate while providing an acceptable level of security.
Implementations MUST NOT use early data (0-RTT data as defined in TLS 1.3), because syslog does not support replay protection and most implementations establish long-lived connections.
Implementations of RFC 5425 MUST continue to use TLS 1.2 as the mandatory-to-implement transport protocol, SHOULD support TLS 1.3, and if TLS 1.3 is implemented, MUST prefer to negotiate TLS 1.3 over earlier versions.
Implementations of RFC 5425 (TLS syslog) MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA as mandatory-to-implement cipher suites; implementations SHOULD offer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 but MAY offer TLS_RSA_WITH_AES_128_CBC_SHA.
Implementations of RFC 6012 are REQUIRED to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA as mandatory-to-implement cipher suites; implementations SHOULD offer the ECDHE suite but MAY offer TLS_RSA_WITH_AES_128_CBC_SHA.
Implementations of RFC 6012 (DTLS syslog) MUST NOT use DTLS 1.0 and MUST use DTLS 1.2; DTLS 1.2 implementations SHOULD support and prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Implementations of RFC 6012 SHOULD support DTLS 1.3 and, if implemented, MUST prefer to negotiate DTLS 1.3 over earlier versions of DTLS.
Syslog clients and servers MUST use certificates as defined in RFC 5280 (PKIX). This applies to both TLS and DTLS syslog implementations.
The installed base of syslog implementations cannot immediately migrate from deprecated cipher suites and DTLS 1.0. This document allows TLS_RSA_WITH_AES_128_CBC_SHA as a transitional measure; administrators must evaluate whether to permit it until devices are updated to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
TLS_RSA_WITH_AES_128_CBC_SHA may require mitigation techniques to achieve expected security and does not provide forward secrecy; implementations should prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which provides forward secrecy and is currently RECOMMENDED.