Visual RFC.
ALL RFCs / RFC 8996
Read the RFC ↗
RFC 8996 / TRANSPORT SECURITY

Why retire a working protocol?

01

Old cryptographic dependencies and compatibility code increase risk even when a connection still succeeds.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 1 ↗
RFC 8996 · § 1EXAMPLE
3 / 3
Why retire a working protocol?Old cryptographic dependencies and compatibility code increase risk even when a connection still succeeds. Current state: Use the remaining secure transport options..Why retire a working protocol?Legacy optionsSupported policyTLS 1.0TLS 1.1Modern TLSWorking interoperability is not sufficient security policy.
03
Use the remaining secure transport options.

A successful connection is useful only within an acceptable security policy.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Reduce the number of insecure options.

  • TLS 1.0 and 1.1 lack support for current recommended cryptographic mechanisms.
  • Old handshake integrity and authentication depend on SHA-1; TLS 1.0 also lacks per-record CBC initialization vectors.
  • Removing old versions reduces downgrade opportunities and configuration burden.
DETAILS

This RFC is a deprecation policy, not the TLS 1.2 or TLS 1.3 wire-protocol specification.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Why retire a working protocol?
  2. Reject TLS 1.0 negotiation
  3. Reject TLS 1.1 negotiation
  4. DTLS is included too
  5. What changes for OAuth?
  6. Migration, fallback, and operations
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