File: rfc8672.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2496 lines) | stat: -rw-r--r-- 120,018 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8672: TLS Server Identity Pinning with Tickets</title>
<meta content="Yaron Sheffer" name="author">
<meta content="Daniel Migault" name="author">
<meta content="
       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. 
    " name="description">
<meta content="xml2rfc 2.34.0" name="generator">
<meta content="public-key certificates, trust-on-first-use, TOFU" name="keyword">
<meta content="8672" name="rfc.number">
<link href="rfc8672.xml" type="application/rfc+xml" rel="alternate">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin: 0 0 0.25em 0;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8672" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket-12" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8672</td>
<td class="center">Pinning with Tickets</td>
<td class="right">October 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sheffer &amp; Migault</td>
<td class="center">Experimental</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8672" class="eref">8672</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-10" class="published">October 2019</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">Y. Sheffer</div>
<div class="org">Intuit</div>
</div>
<div class="author">
      <div class="author-name">D. Migault</div>
<div class="org">Ericsson</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8672</h1>
<h1 id="title">TLS Server Identity Pinning with Tickets</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">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.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8672">https://www.rfc-editor.org/info/rfc8672</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2019 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (https://trustee.ietf.org/license-info) 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.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-boilerplate.3">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.1">
            <p id="section-boilerplate.3-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-boilerplate.3-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.1.2.1">
                <p id="section-boilerplate.3-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a><a href="#section-boilerplate.3-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.1.2.2">
                <p id="section-boilerplate.3-1.1.2.2.1"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-scope-of-experimentation" class="xref">Scope of Experimentation</a><a href="#section-boilerplate.3-1.1.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.2">
            <p id="section-boilerplate.3-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-boilerplate.3-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.2.2.1">
                <p id="section-boilerplate.3-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-initial-connection" class="xref">Initial Connection</a><a href="#section-boilerplate.3-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.2.2.2">
                <p id="section-boilerplate.3-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-subsequent-connections" class="xref">Subsequent Connections</a><a href="#section-boilerplate.3-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.2.2.3">
                <p id="section-boilerplate.3-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-indexing-the-pins" class="xref">Indexing the Pins</a><a href="#section-boilerplate.3-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.3">
            <p id="section-boilerplate.3-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-message-definitions" class="xref">Message Definitions</a><a href="#section-boilerplate.3-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.4">
            <p id="section-boilerplate.3-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-cryptographic-operations" class="xref">Cryptographic Operations</a><a href="#section-boilerplate.3-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.1">
                <p id="section-boilerplate.3-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-pinning-secret" class="xref">Pinning Secret</a><a href="#section-boilerplate.3-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.2">
                <p id="section-boilerplate.3-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-pinning-ticket" class="xref">Pinning Ticket</a><a href="#section-boilerplate.3-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.3">
                <p id="section-boilerplate.3-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-pinning-protection-key" class="xref">Pinning Protection Key</a><a href="#section-boilerplate.3-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.4.2.4">
                <p id="section-boilerplate.3-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-pinning-proof" class="xref">Pinning Proof</a><a href="#section-boilerplate.3-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.5">
            <p id="section-boilerplate.3-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-operational-considerations" class="xref">Operational Considerations</a><a href="#section-boilerplate.3-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.1">
                <p id="section-boilerplate.3-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-protection-key-synchronizat" class="xref">Protection Key Synchronization</a><a href="#section-boilerplate.3-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.2">
                <p id="section-boilerplate.3-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-ticket-lifetime" class="xref">Ticket Lifetime</a><a href="#section-boilerplate.3-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.3">
                <p id="section-boilerplate.3-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-certificate-renewal" class="xref">Certificate Renewal</a><a href="#section-boilerplate.3-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.4">
                <p id="section-boilerplate.3-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-certificate-revocation" class="xref">Certificate Revocation</a><a href="#section-boilerplate.3-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.5">
                <p id="section-boilerplate.3-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-disabling-pinning" class="xref">Disabling Pinning</a><a href="#section-boilerplate.3-1.5.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.6">
                <p id="section-boilerplate.3-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-server-compromise" class="xref">Server Compromise</a><a href="#section-boilerplate.3-1.5.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.5.2.7">
                <p id="section-boilerplate.3-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-disaster-recovery" class="xref">Disaster Recovery</a><a href="#section-boilerplate.3-1.5.2.7.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.6">
            <p id="section-boilerplate.3-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-boilerplate.3-1.6.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.1">
                <p id="section-boilerplate.3-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-trust-on-first-use-tofu-and" class="xref">Trust-on-First-Use (TOFU) and MITM Attacks</a><a href="#section-boilerplate.3-1.6.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.2">
                <p id="section-boilerplate.3-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-pervasive-monitoring" class="xref">Pervasive Monitoring</a><a href="#section-boilerplate.3-1.6.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.3">
                <p id="section-boilerplate.3-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-server-side-error-detection" class="xref">Server-Side Error Detection</a><a href="#section-boilerplate.3-1.6.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.4">
                <p id="section-boilerplate.3-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-client-policy-and-ssl-proxi" class="xref">Client Policy and SSL Proxies</a><a href="#section-boilerplate.3-1.6.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.5">
                <p id="section-boilerplate.3-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-client-side-error-behavior" class="xref">Client-Side Error Behavior</a><a href="#section-boilerplate.3-1.6.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.6">
                <p id="section-boilerplate.3-1.6.2.6.1"><a href="#section-6.6" class="xref">6.6</a>.  <a href="#name-stolen-and-forged-tickets" class="xref">Stolen and Forged Tickets</a><a href="#section-boilerplate.3-1.6.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.7">
                <p id="section-boilerplate.3-1.6.2.7.1"><a href="#section-6.7" class="xref">6.7</a>.  <a href="#name-client-privacy" class="xref">Client Privacy</a><a href="#section-boilerplate.3-1.6.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.6.2.8">
                <p id="section-boilerplate.3-1.6.2.8.1"><a href="#section-6.8" class="xref">6.8</a>.  <a href="#name-ticket-protection-key-manag" class="xref">Ticket Protection Key Management</a><a href="#section-boilerplate.3-1.6.2.8.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.7">
            <p id="section-boilerplate.3-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-boilerplate.3-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.8">
            <p id="section-boilerplate.3-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-references" class="xref">References</a><a href="#section-boilerplate.3-1.8.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.8.2.1">
                <p id="section-boilerplate.3-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-boilerplate.3-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.8.2.2">
                <p id="section-boilerplate.3-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-boilerplate.3-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.9">
            <p id="section-boilerplate.3-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-previous-work" class="xref">Previous Work</a><a href="#section-boilerplate.3-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-boilerplate.3-1.9.2.1">
                <p id="section-boilerplate.3-1.9.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-comparison-hpkp" class="xref">Comparison: HPKP</a><a href="#section-boilerplate.3-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-boilerplate.3-1.9.2.2">
                <p id="section-boilerplate.3-1.9.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-comparison-tack" class="xref">Comparison: TACK</a><a href="#section-boilerplate.3-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.10">
            <p id="section-boilerplate.3-1.10.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-boilerplate.3-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-boilerplate.3-1.11">
            <p id="section-boilerplate.3-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-boilerplate.3-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Misissued public-key certificates can prevent TLS <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> 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.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">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 <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">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 pinning
