Summary

  • RFC 9662 adds a forward-secret ECDHE/GCM suite to the secure-syslog interoperability floor, preserves the older RSA/CBC suite for migration, and draws different version rules for TLS and DTLS.
  • Support, configuration, offer, preference and negotiation are separate facts; none proves that a particular syslog event reached the intended collector or survived in searchable storage.
  • A useful receipt joins the endpoint policy and connection epoch to peer validation, event identity, send result, collector acceptance, durable indexing and readback.

The security console showed a clean result: TLS 1.3, a modern suite and a valid certificate. The incident review found a different fact. The event that should have explained the first six minutes of the outage was not in the archive.

Both observations could be true. A handshake describes a channel. It does not describe every message expected to cross it, nor what happened after the collector received—or failed to receive—those messages.

RFC 9662 updates the cryptographic interoperability rules for syslog transported over TLS and DTLS. It responds to an installed base whose earlier specifications centered TLS_RSA_WITH_AES_128_CBC_SHA, a suite without forward secrecy, and whose datagram mapping still required DTLS 1.0. The repair is deliberately evolutionary. It strengthens the common floor without pretending that every legacy device can change in one maintenance window.

That restraint is valuable. It also creates a management trap. A dashboard can show “RFC 9662 compliant” while hiding whether the connection used the preferred option, whether an exception remains open, whether the peer identity was checked correctly, and whether the events arrived.

Five verbs that must not collapse into one

The first verb is implement. RFC 9662 makes both TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_128_CBC_SHA mandatory to implement for the updated mappings. That requirement preserves a shared technical vocabulary. It does not require every administrator to enable both suites on every interface.

The second verb is configure. A product may contain code for a suite that local policy disables. Conversely, a copied configuration may enable a legacy suite after the reason for the exception has disappeared. Configuration is a local choice with an owner and a revision, not a property inherited forever from the standard.

The third verb is offer. The TLS mapping should offer the ECDHE/GCM suite and may offer the RSA/CBC suite. An offered suite is a proposal in one handshake. It says nothing about what the peer also offered or what the negotiation selected.

The fourth verb is prefer. RFC 9662 requires the modern ECDHE/GCM option to be preferred in the migration pair. Preference matters only when both sides can reach that choice. A fleet inventory that says “supported” can still conceal a collector, proxy, old firmware branch or policy order that makes the legacy result win.

The fifth verb is negotiate. A captured ServerHello or equivalent connection record can establish the selected version and suite for that connection epoch. It cannot establish that the intended certificate identity was authorized for the service, that a later reconnect chose the same parameters, or that event 7f3a ever entered the protected channel.

These verbs belong in separate fields. Turning them into one green control destroys the evidence needed to decide whether the problem is product capability, local policy, peer overlap or message delivery.

TLS and DTLS no longer share the same migration sentence

For the TLS transport mapping, TLS 1.2 remains mandatory to implement. TLS 1.3 should be supported and, when present, must be preferred over older TLS versions. That is a clear floor and direction of travel. It is not a declaration that every secure-syslog session now uses TLS 1.3.

The DTLS transport mapping changes more sharply. DTLS 1.0 must not be used; DTLS 1.2 must be used. DTLS 1.3 should be supported and preferred when implemented. The reason is not stylistic. RFC 8996 deprecated the old protocol versions, while RFC 9325 provides the broader secure-use guidance.

An audit therefore needs the transport before it interprets the version. “1.2” cannot stand alone: TLS 1.2 and DTLS 1.2 have different session, loss and delivery surfaces. A datagram send does not acquire stream acknowledgement merely because DTLS protected it. A long-lived TLS connection does not prove that the application queue remained healthy merely because the socket stayed open.

The underlying version documents—TLS 1.2, DTLS 1.2, TLS 1.3 and DTLS 1.3—describe cryptographic transports. They do not add an end-to-end acknowledgement from the event source to a retained search result.

The legacy suite is an exception with a purpose, not an invisible failure

