The Transport Layer Security (TLS) Protocol Version 1.3¶
Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC Editor / IETF.
Cited by¶
8 citations across 8 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Authentication
- The freshness condition resists replay: the server signs a client-supplied nonce, so a recording of a past valid handshake cannot be replayed to impersonate the server.
Supported in partVerified against the work's full text
RFC 8446 discusses freshness and replay in the TLS 1.3 handshake, noting freshness checking alone does not prevent replays; it does not state the server-signed-nonce mechanism.
“Note that freshness checking alone is not sufficient to prevent replays because it does not detect them during the error window, which -- depending on bandwidth and system capacity -- could include billions of replays in real-world settings.”
- The freshness condition resists replay: the server signs a client-supplied nonce, so a recording of a past valid handshake cannot be replayed to impersonate the server.
- Common Ground
- Team coordination: high-performing teams develop dense common ground — shared vocabulary, shared mental models, shared knowledge of who knows what — that supports the fast, elliptical communication distinguishing them from teams that must spell everything out; the ground collapses silently in crisis, after onboarding, or across silos. Cryptography and security: trust establishment builds common ground about identity, keys, and protocol versions through a handshake, and mismatched assumed common ground is the failure mode many attacks exploit.
This sourceSpecifies the TLS handshake, which authenticates the parties and negotiates keys, cipher suite, and protocol version, and is designed to resist tampering and downgrade attacks — building common ground about identity, keys, and version, with mismatched/forced parameters as the exploited failure mode.
Supported in partVerified against the work's full text
RFC 8446 states the handshake authenticates the parties and negotiates keys, cipher suite and version, but does not state that mismatched assumed common ground is the failure mode many attacks exploit.
“A handshake protocol ( Section 4 ) that authenticates the communicating parties, negotiates cryptographic modes and parameters, and establishes shared keying material.”
- Team coordination: high-performing teams develop dense common ground — shared vocabulary, shared mental models, shared knowledge of who knows what — that supports the fast, elliptical communication distinguishing them from teams that must spell everything out; the ground collapses silently in crisis, after onboarding, or across silos. Cryptography and security: trust establishment builds common ground about identity, keys, and protocol versions through a handshake, and mismatched assumed common ground is the failure mode many attacks exploit.
- Green-Beard Effect
- In multi-agent systems and distributed computing, cryptographic credentials — signed certificates, group memberships, zero-knowledge proofs of membership, webs of trust — function as inspect-once tokens admitting a counterparty to a cooperative protocol without prior reputation.
This sourceSpecifies certificate-based (and mutual) authentication via signed certificates validated against a trust anchor in the handshake, admitting peers to the protocol without prior reputation.
Supported in partVerified against the work's full text
RFC 8446 has certificates verified against a trusted CA trust anchor and peers authenticated in the handshake, but never states every party presents one or that no prior interaction is presupposed.
“Implementations are responsible for verifying the integrity of certificates and should generally support certificate revocation messages. Absent a specific indication from an application profile, certificates should always be verified to ensure proper signing by a trusted certificate authority (CA). The selection and addition of trust anchors should be done very carefully.”
- In multi-agent systems and distributed computing, cryptographic credentials — signed certificates, group memberships, zero-knowledge proofs of membership, webs of trust — function as inspect-once tokens admitting a counterparty to a cooperative protocol without prior reputation.
Mechanisms¶
- Protocol Version Negotiation
- The handshake is an attack and failure surface: an unauthenticated advertisement can be spoofed, and a downgrade attack can force both ends onto the weakest common version, so the negotiation must be integrity-protected rather than trusted.
This sourceSpecifies TLS version negotiation and authenticated downgrade protections intended to prevent an active attacker from forcing endpoints onto an older protocol version.
- The handshake is an attack and failure surface: an unauthenticated advertisement can be spoofed, and a downgrade attack can force both ends onto the weakest common version, so the negotiation must be integrity-protected rather than trusted.
- Response Padding or Coarsening
- Message length leaking through encryption is a staple of traffic analysis, and length padding is its standard countermeasure.
This sourceSpecifies application-data padding to conceal observable record lengths and limit traffic-analysis leakage.
- Message length leaking through encryption is a staple of traffic analysis, and length padding is its standard countermeasure.
- Version Negotiation Handshake
- Because the negotiated choice is bound into the handshake, a meddler on the wire cannot quietly force both ends down to a weaker version they would not have chosen.
This sourceSpecifies authenticated handshake protections intended to prevent an on-path attacker from forcing newer TLS peers to negotiate an unintended weaker version.
- Because the negotiated choice is bound into the handshake, a meddler on the wire cannot quietly force both ends down to a weaker version they would not have chosen.
- Version Negotiation or Capability Probe
- A middleman that tampers with the advertised capabilities can force both ends down to the weakest mutually-supported option — a downgrade attack
This sourceDefines downgrade attacks in version negotiation and the protocol checks used to prevent an active intermediary from forcing an older mutually supported version.
- A middleman that tampers with the advertised capabilities can force both ends down to the weakest mutually-supported option — a downgrade attack
- Version Negotiation Scheme
- Generous downgrade support keeps everyone connected but preserves obsolete, sometimes insecure, behaviour indefinitely, and an attacker who can tamper with the handshake may force a downgrade attack
This sourceSpecifies TLS 1.3 protections against an active attacker forcing negotiation to a lower mutually supported version.
- Generous downgrade support keeps everyone connected but preserves obsolete, sometimes insecure, behaviour indefinitely, and an attacker who can tamper with the handshake may force a downgrade attack
Verification¶
Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.
Does it back the claim? Read against the text for 3 of 8 citations: 3 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Links previously used in the corpus¶
Before the registry existed this work was also linked 4 other ways.
- https://doi.org/10.17487/RFC8446 ×2
- https://www.rfc-editor.org/info/rfc8446 ×2
- https://www.rfc-editor.org/info/rfc8446/ ×1
- https://www.rfc-editor.org/rfc/rfc8446 ×1
Registry ID ref:a7b9a5345e69 · see in the full table