does not pin certificate information and therefore is truly an
independent second-factor authentication.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Ticket pinning is a trust-on-first-use (TOFU) mechanism, in that the
first server authentication is only based on PKI certificate validation,
but for any follow-on sessions, the client is further ensuring the
server's identity based on the server's ability to decrypt the ticket,
in addition to normal PKI certificate authentication.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">During initial TLS session establishment, the client requests a pinning
ticket from the server.  Upon receiving the request the server generates
a pinning secret that is expected to be unpredictable for peers other
than the client or the server.  In our case, the pinning secret is
generated from parameters exchanged during the TLS key exchange, so
client and server can generate it locally and independently. The server
constructs the pinning ticket with the necessary information to retrieve
the pinning secret.  The server then encrypts the ticket and returns the
pinning ticket to the client with an associated pinning lifetime.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The pinning lifetime value indicates for how long the server promises to
retain the server-side ticket-encryption key, which allows it to
complete the protocol exchange correctly and prove its identity. The
server commitment (and ticket lifetime) is typically on the order of
weeks.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">Once the key exchange is completed, and the server is deemed
authenticated, the client generates locally the pinning secret and
caches the server's identifiers to index the pinning secret as well as
the pinning ticket and its associated lifetime.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">When the client reestablishes a new TLS session with the server, it
sends the pinning ticket to the server. Upon receiving it, the server
returns a proof of knowledge of the pinning secret.  Once the key
exchange is completed, and the server has been authenticated, the client
checks the pinning proof returned by the server using the client's
stored pinning secret. If the proof matches, the client can conclude
that the server to which it is currently connecting is, in fact, the correct
server.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">This document only applies to TLS 1.3.
We believe that the
idea can also be retrofitted into earlier versions of the protocol, but
this would require significant changes.
One example is that TLS 1.2 <span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span> and
earlier versions do not provide a generic facility of encrypted
handshake extensions, such as is used here to transport the ticket.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">The main advantages of this protocol over earlier pinning solutions 
are the following:<a href="#section-1-10" class="pilcrow">¶</a></p>
<ul>
<li id="section-1-11.1">The protocol is at the TLS level, and as a result is not restricted to
HTTP at the application level.<a href="#section-1-11.1" class="pilcrow">¶</a>
</li>
        <li id="section-1-11.2">The protocol is robust to changes in server IP address, 