RFC 9662 does not simply ban the older RSA/CBC suite. It recognizes that a device may only possess that option and tells the administrator to evaluate whether allowing it is necessary so that syslog messages continue to be delivered until the device is updated.

This is a continuity judgment. Denying the only common suite can improve the apparent cryptographic score while cutting off the evidence needed to operate or investigate the device. Allowing it indefinitely can turn a temporary bridge into unowned exposure. The correct record therefore contains both halves: why delivery would otherwise fail, and when the exception ends.

A defensible exception names the device class, software version, collector boundary, permitted peer, transport, suite, compensating controls, owner, approval time, expiry and upgrade test. It also records actual use. An exception that is never selected may be removable; an exception selected every hour identifies a migration dependency. Neither conclusion can be obtained from a policy file alone.

The IANA TLS registry coordinates identifiers and status information. It cannot say which endpoints enabled an algorithm, which pair negotiated it or why an administrator accepted it. Registry, product, configuration and live connection are different evidence layers.

No early data means exactly that

TLS 1.3 permits early data under defined PSK conditions. RFC 9662 prohibits it for secure syslog. The profile points to the weaker properties of early data and to the fact that the syslog protocol does not supply replay protection. A repeated early event could create a false incident count or duplicate an action triggered by log processing.

The prohibition closes one dangerous path. It does not give ordinary post-handshake syslog messages exactly-once semantics. Events can still be duplicated before encryption, retried after an ambiguous failure, lost under queue pressure, dropped in a datagram path, rejected by a collector, written to the wrong tenant, aged out early or made unsearchable by an indexing fault.

Testing should therefore prove two different claims. First, a client must not send secure-syslog application data as early data, and a collector must not accept it as such. Second, the normal post-handshake path must preserve a test event from creation through collector acceptance and durable readback. Passing the first test never marks the second green.

Authentication ends before retention

Secure syslog also depends on certificate validation. RFC 5280 supplies the certificate and path-validation framework, while the transport mappings define their syslog use. A certificate chain can be cryptographically valid yet terminate at an unintended trust anchor, present the wrong service identity, or authenticate a peer that local authorization should not accept.

Even correct peer authentication is only a channel fact. The event needs its own identity. At minimum, keep a privacy-safe source identifier, device clock and sequence context, creation time, queue time, connection epoch, send attempt, collector acceptance identifier, durable-write result, index destination, retention class and later readback result. If payload secrecy prevents retaining full test content, a salted marker can still join the records.

The result should preserve honest failure classes: no shared suite, prohibited version, certificate-path failure, reference-identity failure, unauthorized peer, forbidden early data, connection break, queue overflow, datagram loss, collector rejection, storage failure, indexing mismatch and missing readback. “Secure syslog failed” is too coarse to assign custody.

Build the receipt from the search result backward

Start with the outcome leadership actually needs: could an authorized investigator retrieve the expected event inside the promised retention window? Resolve that event to the durable object and collector acceptance record. Resolve acceptance to a transport send, connection epoch and source queue record. Resolve the connection to the negotiated version, suite, resumption and early-data state, peer certificate and local policy revision. Finally, resolve policy exceptions to owners and expiry.

This reverse chain prevents a common substitution. The cryptographic team can prove a modern handshake; the logging team can prove a collector process was healthy; the storage team can prove the index existed. Only the joined event identity proves that the relevant record crossed all three boundaries.

Heng Lu’s Minimum Initial Specification supplies the right institutional proportion: standardize the small common floor, then leave local deployment choices visible and accountable. Reality Layers prevents a standards label from borrowing the authority of a live result. Running-Code Primacy puts the decisive observation in the system that negotiated, carried, accepted and retained the event.

RFC 9662 makes secure-syslog interoperability safer without denying migration reality. Leadership should respect both parts of that achievement. The standard can define the cryptographic choices a pair must share. Only the operating path can prove which choice was made and whether the log survived.

Sources