RFC 8672

TLS Server Identity Pinning with Tickets, October 2019

File formats:

icon for HTML icon for text file icon for v3pdf icon for XML
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.




Advanced Search