certification authority (CA), and public key.  The
server is characterized by the ownership of the pinning protection key,
which is never provided to the client. Server configuration parameters
such as the CA and the public key may change without affecting the
pinning ticket protocol.<a href="#section-1-11.2" class="pilcrow">¶</a>
</li>
        <li id="section-1-11.3">Once a single parameter is configured (the ticket's lifetime), operation
is fully automated. The server administrator need not bother with the
management of backup certificates or explicit pins.<a href="#section-1-11.3" class="pilcrow">¶</a>
</li>
        <li id="section-1-11.4">For server clusters, we reuse the existing infrastructure <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>
where it exists.<a href="#section-1-11.4" class="pilcrow">¶</a>
</li>
        <li id="section-1-11.5">Pinning errors, presumably resulting from man-in-the-middle (MITM) attacks,
can be detected
both by the client and the server. This allows for server-side detection
of MITM attacks using large-scale analytics, and with no need to rely on
clients to explicitly report the error.<a href="#section-1-11.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-12">A note on terminology: unlike other solutions in this space, we do not
do "certificate pinning" (or "public key pinning"), since the protocol
is oblivious to the server's certificate. We prefer the term "server
identity pinning" for this new solution.  In our solution, the server
proves its identity by generating a proof that it can read and decrypt
an encrypted ticket. As a result, the identity proof relies on proof of
ownership of the pinning protection key. However, this key is never
exchanged with the client or known by it, and so cannot itself be
pinned.<a href="#section-1-12" class="pilcrow">¶</a></p>
<div id="conventions-used-in-this-document">
<section id="section-1.1">
        <h3 id="name-conventions-used-in-this-do">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="scope-of-experimentation">
<section id="section-1.2">
        <h3 id="name-scope-of-experimentation">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-scope-of-experimentation" class="section-name selfRef">Scope of Experimentation</a>
        </h3>
<p id="section-1.2-1">This document describes an experimental extension to the TLS protocol.
This section defines constraints on this experiment and how it can yield useful information, potentially resulting in a standard.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">The protocol is designed so that if the server does not support it, the client and server fall back to a normal TLS exchange,
with the exception of a single PinningTicket extension being initially sent by the client.
In addition, the protocol is designed only to strengthen the validation of the server's identity ("second factor").
As a result, implementation or even protocol errors should not result in
weakened security compared to the normal TLS exchange.
Given these two points, experimentation can be run on the open Internet between consenting client and server implementations.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
<p id="section-1.2-3">The goal of the experiment is to prove that:<a href="#section-1.2-3" class="pilcrow">¶</a></p>
<ul>
<li id="section-1.2-4.1">Non-supporting clients and servers are unaffected.<a href="#section-1.2-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-1.2-4.2">Connectivity between supporting clients and servers is retained under normal circumstances,
whether the client connects to the server frequently (relative to the ticket's lifetime) or very rarely.<a href="#section-1.2-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-1.2-4.3">Enterprise middleboxes do not interrupt such connectivity.<a href="#section-1.2-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-1.2-4.4">Misissued certificates and rogue TLS-aware middleboxes do result in broken connectivity,
and these cases are detected on the client and/or server side. Clients and servers can be recovered
even after such events and the normal connectivity restored.<a href="#section-1.2-4.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.2-5">Following two years of successful deployment, the authors will publish a document that summarizes
the experiment's findings and will resubmit the protocol for
consideration as a Proposed Standard.<a href="#section-1.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="protocol-overview">
<section id="section-2">
      <h2 id="name-protocol-overview">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
      </h2>
<p id="section-2-1">The protocol consists of two phases: the first time a particular client
connects to a server, and subsequent connections.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This protocol supports full TLS handshakes, as well as 0-RTT handshakes.
Below we present it in the context of a full handshake, but behavior in
0-RTT handshakes should be identical.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">The document presents some similarities with the ticket resumption
mechanism described in <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>. However the scope of this document
differs from session resumption mechanisms implemented with <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>
or with other mechanisms. Specifically, the pinning ticket does not
carry any state associated with a TLS session and thus cannot be used
for session resumption or client authentication. Instead, the
pinning ticket only contains the encrypted pinning secret.
The pinning ticket is used by the server to prove
its ability to decrypt it, which implies ownership of the pinning
protection key.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4"><span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span> has been obsoleted 
by <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, and ticket resumption is
now defined by <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>. This document references
<span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span> as an informational document since it contains a more
thorough discussion of stateless ticket resumption, and because
ticket resumption benefits
from significant operational experience with TLS 1.2 that is still
widely deployed at the time of writing.  This experience,
as well as deployment experience, can easily be re-used for identity pinning.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">With TLS 1.3, session resumption is based on a Pre-Shared Key (PSK).
This is orthogonal to this protocol. With TLS 1.3, a TLS session can be
established using PKI and a pinning ticket, and later resumed with PSK.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">However, the protocol described in this document addresses the problem
of misissued certificates. Thus, it is not expected to be used outside a
certificate-based TLS key exchange, such as in PSK. As a result, PSK
handshakes <span class="bcp14">MUST NOT</span> include the extension defined here.<a href="#section-2-6" class="pilcrow">¶</a></p>
<div id="initial-connection">
<section id="section-2.1">
        <h3 id="name-initial-connection">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-initial-connection" class="section-name selfRef">Initial Connection</a>
        </h3>
<p id="section-2.1-1">When a client first connects to a server, it requests a pinning ticket
by sending an empty PinningTicket extension, and receives it as part of
the server's first response, in the returned PinningTicket extension.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-ascii-art" id="section-2.1-2">
<pre>
 Client                                               Server

 ClientHello
   + key_share
   + signature_algorithms
   + PinningTicket         --------&gt;
                                                 ServerHello
                                                 + key_share
                                       {EncryptedExtensions
                                            + PinningTicket}
                                       {CertificateRequest*}
                                              {Certificate*}
                                        {CertificateVerify*}
                           &lt;--------              {Finished}
 {Certificate*}
 {CertificateVerify*}
 {Finished}                --------&gt;
 [Application Data]        &lt;-------&gt;      [Application Data]

        *  Indicates optional or situation-dependent
           messages that are not always sent.

        {} Indicates messages protected using keys
           derived from the ephemeral secret.

        [] Indicates messages protected using keys
           derived from the master secret.
</pre><a href="#section-2.1-2" class="pilcrow">¶</a>
</div>
<p id="section-2.1-3">If a client supports the PinningTicket extension and does not have any
pinning ticket associated with the server, the exchange is considered as
an initial connection. Other reasons the client may not have a pinning
ticket include the client having flushed its pinning ticket store, or
the committed lifetime of the pinning ticket having expired.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">Upon receipt of the PinningTicket extension, the server computes a
pinning secret (<a href="#pinning-secret" class="xref">Section 4.1</a>) and sends the pinning ticket
(<a href="#pinning-ticket" class="xref">Section 4.2</a>) encrypted with the pinning protection key
(<a href="#pinning-ticket-key" class="xref">Section 4.3</a>).  The pinning ticket is associated with a
lifetime value by which the server assumes the responsibility of
retaining the pinning protection key and being able to decrypt incoming
pinning tickets during the period indicated by the committed lifetime.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1-5">Once the pinning ticket has been generated, the server returns the
pinning ticket and the committed lifetime in a PinningTicket extension
embedded in the EncryptedExtensions message.  We note that a
PinningTicket extension <span class="bcp14">MUST NOT</span> be sent as part of a HelloRetryRequest.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">Upon receiving the pinning ticket, the client <span class="bcp14">MUST NOT</span> accept it until
the key exchange is completed and the server authenticated. If the key
exchange is not completed successfully, the client <span class="bcp14">MUST</span> ignore the
received pinning ticket. Otherwise, the client computes the pinning
secret and <span class="bcp14">SHOULD</span> cache the pinning secret and the pinning ticket for
the duration indicated by the pinning ticket lifetime. The client <span class="bcp14">SHOULD</span>
clean up the cached values at the end of the indicated lifetime.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="subsequent-connections">
<section id="section-2.2">
        <h3 id="name-subsequent-connections">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-subsequent-connections" class="section-name selfRef">Subsequent Connections</a>
        </h3>
<p id="section-2.2-1">When the client initiates a connection to a server it has previously
seen (see <a href="#indexing" class="xref">Section 2.3</a> on identifying servers), it <span class="bcp14">SHOULD</span> send the
pinning ticket for that server.  The pinning ticket, pinning secret, and
pinning ticket lifetime computed during the establishment of the
previous TLS session are designated in this document as the "original"
ones, to distinguish them from a new ticket that may be generated during
the current session.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">The server <span class="bcp14">MUST</span> extract the original pinning_secret value from the
ticket and <span class="bcp14">MUST</span> respond with a PinningTicket extension, which includes:<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-2.2-3.1">A proof that the server can understand the ticket that was sent by the
client; this proof also binds the pinning ticket to the server's
(current) public key, as well as the ongoing TLS session. The proof is
mandatory and <span class="bcp14">MUST</span> be included if a pinning ticket was sent by the client.<a href="#section-2.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.2-3.2">A fresh pinning ticket. The main reason for refreshing the ticket on
each connection is privacy: to avoid the ticket serving as a fixed
client identifier. While a fresh pinning ticket might be of zero length,
it is <span class="bcp14">RECOMMENDED</span> to include a fresh ticket with a nonzero length with each
response.<a href="#section-2.2-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-2.2-4">If the server cannot validate the received ticket, that might indicate
an earlier MITM attack on this client. The server <span class="bcp14">MUST</span> then abort the
connection with a handshake_failure alert and <span class="bcp14">SHOULD</span> log this failure.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2-5">The client <span class="bcp14">MUST</span> verify the proof, and if it fails to do so, 
the client <span class="bcp14">MUST</span> issue a
handshake_failure alert and abort the connection (see also
<a href="#client_error" class="xref">Section 6.5</a>).  It is important that the client does not attempt to
"fall back" by omitting the PinningTicket extension.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<p id="section-2.2-6">When the connection is successfully set up, i.e., after the Finished
message is verified, the client <span class="bcp14">SHOULD</span> store the new ticket along with
the corresponding pinning_secret, replacing the original ticket.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
<p id="section-2.2-7">Although this is an extension, if the client already has a ticket for a
server, the client <span class="bcp14">MUST</span> interpret a missing PinningTicket extension in
the server's response as an attack, because of the server's prior
commitment to respect the ticket. The client <span class="bcp14">MUST</span> abort the connection
in this case.  See also <a href="#ramp_down" class="xref">Section 5.5</a> on ramping down support for this
extension.<a href="#section-2.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="indexing">
<section id="section-2.3">
        <h3 id="name-indexing-the-pins">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-indexing-the-pins" class="section-name selfRef">Indexing the Pins</a>
        </h3>
<p id="section-2.3-1">Each pin is associated with a set of identifiers that include, among
others, hostname, protocol (TLS or DTLS), and port
number.  In other words, the pin for port TCP/443 may be different from
that for DTLS, or from the pin for port TCP/8443. These identifiers are
expected to be relevant to characterize the identity of the server as
well as the establishing TLS session. When a hostname is used, it <span class="bcp14">MUST</span> be
the value sent inside the Server Name Indication (SNI) extension.  This
definition is similar to the concept of a Web Origin <span>[<a href="#RFC6454" class="xref">RFC6454</a>]</span>, but does not assume
the existence of a URL.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">The purpose of ticket pinning is to pin the server identity. As a
result, any information orthogonal to the server's identity <span class="bcp14">MUST NOT</span> be
considered in indexing.  More particularly, IP addresses are ephemeral
and forbidden in SNI, and therefore pins <span class="bcp14">MUST NOT</span> be associated with IP
addresses. Similarly, CA names or public keys associated with server
<span class="bcp14">MUST NOT</span> be used for indexing as they may change over time.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="message-definitions">
<section id="section-3">
      <h2 id="name-message-definitions">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-message-definitions" class="section-name selfRef">Message Definitions</a>
      </h2>
<p id="section-3-1">This section defines the format of the PinningTicket extension.
We follow the message notation of <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="section-3-2">
<pre class="sourcecode lang-c">
 opaque pinning_ticket&lt;0..2^16-1&gt;;

 opaque pinning_proof&lt;0..2^8-1&gt;;

 struct {
   select (Role) {
     case client:
       pinning_ticket ticket&lt;0..2^16-1&gt;; //omitted on 1st connection

     case server:
       pinning_proof proof&lt;0..2^8-1&gt;; //no proof on 1st connection
       pinning_ticket ticket&lt;0..2^16-1&gt;; //omitted on ramp down
       uint32 lifetime;
   }
} PinningTicketExtension;
</pre><a href="#section-3-2" class="pilcrow">¶</a>
</div>
<dl class="dlParallel" id="section-3-3">
        <dt id="section-3-3.1">ticket</dt>
        <dd style="margin-left: 5.0em" id="section-3-3.2">
  a pinning ticket sent by the client or returned by the server. The
ticket is opaque to the client. The extension <span class="bcp14">MUST</span> contain exactly 0 or
1 tickets.<a href="#section-3-3.2" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.3">proof</dt>
        <dd style="margin-left: 5.0em" id="section-3-3.4">
  a demonstration by the server that it understands the received ticket
and therefore that it is in possession of the secret that was used to
generate it originally.  The extension <span class="bcp14">MUST</span> contain exactly 0 or 1
proofs.<a href="#section-3-3.4" class="pilcrow">¶</a>
</dd>
<dt id="section-3-3.5">lifetime</dt>
        <dd style="margin-left: 5.0em" id="section-3-3.6">
  the duration (in seconds) that the server commits to accept offered
tickets in the future.<a href="#section-3-3.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="crypto">
<section id="section-4">
      <h2 id="name-cryptographic-operations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-cryptographic-operations" class="section-name selfRef">Cryptographic Operations</a>
      </h2>
<p id="section-4-1">This section provides details on the cryptographic operations performed
by the protocol peers.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="pinning-secret">
<section id="section-4.1">
        <h3 id="name-pinning-secret">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-pinning-secret" class="section-name selfRef">Pinning Secret</a>
        </h3>
<p id="section-4.1-1">The pinning secret is generated locally by the client and the server,
which means they must use the same inputs to generate it. This value
must be generated before the ServerHello message is sent, as the server
includes the corresponding pinning ticket in the same flight as the
ServerHello message. In addition, the pinning secret must be
unpredictable to any party other than the client and the server.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">The pinning secret is derived using the Derive-Secret function provided
by TLS 1.3, described in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<div id="section-4.1-3">
<pre class="sourcecode lang-c">
pinning secret = Derive-Secret(Handshake Secret, "pinning secret",
         ClientHello...ServerHello)
</pre><a href="#section-4.1-3" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="pinning-ticket">
<section id="section-4.2">
        <h3 id="name-pinning-ticket">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-pinning-ticket" class="section-name selfRef">Pinning Ticket</a>
        </h3>
<p id="section-4.2-1">The pinning ticket contains the pinning secret. The pinning ticket is
provided by the client to the server, which decrypts it in order to
extract the pinning secret and responds with a pinning proof.  As a
result, the characteristics of the pinning ticket are:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-4.2-2.1">Pinning tickets <span class="bcp14">MUST</span> be encrypted and integrity-protected using strong
cryptographic algorithms.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-2.2">Pinning tickets <span class="bcp14">MUST</span> be protected with a long-term pinning protection
key.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-2.3">Pinning tickets <span class="bcp14">MUST</span> include a pinning protection key ID or serial
number as to enable the pinning protection key to be refreshed.<a href="#section-4.2-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-2.4">The pinning ticket <span class="bcp14">MAY</span> include other information, in addition to the
pinning secret. When additional information is included, a careful
review needs to be performed to evaluate its impact on privacy.<a href="#section-4.2-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.2-3">The pinning ticket's format is not specified by this document, but
a format similar to the one proposed by <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>
is <span class="bcp14">RECOMMENDED</span>.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pinning-ticket-key">
<section id="section-4.3">
        <h3 id="name-pinning-protection-key">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-pinning-protection-key" class="section-name selfRef">Pinning Protection Key</a>
        </h3>
<p id="section-4.3-1">The pinning protection key is used only by the server and so remains
server implementation specific. <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span> recommends the use of two
keys, but when using Authenticated Encryption with Associated Data (AEAD) algorithms,
 only a single key is required.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">When a single server terminates TLS for multiple virtual servers using
the SNI mechanism, it is strongly <span class="bcp14">RECOMMENDED</span> that the server use
a separate protection key for each one of them, in order to allow
migrating virtual servers between different servers while keeping
pinning active.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">As noted in <a href="#cluster" class="xref">Section 5.1</a>, if the server is actually a cluster of
machines, the protection key <span class="bcp14">MUST</span> be synchronized between all the nodes
that accept TLS connections to the same server name.  When <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>
is deployed, an easy way to do it is to derive the protection key from
the session-ticket protection key, which is already synchronized. For
example:<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<div id="section-4.3-4">
<pre class="sourcecode lang-c">
pinning_protection_key = HKDF-Expand(resumption_protection_key,
                              "pinning protection", L)
</pre><a href="#section-4.3-4" class="pilcrow">¶</a>
</div>
<p id="section-4.3-5">Where resumption_protection_key is the ticket protection key defined in
<span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span>. Both resumption_protection_key and pinning_protection_key
are only used by the server.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">The above solution attempts to minimize code changes related to management of the resumption_protection_key.
The drawback is that this key would be used both to directly encrypt session tickets and to derive
the pinning_protection_key, and such mixed usage of a single key is not in line with cryptographic best practices.
Where possible, it is <span class="bcp14">RECOMMENDED</span> that the resumption_protection_key 
be unrelated to the pinning_protection_key and that they are separately 
shared among the relevant servers.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pinning-proof">
<section id="section-4.4">
        <h3 id="name-pinning-proof">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-pinning-proof" class="section-name selfRef">Pinning Proof</a>
        </h3>
<p id="section-4.4-1">The pinning proof is sent by the server to demonstrate that it has been
able to decrypt the pinning ticket and to retrieve the pinning secret. The
proof must be unpredictable and must not be replayed. Similarly to the
pinning ticket, the pinning proof is sent by the server in the
ServerHello message.  In addition, it must not be possible for a MITM
server with a fake certificate to obtain a pinning proof from the
original server.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">In order to address these requirements, the pinning proof is bound to
the TLS session as well as the public key of the server:<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<div id="section-4.4-3">
<pre class="sourcecode lang-c">
pinning_proof_secret=Derive-Secret(Handshake Secret, 
             "pinning proof 1", ClientHello...ServerHello)

proof = HMAC(original_pinning_secret, "pinning proof 2" +
             pinning_proof_secret + Hash(server_public_key))
</pre><a href="#section-4.4-3" class="pilcrow">¶</a>
</div>
<p id="section-4.4-4">where HMAC <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span> uses the Hash algorithm that was negotiated in
the handshake, and the same hash is also used over the server's public
key. The original_pinning_secret value refers to the secret value
extracted from the ticket sent by the client, to distinguish it from a
new pinning secret value that is possibly computed in the current
exchange.  The server_public_key value is the DER representation of
the public key, specifically the SubjectPublicKeyInfo structure as-is.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="operational-considerations">
<section id="section-5">
      <h2 id="name-operational-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
      </h2>
<p id="section-5-1">The main motivation behind the current protocol is to enable identity
pinning without the need for manual operations. Manual operations are
susceptible to human error, and in the case of public key pinning, can
easily result in "server bricking": the server becoming inaccessible to
some or all of its users. To achieve this goal, operations described in
identity pinning are only performed within the current TLS session, and
there is no dependence on any TLS configuration parameters such as CA
identity or public keys.  As a result, configuration changes are
unlikely to lead to desynchronized state between the client and the
server.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="cluster">
<section id="section-5.1">
        <h3 id="name-protection-key-synchronizat">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-protection-key-synchronizat" class="section-name selfRef">Protection Key Synchronization</a>
        </h3>
<p id="section-5.1-1">The only operational requirement when deploying this protocol is that, if
the server is part of a cluster, protection keys (the keys used to
encrypt tickets) <span class="bcp14">MUST</span> be synchronized between all cluster members. The
protocol is designed so that if resumption ticket protection keys
<span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span> are already synchronized between cluster members, nothing
more needs to be done.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Moreover, synchronization does not need to be instantaneous, e.g.,
protection keys can be distributed a few minutes or hours in advance of
their rollover. In such scenarios, each cluster member <span class="bcp14">MUST</span> be able to
accept tickets protected with a new version of the protection key, even
while it is still using an old version to generate keys. This ensures
that, when a client receives a "new" ticket, it does not next hit a cluster
member that still rejects this ticket.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">Misconfiguration can lead to the server's clock being off by a large
amount of time. Consider a case where a server's clock is misconfigured,
for example, to be 1 year in
the future, and the system is allowed to delete expired keys automatically.
The server will then delete many outstanding keys because they are now
long expired and will end up rejecting valid tickets that are stored
by clients. Such a scenario could make the server
inaccessible to a large number of clients.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">The decision to delete a key should at least consider
the largest value of the ticket lifetime as well as the expected time
desynchronization between the servers of the cluster and the time
difference for distributing the new key among the different servers in
the cluster.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ticket-lifetime">
<section id="section-5.2">
        <h3 id="name-ticket-lifetime">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-ticket-lifetime" class="section-name selfRef">Ticket Lifetime</a>
        </h3>
<p id="section-5.2-1">The lifetime of the ticket is a commitment by the server to retain the
ticket's corresponding protection key for this duration, so that the
server can prove to the client that it knows the secret embedded in the
ticket. For production systems, the lifetime <span class="bcp14">SHOULD</span> be between 7 and 31
days.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="certificate-renewal">
<section id="section-5.3">
        <h3 id="name-certificate-renewal">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-certificate-renewal" class="section-name selfRef">Certificate Renewal</a>
        </h3>
<p id="section-5.3-1">The protocol ensures that the client will continue speaking to the
correct server even when the server's certificate is renewed. In this
sense, pinning is not associated with certificates, which is the reason we
designate the protocol described in this document as "server identity
pinning".<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">Note that this property is not impacted by the use of the server's
public key in the pinning proof because the scope of the public key
used is only the current TLS session.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="certificate-revocation">
<section id="section-5.4">
        <h3 id="name-certificate-revocation">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-certificate-revocation" class="section-name selfRef">Certificate Revocation</a>
        </h3>
<p id="section-5.4-1">The protocol is orthogonal to certificate validation in the sense that,
if the server's certificate has been revoked or is invalid for some
other reason, the client <span class="bcp14">MUST</span> refuse to connect to it regardless of any
ticket-related behavior.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ramp_down">
<section id="section-5.5">
        <h3 id="name-disabling-pinning">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-disabling-pinning" class="section-name selfRef">Disabling Pinning</a>
        </h3>
<p id="section-5.5-1">A server implementing this protocol <span class="bcp14">MUST</span> have a "ramp down" mode of
operation where:<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.5-2.1">The server continues to accept valid pinning tickets and responds
  correctly with a proof.<a href="#section-5.5-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.5-2.2">The server does not send back a new pinning ticket.<a href="#section-5.5-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.5-3">After a while, no clients will hold valid tickets, and the
feature may be disabled. Note that clients that do not receive a new
pinning ticket do not necessarily need to remove the original ticket.
Instead, the client may keep using the ticket until its lifetime
expires. However, as detailed in <a href="#privacy" class="xref">Section 6.7</a>, re-use of a
ticket by the client may result in privacy concerns as the ticket value
may be used to correlate TLS sessions.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<p id="section-5.5-4">Issuing a new pinning ticket with a shorter lifetime would only delay
the ramp down process, as the shorter lifetime can only affect clients
that actually initiated a new connection. Other clients would still see
the original lifetime for their pinning tickets.<a href="#section-5.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="server-compromise">
<section id="section-5.6">
        <h3 id="name-server-compromise">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-server-compromise" class="section-name selfRef">Server Compromise</a>
        </h3>
<p id="section-5.6-1">If a server compromise is detected, the pinning protection key <span class="bcp14">MUST</span> be
rotated immediately, but the server <span class="bcp14">MUST</span> still accept valid tickets that
use the old, compromised key.  Clients that still hold old pinning
tickets will remain vulnerable to MITM attacks, but those that connect
to the correct server will immediately receive new tickets protected
with the newly generated pinning protection key.<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<p id="section-5.6-2">The same procedure applies if the pinning protection key is compromised
directly, e.g., if a backup copy is inadvertently made public.<a href="#section-5.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="disaster-recovery">
<section id="section-5.7">
        <h3 id="name-disaster-recovery">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-disaster-recovery" class="section-name selfRef">Disaster Recovery</a>
        </h3>
<p id="section-5.7-1">All web servers in production need to be backed up, so that they can be
recovered if a disaster (including a malicious activity) ever wipes them
out. Backup often includes the certificate and its private key, which
must be backed up securely. The pinning secret, including earlier
versions that are still being accepted, must be backed up regularly.
However since it is only used as an authentication second factor, it
does not require the same level of confidentiality as the server's
private key.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">Readers should note that <span>[<a href="#RFC5077" class="xref">RFC5077</a>]</span> session resumption keys are more
security sensitive and should normally not be backed up, but rather
treated as ephemeral keys. Even when servers derive pinning secrets from
resumption keys (<a href="#pinning-secret" class="xref">Section 4.1</a>), they <span class="bcp14">MUST NOT</span> back up resumption
keys.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">This section reviews several security aspects related to the proposed
extension.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="trust-on-first-use-tofu-and-mitm-attacks">
<section id="section-6.1">
        <h3 id="name-trust-on-first-use-tofu-and">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-trust-on-first-use-tofu-and" class="section-name selfRef">Trust-on-First-Use (TOFU) and MITM Attacks</a>
        </h3>
<p id="section-6.1-1">This protocol is a trust-on-first-use protocol. If a client initially
connects to the "right" server, it will be protected against MITM
attackers for the lifetime of each received ticket. If it connects
regularly (depending, of course, on the server-selected lifetime), it will
stay constantly protected against fake certificates.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">However if it initially connects to an attacker, subsequent connections
to the "right" server will fail. Server operators might want to advise
clients on how to remove corrupted pins, once such large-scale attacks
are detected and remediated.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">The protocol is designed so that it is not vulnerable to an active MITM
attacker who has real-time access to the original server. The pinning
proof includes a hash of the server's public key to ensure the client
that the proof was in fact generated by the server with which it is
initiating the connection.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pervasive-monitoring">
<section id="section-6.2">
        <h3 id="name-pervasive-monitoring">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-pervasive-monitoring" class="section-name selfRef">Pervasive Monitoring</a>
        </h3>
<p id="section-6.2-1">Some organizations, and even some countries, perform pervasive monitoring
on their constituents <span>[<a href="#RFC7258" class="xref">RFC7258</a>]</span>. This often takes the form of
always-active SSL proxies. Because of the TOFU property, this protocol
does not provide any security in such cases.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<p id="section-6.2-2">Pervasive monitoring may also result in privacy concerns detailed in
<a href="#privacy" class="xref">Section 6.7</a>.<a href="#section-6.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="server_error">
<section id="section-6.3">
        <h3 id="name-server-side-error-detection">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-server-side-error-detection" class="section-name selfRef">Server-Side Error Detection</a>
        </h3>
<p id="section-6.3-1">Uniquely, this protocol allows the server to detect clients that present
incorrect tickets and therefore can be assumed to be victims of a MITM
attack. Server operators can use such cases as indications of ongoing
attacks, similarly to fake certificate attacks that took place in a few
countries in the past.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="client_policy">
<section id="section-6.4">
        <h3 id="name-client-policy-and-ssl-proxi">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-client-policy-and-ssl-proxi" class="section-name selfRef">Client Policy and SSL Proxies</a>
        </h3>
<p id="section-6.4-1">Like it or not, some clients are normally deployed behind an SSL proxy.
Similar to <span>[<a href="#RFC7469" class="xref">RFC7469</a>]</span>, it is acceptable to allow pinning to be
disabled for some hosts according to local policy. For example,
a User Agent (UA) <span class="bcp14">MAY</span>
disable pinning for hosts whose validated certificate chain terminates
at a user-defined trust anchor, rather than a trust anchor built into
the UA (or underlying platform). Moreover, a client <span class="bcp14">MAY</span> accept an empty
PinningTicket extension from such hosts as a valid response.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="client_error">
<section id="section-6.5">
        <h3 id="name-client-side-error-behavior">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-client-side-error-behavior" class="section-name selfRef">Client-Side Error Behavior</a>
        </h3>
<p id="section-6.5-1">When a client receives a malformed or empty PinningTicket extension from
a pinned server, it <span class="bcp14">MUST</span> abort the handshake. If the client
retries the request, it <span class="bcp14">MUST NOT</span> omit the
PinningTicket in the retry message. Doing otherwise would expose the client to
trivial fallback attacks, similar to those described in <span>[<a href="#RFC7507" class="xref">RFC7507</a>]</span>.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<p id="section-6.5-2">However, this rule can negatively impact clients that move from
behind SSL proxies into the open Internet, and vice versa, if the advice
in <a href="#client_policy" class="xref">Section 6.4</a> is not followed.  Therefore, 
it is <span class="bcp14">RECOMMENDED</span>  that
browser and library vendors provide a documented way to remove stored
pins.<a href="#section-6.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="stolen-and-forged-tickets">
<section id="section-6.6">
        <h3 id="name-stolen-and-forged-tickets">
<a href="#section-6.6" class="section-number selfRef">6.6. </a><a href="#name-stolen-and-forged-tickets" class="section-name selfRef">Stolen and Forged Tickets</a>
        </h3>
<p id="section-6.6-1">An attacker gains no benefit from stealing pinning tickets, even in conjunction with other pinning
parameters such as the associated pinning secret, since pinning tickets are used to secure the client
rather than the server.  Similarly, it is useless to forge a ticket for
a particular server.<a href="#section-6.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy">
<section id="section-6.7">
        <h3 id="name-client-privacy">
<a href="#section-6.7" class="section-number selfRef">6.7. </a><a href="#name-client-privacy" class="section-name selfRef">Client Privacy</a>
        </h3>
<p id="section-6.7-1">This protocol is designed so that an external attacker cannot link 
different requests to a single client, provided the client
requests and receives a fresh ticket upon each connection. This may be
of concern particularly during ramp down, if the server does not provide
a new ticket, and the client reuses the same ticket. To reduce or avoid such
privacy concerns, it is <span class="bcp14">RECOMMENDED</span> for the server to issue a fresh ticket with a
reduced lifetime. This would at least reduce the time period in which
the TLS sessions of the client can be linked. The server <span class="bcp14">MAY</span> also
issue tickets with a zero-second lifetime until it is confident all
tickets are expired.<a href="#section-6.7-1" class="pilcrow">¶</a></p>
<p id="section-6.7-2">On the other hand, the server to which the client is connecting can
easily track the client.  This may be an issue when the client expects
to connect to the server (e.g., a mail server) with multiple identities.
Implementations <span class="bcp14">SHOULD</span> allow the user to opt out of pinning, either in
general or for particular servers.<a href="#section-6.7-2" class="pilcrow">¶</a></p>
<p id="section-6.7-3">This document does not define the exact content of tickets.
Including client-specific information in tickets would raise privacy concerns
and is <span class="bcp14">NOT RECOMMENDED</span>.<a href="#section-6.7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ticket-protection-key-management">
<section id="section-6.8">
        <h3 id="name-ticket-protection-key-manag">
<a href="#section-6.8" class="section-number selfRef">6.8. </a><a href="#name-ticket-protection-key-manag" class="section-name selfRef">Ticket Protection Key Management</a>
        </h3>
<p id="section-6.8-1">While the ticket format is not mandated by this document, protecting 
the ticket using authenticated encryption is <span class="bcp14">RECOMMENDED</span>. Some of the algorithms
commonly used for authenticated encryption, e.g., Galois/Counter Mode (GCM), are highly
vulnerable to nonce reuse, and this problem is magnified in a cluster
setting.  Therefore, implementations that choose AES-GCM or any AEAD
equivalent <span class="bcp14">MUST</span> adopt
one of these three alternatives:<a href="#section-6.8-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-6.8-2.1">Partition the nonce namespace between cluster members and use monotonic
counters on each member, e.g., by setting the nonce to the concatenation
of the cluster member ID and an incremental counter.<a href="#section-6.8-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-6.8-2.2">Generate random nonces but avoid the so-called birthday bound, i.e.,
never generate more than the maximum allowed number of encrypted
tickets (2**64 for AES-128-GCM) for the same ticket
pinning protection key.<a href="#section-6.8-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-6.8-2.3">An alternative design that has been attributed to Karthik Bhargavan is
as follows.  Start with a 128-bit master key K_master and then for
each encryption, generate a 256-bit random nonce and compute: K =
HKDF(K_master, Nonce || "key"), then N = HKDF(K_master, Nonce ||
"nonce"). Use these values to encrypt the ticket, AES-GCM(K, N,
data). This nonce should then be stored and transmitted with the
ticket.<a href="#section-6.8-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="iana-considerations">
<section id="section-7">
      <h2 id="name-iana-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-7-1">The IANA has allocated a TicketPinning extension value in the "TLS
ExtensionType Values" registry.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2"><span>[<a href="#RFC8447" class="xref">RFC8447</a>]</span> defines the procedure, requirements, and the necessary
information for the IANA to update the "TLS ExtensionType Values"
registry <span>[<a href="#TLS-EXT" class="xref">TLS-EXT</a>]</span>. The registration procedure
      is "Specification Required" <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">The TicketPinning extension is registered as follows. (The extension is not
      limited to Private Use, and as such has its first byte in the range
      0-254.)<a href="#section-7-3" class="pilcrow">¶</a></p>
<dl class="dlParallel" id="section-7-4">
        <dt id="section-7-4.1">Value:</dt>
        <dd id="section-7-4.2">32<a href="#section-7-4.2" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.3">Name:</dt>
        <dd id="section-7-4.4">ticket_pinning<a href="#section-7-4.4" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.5">Recommended:</dt>
        <dd id="section-7-4.6">No<a href="#section-7-4.6" class="pilcrow">¶</a>
</dd>
<dt id="section-7-4.7">TLS 1.3:</dt>
        <dd id="section-7-4.8">CH, EE (to indicate that the extension is present
 in ClientHello and EncryptedExtensions messages)<a href="#section-7-4.8" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<section id="section-8">
      <h2 id="name-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-normative-references">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dt id="RFC8447">[RFC8447]</dt>
      <dd>
<span class="refAuthor">Salowey, J.</span><span class="refAuthor"> and S. Turner</span>, <span class="refTitle">"IANA Registry Updates for TLS and DTLS"</span>, <span class="seriesInfo">RFC 8447</span>, <span class="seriesInfo">DOI 10.17487/RFC8447</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8447">https://www.rfc-editor.org/info/rfc8447</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-8.2">
        <h3 id="name-informative-references">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Netcraft">[Netcraft]</dt>
        <dd>
<span class="refAuthor">Mutton, P.</span>, <span class="refTitle">"HTTP Public Key Pinning: You're doing it wrong!"</span>, <time datetime="2016-03">March 2016</time>, <span>&lt;<a href="https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html">https://news.netcraft.com/archives/2016/03/30/http-public-key-pinning-youre-doing-it-wrong.html</a>&gt;</span>. </dd>
<dt id="Oreo">[Oreo]</dt>
        <dd>
<span class="refAuthor">Berkman, O.</span><span class="refAuthor">, Pinkas, B.</span><span class="refAuthor">, and M. Yung</span>, <span class="refTitle">"Firm Grip Handshakes: A Tool for Bidirectional Vouching"</span>, <span class="seriesInfo">Cryptology and Network Security pp. 142-157</span>, <time datetime="2012">2012</time>. </dd>
<dt id="RFC2104">[RFC2104]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span><span class="refAuthor">, Bellare, M.</span><span class="refAuthor">, and R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</a>&gt;</span>. </dd>
<dt id="RFC5077">[RFC5077]</dt>
        <dd>
<span class="refAuthor">Salowey, J.</span><span class="refAuthor">, Zhou, H.</span><span class="refAuthor">, Eronen, P.</span><span class="refAuthor">, and H. Tschofenig</span>, <span class="refTitle">"Transport Layer Security (TLS) Session Resumption without Server-Side State"</span>, <span class="seriesInfo">RFC 5077</span>, <span class="seriesInfo">DOI 10.17487/RFC5077</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5077">https://www.rfc-editor.org/info/rfc5077</a>&gt;</span>. </dd>
<dt id="RFC5246">[RFC5246]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span><span class="refAuthor"> and E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
<dt id="RFC6454">[RFC6454]</dt>
        <dd>
<span class="refAuthor">Barth, A.</span>, <span class="refTitle">"The Web Origin Concept"</span>, <span class="seriesInfo">RFC 6454</span>, <span class="seriesInfo">DOI 10.17487/RFC6454</span>, <time datetime="2011-12">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6454">https://www.rfc-editor.org/info/rfc6454</a>&gt;</span>. </dd>
<dt id="RFC6962">[RFC6962]</dt>
        <dd>
<span class="refAuthor">Laurie, B.</span><span class="refAuthor">, Langley, A.</span><span class="refAuthor">, and E. Kasper</span>, <span class="refTitle">"Certificate Transparency"</span>, <span class="seriesInfo">RFC 6962</span>, <span class="seriesInfo">DOI 10.17487/RFC6962</span>, <time datetime="2013-06">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6962">https://www.rfc-editor.org/info/rfc6962</a>&gt;</span>. </dd>
<dt id="RFC7258">[RFC7258]</dt>
        <dd>
<span class="refAuthor">Farrell, S.</span><span class="refAuthor"> and H. Tschofenig</span>, <span class="refTitle">"Pervasive Monitoring Is an Attack"</span>, <span class="seriesInfo">BCP 188</span>, <span class="seriesInfo">RFC 7258</span>, <span class="seriesInfo">DOI 10.17487/RFC7258</span>, <time datetime="2014-05">May 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7258">https://www.rfc-editor.org/info/rfc7258</a>&gt;</span>. </dd>
<dt id="RFC7469">[RFC7469]</dt>
        <dd>
<span class="refAuthor">Evans, C.</span><span class="refAuthor">, Palmer, C.</span><span class="refAuthor">, and R. Sleevi</span>, <span class="refTitle">"Public Key Pinning Extension for HTTP"</span>, <span class="seriesInfo">RFC 7469</span>, <span class="seriesInfo">DOI 10.17487/RFC7469</span>, <time datetime="2015-04">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7469">https://www.rfc-editor.org/info/rfc7469</a>&gt;</span>. </dd>
<dt id="RFC7507">[RFC7507]</dt>
        <dd>
<span class="refAuthor">Moeller, B.</span><span class="refAuthor"> and A. Langley</span>, <span class="refTitle">"TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks"</span>, <span class="seriesInfo">RFC 7507</span>, <span class="seriesInfo">DOI 10.17487/RFC7507</span>, <time datetime="2015-04">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7507">https://www.rfc-editor.org/info/rfc7507</a>&gt;</span>. </dd>
<dt id="RFC8555">[RFC8555]</dt>
        <dd>
<span class="refAuthor">Barnes, R.</span><span class="refAuthor">, Hoffman-Andrews, J.</span><span class="refAuthor">, McCarney, D.</span><span class="refAuthor">, and J. Kasten</span>, <span class="refTitle">"Automatic Certificate Management Environment (ACME)"</span>, <span class="seriesInfo">RFC 8555</span>, <span class="seriesInfo">DOI 10.17487/RFC8555</span>, <time datetime="2019-03">March 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8555">https://www.rfc-editor.org/info/rfc8555</a>&gt;</span>. </dd>
<dt id="TLS-EXT">[TLS-EXT]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TLS Extension Type Value"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tls-extensiontype-values/">https://www.iana.org/assignments/tls-extensiontype-values/</a>&gt;</span>. </dd>
<dt id="I-D.perrin-tls-tack">[TLS-TACK]</dt>
      <dd>
<span class="refAuthor">Marlinspike, M.</span>, <span class="refTitle">"Trust Assertions for Certificate Keys"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-perrin-tls-tack-02</span>, <time datetime="2013-01-07">7 January 2013</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-perrin-tls-tack-02">https://tools.ietf.org/html/draft-perrin-tls-tack-02</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="previous-work">
<section id="section-appendix.a">
      <h2 id="name-previous-work">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-previous-work" class="section-name selfRef">Previous Work</a>
      </h2>
<p id="section-appendix.a-1">The global PKI system relies on the trust of a CA issuing certificates.
As a result, a corrupted trusted CA may issue a certificate for any
organization without the organization's approval (a misissued or "fake"
certificate), and use the certificate to impersonate the organization.
There are many attempts to resolve these weaknesses, including the
Certificate Transparency (CT) protocol <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>, 
HTTP Public Key Pinning (HPKP) <span>[<a href="#RFC7469" class="xref">RFC7469</a>]</span>, 
and Trust Assertions for Certificate Keys (TACK) <span>[<a href="#I-D.perrin-tls-tack" class="xref">TLS-TACK</a>]</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">CT requires
cooperation of a large portion of the hundreds of extant certificate
authorities (CAs) before it can be used "for real", in enforcing mode.
It is noted that the relevant industry forum (CA/Browser Forum) is
indeed pushing for such extensive adoption. However the public nature of CT
often makes it inappropriate for enterprise use because many organizations
are not willing to expose their internal infrastructure publicly.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">TACK has some similarities
to the current proposal, but work on it seems to have stalled.  <a href="#tack" class="xref">Appendix A.2</a>
compares our proposal to TACK.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">HPKP is an IETF standard, but so far has proven hard to deploy. HPKP
pins (fixes) a public key, one of the public keys listed in the
certificate chain.  As a result, HPKP needs to be coordinated with the
certificate management process.  Certificate management impacts HPKP and
thus increases the probability of HPKP failures.  This risk is made even
higher given the fact that, even though work has been done in the 
Automated Certificate Management Environment (ACME)
working group to automate certificate management, in many or even most cases,
certificates are still managed manually.  As a result, HPKP cannot be
completely automated, resulting in error-prone manual configuration. Such
errors could prevent the web server from being accessed by some clients.
In addition, HPKP uses an HTTP header, which makes this solution HTTPS
specific and not generic to TLS. On the other hand, the current document
provides a solution that is independent of the server's certificate
management, and that can be entirely and easily automated. <a href="#hpkp" class="xref">Appendix A.1</a>
compares HPKP to the current document in more detail.<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<p id="section-appendix.a-5">The ticket pinning proposal augments these mechanisms with a much easier
to implement and deploy solution for server identity pinning, by reusing
some of the ideas behind TLS session resumption.<a href="#section-appendix.a-5" class="pilcrow">¶</a></p>
<p id="section-appendix.a-6">This section compares ticket pinning to two earlier proposals, HPKP and TACK.<a href="#section-appendix.a-6" class="pilcrow">¶</a></p>
<div id="hpkp">
<section id="section-a.1">
        <h2 id="name-comparison-hpkp">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-comparison-hpkp" class="section-name selfRef">Comparison: HPKP</a>
        </h2>
