Summary

  • RFC 9852 / BCP 195, co-authored by Rich Salz and Nimrod Aviram, says a new protocol using TLS must assume TLS 1.3 is available and specify TLS 1.3 as its default. The rule governs the protocol specification being written.
  • A specification requirement is not a receipt from a running endpoint. Negotiated version, endpoint configuration, peer authentication, application acceptance and recovery evidence remain separate facts. RFC 9852 also explicitly excludes DTLS from this prescription.

The word require has a useful force in standards work. It stops an author of a new protocol from treating a known choice as if it were still neutral. It lets implementations and reviewers know the baseline the protocol is meant to demand. But it can create a different mistake when it leaves the document and reaches a status report: someone reads a normative requirement as though it were a completed observation about a service.

RFC 9852, New Protocols Using TLS Must Require TLS 1.3, is an IETF Best Current Practice, BCP 195. Rich Salz and Nimrod Aviram are named as its authors; the RFC is an IETF consensus document, not an individual deployment statement. Its central instruction is deliberately directed at a specific object: a new protocol that uses TLS must assume TLS 1.3 is available and must specify TLS 1.3 as its default. That is a disciplined answer to a design question: what should the next protocol document require?

It is not an answer to every operational question that follows. A protocol text can require TLS 1.3 while an operator still needs to know what version a particular client and endpoint actually negotiated. It can say how a new protocol should be designed while leaving separate the local configuration that selects policy, the certificate and peer-authentication path appropriate to the service, the application behavior after a handshake, and the evidence that a failure was detected and recovered. Those questions are not defects in the BCP. They belong to different owners and are demonstrated through different artifacts.

The RFC’s scope matters as much as its imperative. It says its prescription pertains to TLS only. Because DTLS 1.3 is not widely available or deployed, the document says the requirement does not pertain to DTLS in any version. That sentence prevents a reader from turning a rule for newly specified TLS protocols into a blanket conclusion about every datagram protocol. A broad label such as “TLS 1.3 mandated” hides precisely the boundary that the RFC makes explicit.

The rationale is also narrower than a deployment certificate. RFC 9852 says TLS 1.3 is widely used, has comprehensive security proofs and improves security and privacy deficiencies in TLS 1.2. It contrasts this with TLS 1.2, which can be configured to provide good properties but typically requires bespoke configuration to address deficiencies. It also identifies post-quantum migration as an important consideration while placing detailed determinations about when a particular application needs PQC outside its scope. These are reasons for the design rule, not telemetry from a named service.

That separation is the point of Running-Code Primacy. A design rule establishes what a future protocol should state. A configuration record establishes what an operator intended at a controlled endpoint. A handshake observation establishes a negotiated fact for a particular connection. Authentication and authorization records establish their own conditions. Application behavior and recovery observations establish yet other facts. None needs to be diminished for the others to remain visible. The error is to let one artifact silently stand in for all of them.

For a protocol designer, the practical conclusion is direct: follow BCP 195 when defining a new TLS-using protocol and write the TLS 1.3 default plainly. For an operator or reviewer, the conclusion is equally direct but distinct: report an implementation or deployment only when the relevant operational joins can be inspected. Retain the intended policy, the observed negotiations at the endpoints that matter, any needed authentication result, the application-level consequence and the recovery trail. A rule in an RFC and a receipt from a system can then reinforce each other without being confused.

Sources