TLS Server Identity Pinning with Tickets
RFC 8672

Document Type RFC - Experimental (October 2019; No errata)
Authors Yaron Sheffer  , Daniel Migault 
Last updated 2019-10-31
Stream ISE
Formats plain text html xml pdf htmlized bibtex
IETF conflict review conflict-review-sheffer-tls-pinning-ticket
Stream ISE state Published RFC
Consensus Boilerplate Unknown
Document shepherd Adrian Farrel
Shepherd write-up Show (last changed 2019-05-25)
IESG IESG state RFC 8672 (Experimental)
Telechat date
Responsible AD (None)
Send notices to Adrian Farrel <>
IANA IANA review state IANA OK - Actions Needed
IANA action state RFC-Ed-Ack

Independent Submission                                        Y. Sheffer
Request for Comments: 8672                                        Intuit
Category: Experimental                                        D. Migault
ISSN: 2070-1721                                                 Ericsson
                                                            October 2019

                TLS Server Identity Pinning with Tickets


   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.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not candidates for any level of Internet Standard;
   see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

Table of Contents

   1.  Introduction
     1.1.  Conventions Used in This Document
     1.2.  Scope of Experimentation
   2.  Protocol Overview
     2.1.  Initial Connection
     2.2.  Subsequent Connections
     2.3.  Indexing the Pins
   3.  Message Definitions
   4.  Cryptographic Operations
     4.1.  Pinning Secret
     4.2.  Pinning Ticket
     4.3.  Pinning Protection Key
     4.4.  Pinning Proof
   5.  Operational Considerations
     5.1.  Protection Key Synchronization
     5.2.  Ticket Lifetime
     5.3.  Certificate Renewal
     5.4.  Certificate Revocation
     5.5.  Disabling Pinning
     5.6.  Server Compromise
     5.7.  Disaster Recovery
   6.  Security Considerations
     6.1.  Trust-on-First-Use (TOFU) and MITM Attacks
     6.2.  Pervasive Monitoring
     6.3.  Server-Side Error Detection
     6.4.  Client Policy and SSL Proxies
     6.5.  Client-Side Error Behavior
     6.6.  Stolen and Forged Tickets
     6.7.  Client Privacy
     6.8.  Ticket Protection Key Management
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Appendix A.  Previous Work
     A.1.  Comparison: HPKP
     A.2.  Comparison: TACK
   Authors' Addresses

1.  Introduction

   Misissued public-key certificates can prevent TLS [RFC8446] clients
   from appropriately authenticating the TLS server.  This is a
   significant risk in the context of the global public key
   infrastructure (PKI), and similarly for large-scale deployments of
   certificates within enterprises.

   This document proposes experimental extensions to TLS with opaque
   pinning tickets as a way to pin the server's identity.  The approach
   is intended to be easy to implement and deploy, and reuses some of
   the ideas behind TLS session resumption [RFC5077].

   Ticket pinning is a second-factor server authentication method and is
   not proposed as a substitute for the authentication method provided
   in the TLS key exchange.  More specifically, the client only uses the
   pinning identity method after the TLS key exchange is successfully
   completed.  In other words, the pinning identity method is only
   performed over an authenticated TLS session.  Note that ticket
Show full document text