<p id="section-a.1-1">The current IETF standard for pinning the identity of web servers is 
HPKP <span>[<a href="#RFC7469" class="xref">RFC7469</a>]</span>.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<p id="section-a.1-2">The main differences between HPKP and the current document are the
following:<a href="#section-a.1-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.1-3.1">HPKP limits its scope to HTTPS, while the current document considers all
application above TLS.<a href="#section-a.1-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-3.2">HPKP pins the public key of the server (or another public key along the
certificate chain), and as such, is highly dependent on the management of
certificates.  Such dependency increases the potential error surface,
especially as certificate management is not yet largely automated.  The
current proposal, on the other hand, is independent of certificate
management.<a href="#section-a.1-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-3.3">HPKP pins public keys that are public and used for the standard TLS
authentication.  Identity pinning relies on the ownership of the pinning
key, which is not disclosed to the public and not involved in the
standard TLS authentication.  As a result, identity pinning is a
completely independent, second-factor authentication mechanism.<a href="#section-a.1-3.3" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-3.4">HPKP relies on a backup key to recover the misissuance of a key.  We
believe such backup mechanisms add excessive complexity and cost.
Reliability of the current mechanism is primarily based on its being
highly automated.<a href="#section-a.1-3.4" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-3.5">HPKP relies on the client to report errors to the report-uri.  The
current document does not need any out-of-band mechanism, and the server is
informed automatically. This provides an easier and more reliable health
monitoring.<a href="#section-a.1-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-a.1-4">On the other hand, HPKP shares the following aspects with identity pinning:<a href="#section-a.1-4" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.1-5.1">Both mechanisms provide hard failure.  With HPKP, only the client is
aware of the failure, while with the current proposal both client and
server are informed of the failure.  This provides room for further
mechanisms to automatically recover from such failures.<a href="#section-a.1-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-5.2">Both mechanisms are subject to a server compromise in which users are
provided with an invalid ticket (e.g., a random one) or HTTP header with
a very long lifetime. For identity pinning, this lifetime <span class="bcp14">SHOULD NOT</span> be
longer than 31 days.  In both cases, clients will not be able to
reconnect the server during this lifetime.  With the current proposal,
an attacker needs to compromise the TLS layer, while with HPKP, the
attacker needs to compromise the HTTP server.  Arguably, the TLS-level
compromise is typically more difficult for the attacker.<a href="#section-a.1-5.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-a.1-6">Unfortunately HPKP has not seen wide deployment yet.  As of March 2016,
the number of servers using HPKP was less than 3000 <span>[<a href="#Netcraft" class="xref">Netcraft</a>]</span>.  This
may simply be due to inertia, but we believe the main reason is the
interactions between HPKP and manual certificate management that is
needed to implement HPKP for enterprise servers. The penalty for making
mistakes (e.g., being too early or too late to deploy new pins) is that
the server becomes unusable for some of the clients.<a href="#section-a.1-6" class="pilcrow">¶</a></p>
<p id="section-a.1-7">To demonstrate this point, we present a list of the steps involved in
deploying HPKP on a security-sensitive web server.<a href="#section-a.1-7" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal" id="section-a.1-8">
          <li id="section-a.1-8.1">
            <p id="section-a.1-8.1.1">Generate two public/private key pairs on a computer that is not the
