RFC 8672
TLS Server Identity Pinning with Tickets, October 2019
- File formats:
- Also available: XML file for editing
- Status:
- EXPERIMENTAL
- Authors:
- Y. Sheffer
D. Migault - Stream:
- INDEPENDENT
Cite this RFC: TXT | XML | BibTeX
DOI: https://doi.org/10.17487/RFC8672
Discuss this RFC: Send questions or comments to the mailing list rfc-ise@rfc-editor.org
Other actions: Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 8672
Abstract
Misissued public-key certificates can prevent TLS clients from appropriately authenticating the TLS server. Several alternatives have been proposed to detect this situation and prevent a client from establishing a TLS session with a TLS end point authenticated with an illegitimate public-key certificate. These mechanisms are either not widely deployed or limited to public web browsing.
This document proposes experimental extensions to TLS with opaque pinning tickets as a way to pin the server's identity. During an initial TLS session, the server provides an original encrypted pinning ticket. In subsequent TLS session establishment, upon receipt of the pinning ticket, the server proves its ability to decrypt the pinning ticket and thus the ownership of the pinning protection key. The client can now safely conclude that the TLS session is established with the same TLS server as the original TLS session. One of the important properties of this proposal is that no manual management actions are required.
For the definition of Status, see RFC 2026.
For the definition of Stream, see RFC 8729.