live server. The second one is the "backup1" key pair.<a href="#section-a.1-8.1.1" class="pilcrow">¶</a></p>
<div id="section-a.1-8.1.2">
<pre class="sourcecode lang-bash">
openssl genrsa -out "example.com.key" 2048;

openssl genrsa -out "example.com.backup1.key" 2048;
</pre><a href="#section-a.1-8.1.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="section-a.1-8.2">
            <p id="section-a.1-8.2.1">Generate hashes for both of the public keys. These will be used in
the HPKP header:<a href="#section-a.1-8.2.1" class="pilcrow">¶</a></p>
<div id="section-a.1-8.2.2">
<pre class="sourcecode lang-bash">
openssl rsa -in "example.com.key" -outform der -pubout | \
openssl dgst -sha256 -binary | openssl enc -base64  

openssl rsa -in "example.com.backup1.key" -outform der \
-pubout | openssl dgst -sha256 -binary | openssl enc -base64
</pre><a href="#section-a.1-8.2.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="section-a.1-8.3">
            <p id="section-a.1-8.3.1">Generate a single CSR (Certificate Signing Request) for the first
key pair, where you include the domain name in the CN (Common Name)
field:<a href="#section-a.1-8.3.1" class="pilcrow">¶</a></p>
<div id="section-a.1-8.3.2">
<pre class="sourcecode lang-bash">
openssl req -new -subj "/C=GB/ST=Area/L=Town/O=Org/ \
CN=example.com" -key "example.com.key" -out "example.com.csr"; 
</pre><a href="#section-a.1-8.3.2" class="pilcrow">¶</a>
</div>
</li>
          <li id="section-a.1-8.4">Send this CSR to the CA and go though the
dance to prove you own the domain.  The CA will give you a single
certificate that will typically expire within a year or two.<a href="#section-a.1-8.4" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-8.5">
            <p id="section-a.1-8.5.1">On the live server, upload and set up the first key pair and its
certificate.  At this point, you can add the "Public-Key-Pins" header,
using the two hashes you created in step 2.<a href="#section-a.1-8.5.1" class="pilcrow">¶</a></p>
<p id="section-a.1-8.5.2">
Note that only the first key pair has been uploaded to the server so far.<a href="#section-a.1-8.5.2" class="pilcrow">¶</a></p>
</li>
          <li id="section-a.1-8.6">Store the second (backup1) key pair somewhere safe, probably
somewhere encrypted like a password manager.  It won't expire, as it's
just a key pair; it just needs to be ready for when you need to get your
next certificate.<a href="#section-a.1-8.6" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-8.7">Time passes -- probably just under a year (if waiting for a
certificate to expire), or maybe sooner if you find that your server has
been compromised, and you need to replace the key pair and certificate.<a href="#section-a.1-8.7" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-8.8">Create a new CSR using the "backup1"
key pair, and get a new certificate from your CA.<a href="#section-a.1-8.8" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-8.9">Generate a new backup key pair (backup2), get its hash, and store it
in a safe place (again, not on the live server).<a href="#section-a.1-8.9" class="pilcrow">¶</a>
</li>
          <li id="section-a.1-8.10">Replace your old certificate and old key pair, update the
"Public-Key-Pins" header to remove the old hash, and add the new
"backup2" key pair.<a href="#section-a.1-8.10" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-a.1-9">Note that in the above steps, both the certificate issuance as well as
the storage of the backup key pair involve manual steps. Even with an
automated CA that runs the ACME protocol <span>[<a href="#RFC8555" class="xref">RFC8555</a>]</span>, key backup would be a
challenge to automate.<a href="#section-a.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tack">
<section id="section-a.2">
        <h2 id="name-comparison-tack">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-comparison-tack" class="section-name selfRef">Comparison: TACK</a>
        </h2>
<p id="section-a.2-1">Compared with HPKP, TACK <span>[<a href="#I-D.perrin-tls-tack" class="xref">TLS-TACK</a>]</span> is more similar
to the current document.  It can even be argued that this document is a
symmetric-cryptography variant of TACK.  That said, there are still a
few significant differences:<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.2-2.1">Probably the most important difference is that with TACK, validation of
the server certificate is no longer required, and in fact TACK specifies
it as a "<span class="bcp14">MAY</span>" requirement (<span>[<a href="#I-D.perrin-tls-tack" class="xref">TLS-TACK</a>], <a href="https://tools.ietf.org/html/draft-perrin-tls-tack-02#section-5.3" class="relref">Section 5.3</a></span>).  With ticket pinning, certificate
validation by the client remains a <span class="bcp14">MUST</span> requirement, and the ticket acts
only as a second factor. If the pinning secret is compromised, the
server's security is not immediately at risk.<a href="#section-a.2-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-2.2">Both TACK and the current document are mostly orthogonal to the server
certificate as far as their life cycle, and so both can be deployed with
no manual steps.<a href="#section-a.2-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-2.3">TACK uses Elliptic Curve Digital Signature Algorithm 
(ECDSA) to sign the server's public key. This allows
cooperating clients to share server assertions between themselves. This
is an optional TACK feature, and one that cannot be done with pinning
tickets.<a href="#section-a.2-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-2.4">TACK allows multiple servers to share its public keys. Such sharing is
disallowed by the current document.<a href="#section-a.2-2.4" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-2.5">TACK does not allow the server to track a particular client, and so
has better privacy properties than the current document.<a href="#section-a.2-2.5" class="pilcrow">¶</a>
</li>
          <li id="section-a.2-2.6">TACK has an interesting way to determine the pin's lifetime, setting
it to the time period since the pin was first observed, with a hard
upper bound of 30 days.  The current document makes the lifetime explicit,
which may be more flexible to deploy.  For example, web sites that are
only visited rarely by users may opt for a longer period than other
sites that expect users to visit on a daily basis.<a href="#section-a.2-2.6" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="acknowledgments">
<section id="section-appendix.b">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.b-1">The original idea behind this proposal was published in <span>[<a href="#Oreo" class="xref">Oreo</a>]</span> by
Moti Yung, Benny Pinkas, and Omer Berkman.  The current protocol is
but a distant relative of the original Oreo protocol, and any errors
are the responsibility of the authors of this document alone.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">We would like to thank Adrian Farrel, Dave Garrett,
Daniel Kahn Gillmor,
Alexey Melnikov,
Yoav Nir,
Eric Rescorla, Benjamin Kaduk, and Rich Salz for their comments on this document.
Special thanks to Craig Francis for contributing the HPKP deployment
script, and to Ralph Holz for several fruitful discussions.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yaron Sheffer</span></div>
<div dir="auto" class="left"><span class="org">Intuit</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yaronf.ietf@gmail.com" class="email">yaronf.ietf@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Daniel Migault</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:daniel.migault@ericsson.com" class="email">daniel.migault@ericsson.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>