File: rfc9147.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 (4900 lines) | stat: -rw-r--r-- 264,583 bytes
<!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 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
<meta content="Eric Rescorla" name="author">
<meta content="Hannes Tschofenig" name="author">
<meta content="Nagendra Modadugu" name="author">
<meta content="
       This document specifies version 1.3 of the Datagram Transport Layer Security
(DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and message
forgery. 
       The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)
1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability.  Datagram semantics of the underlying transport are preserved by the DTLS protocol. 
       This document obsoletes RFC 6347. 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="Communication Security" name="keyword">
<meta content="9147" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9147.xml" rel="alternate" type="application/rfc+xml">
<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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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;
  }

}
/* 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-bottom: 0.25em;
  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.5em;
}
/* 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; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9147" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13-43" 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 9147</td>
<td class="center">DTLS 1.3</td>
<td class="right">April 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Rescorla, et al.</td>
<td class="center">Standards Track</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">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9147" class="eref">9147</a></dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc6347" class="eref">6347</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-04" class="published">April 2022</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">E. Rescorla</div>
<div class="org">Mozilla</div>
</div>
<div class="author">
      <div class="author-name">H. Tschofenig</div>
<div class="org">Arm Limited</div>
</div>
<div class="author">
      <div class="author-name">N. Modadugu</div>
<div class="org">Google, Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9147</h1>
<h1 id="title">The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document specifies version 1.3 of the Datagram Transport Layer Security
(DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the
Internet in a way that is designed to prevent eavesdropping, tampering, and message
forgery.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">The DTLS 1.3 protocol is based on the Transport Layer Security (TLS)
1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability.  Datagram semantics of the underlying transport are preserved by the DTLS protocol.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">This document obsoletes RFC 6347.<a href="#section-abstract-3" 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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in 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/rfc9147">https://www.rfc-editor.org/info/rfc9147</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) 2022 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
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the copyright in some of this
            material may not have granted the IETF Trust the right to allow
            modifications of such material outside the IETF Standards Process.
            Without obtaining an adequate license from the person(s)
            controlling the copyright in such materials, this document may not
            be modified outside the IETF Standards Process, and derivative
            works of it may not be created outside the IETF Standards Process,
            except to format it for publication as an RFC or to translate it
            into languages other than English.<a href="#section-boilerplate.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <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="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-dtls-design-rationale-and-o" class="xref">DTLS Design Rationale and Overview</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-packet-loss" class="xref">Packet Loss</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-reordering" class="xref">Reordering</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-fragmentation" class="xref">Fragmentation</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-replay-detection" class="xref">Replay Detection</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-the-dtls-record-layer" class="xref">The DTLS Record Layer</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-demultiplexing-dtls-records" class="xref">Demultiplexing DTLS Records</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-sequence-number-and-epoch" class="xref">Sequence Number and Epoch</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-processing-guidelines" class="xref">Processing Guidelines</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-reconstructing-the-sequence" class="xref">Reconstructing the Sequence Number and Epoch</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.3">
                    <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="xref">4.2.3</a>.  <a href="#name-record-number-encryption" class="xref">Record Number Encryption</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-transport-layer-mapping" class="xref">Transport Layer Mapping</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-pmtu-issues" class="xref">PMTU Issues</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-record-payload-protection" class="xref">Record Payload Protection</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.1">
                    <p id="section-toc.1-1.4.2.5.2.1.1"><a href="#section-4.5.1" class="xref">4.5.1</a>.  <a href="#name-anti-replay" class="xref">Anti-Replay</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.2">
                    <p id="section-toc.1-1.4.2.5.2.2.1"><a href="#section-4.5.2" class="xref">4.5.2</a>.  <a href="#name-handling-invalid-records" class="xref">Handling Invalid Records</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5.2.3">
                    <p id="section-toc.1-1.4.2.5.2.3.1"><a href="#section-4.5.3" class="xref">4.5.3</a>.  <a href="#name-aead-limits" class="xref">AEAD Limits</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-the-dtls-handshake-protocol" class="xref">The DTLS Handshake Protocol</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-denial-of-service-counterme" class="xref">Denial-of-Service Countermeasures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-dtls-handshake-message-form" class="xref">DTLS Handshake Message Format</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-clienthello-message" class="xref">ClientHello Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-serverhello-message" class="xref">ServerHello Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-handshake-message-fragmenta" class="xref">Handshake Message Fragmentation and Reassembly</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-endofearlydata-message" class="xref">EndOfEarlyData Message</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-dtls-handshake-flights" class="xref">DTLS Handshake Flights</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-timeout-and-retransmission" class="xref">Timeout and Retransmission</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.1">
                    <p id="section-toc.1-1.5.2.8.2.1.1"><a href="#section-5.8.1" class="xref">5.8.1</a>.  <a href="#name-state-machine" class="xref">State Machine</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.2">
                    <p id="section-toc.1-1.5.2.8.2.2.1"><a href="#section-5.8.2" class="xref">5.8.2</a>.  <a href="#name-timer-values" class="xref">Timer Values</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.3">
                    <p id="section-toc.1-1.5.2.8.2.3.1"><a href="#section-5.8.3" class="xref">5.8.3</a>.  <a href="#name-large-flight-sizes" class="xref">Large Flight Sizes</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8.2.4">
                    <p id="section-toc.1-1.5.2.8.2.4.1"><a href="#section-5.8.4" class="xref">5.8.4</a>.  <a href="#name-state-machine-duplication-f" class="xref">State Machine Duplication for Post-Handshake Messages</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9">
                <p id="section-toc.1-1.5.2.9.1"><a href="#section-5.9" class="xref">5.9</a>.  <a href="#name-cryptographic-label-prefix" class="xref">Cryptographic Label Prefix</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.10">
                <p id="section-toc.1-1.5.2.10.1"><a href="#section-5.10" class="xref">5.10</a>. <a href="#name-alert-messages" class="xref">Alert Messages</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.11">
                <p id="section-toc.1-1.5.2.11.1"><a href="#section-5.11" class="xref">5.11</a>. <a href="#name-establishing-new-associatio" class="xref">Establishing New Associations with Existing Parameters</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-example-of-handshake-with-t" class="xref">Example of Handshake with Timeout and Retransmission</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-epoch-values-and-rekeying" class="xref">Epoch Values and Rekeying</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-ack-message" class="xref">ACK Message</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-sending-acks" class="xref">Sending ACKs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-receiving-acks" class="xref">Receiving ACKs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-design-rationale" class="xref">Design Rationale</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-key-updates" class="xref">Key Updates</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-connection-id-updates" class="xref">Connection ID Updates</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-connection-id-example" class="xref">Connection ID Example</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-application-data-protocol" class="xref">Application Data Protocol</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-changes-since-dtls-12" class="xref">Changes since DTLS 1.2</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-updates-affecting-dtls-12" class="xref">Updates Affecting DTLS 1.2</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#section-15.1" class="xref">15.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#section-15.2" class="xref">15.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-protocol-data-structures-an" class="xref">Protocol Data Structures and Constant Values</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.1">
                <p id="section-toc.1-1.16.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-record-layer" class="xref">Record Layer</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.2">
                <p id="section-toc.1-1.16.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-handshake-protocol" class="xref">Handshake Protocol</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.3">
                <p id="section-toc.1-1.16.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-acks" class="xref">ACKs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16.2.4">
                <p id="section-toc.1-1.16.2.4.1"><a href="#appendix-A.4" class="xref">A.4</a>.  <a href="#name-connection-id-management" class="xref">Connection ID Management</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-analysis-of-limits-on-ccm-u" class="xref">Analysis of Limits on CCM Usage</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.1">
                <p id="section-toc.1-1.17.2.1.1"><a href="#appendix-B.1" class="xref">B.1</a>.  <a href="#name-confidentiality-limits" class="xref">Confidentiality Limits</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.2">
                <p id="section-toc.1-1.17.2.2.1"><a href="#appendix-B.2" class="xref">B.2</a>.  <a href="#name-integrity-limits" class="xref">Integrity Limits</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17.2.3">
                <p id="section-toc.1-1.17.2.3.1"><a href="#appendix-B.3" class="xref">B.3</a>.  <a href="#name-limits-for-aead_aes_128_ccm" class="xref">Limits for AEAD_AES_128_CCM_8</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.18">
            <p id="section-toc.1-1.18.1"><a href="#appendix-C" class="xref">Appendix C</a>.  <a href="#name-implementation-pitfalls" class="xref">Implementation Pitfalls</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.19">
            <p id="section-toc.1-1.19.1"><a href="#appendix-D" class="xref"></a><a href="#name-contributors" class="xref">Contributors</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.20">
            <p id="section-toc.1-1.20.1"><a href="#appendix-E" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</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">The primary goal of the TLS protocol is to establish an authenticated,
confidentiality- and integrity-protected channel between two communicating peers.
The TLS protocol is composed of two layers:
the TLS record protocol and the TLS handshake protocol. However, TLS must
run over a reliable transport channel -- typically TCP <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">There are applications that use UDP <span>[<a href="#RFC0768" class="xref">RFC0768</a>]</span> as a transport
and the Datagram Transport Layer
Security (DTLS) protocol has been developed to offer communication security protection
for those applications. DTLS is deliberately designed to be
as similar to TLS as possible, both to minimize new security invention and to
maximize the amount of code and infrastructure reuse.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">DTLS 1.0 <span>[<a href="#RFC4347" class="xref">RFC4347</a>]</span> was originally defined as a delta from TLS 1.1 <span>[<a href="#RFC4346" class="xref">RFC4346</a>]</span>, and
DTLS 1.2 <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span> was defined as a series of deltas to TLS 1.2 <span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span>.  There
is no DTLS 1.1; that version number was skipped in order to harmonize version numbers
with TLS.  This specification describes the most current version of the DTLS protocol
as a delta from TLS 1.3 <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span>. It obsoletes DTLS 1.2.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Implementations that speak both DTLS 1.2 and DTLS 1.3 can interoperate with those
that speak only DTLS 1.2 (using DTLS 1.2 of course), just as TLS 1.3 implementations
can interoperate with TLS 1.2 (see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#appendix-D" class="relref">Appendix D</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span> for details).
While backwards compatibility with DTLS 1.0 is possible, the use of DTLS 1.0 is not
recommended, as explained in <span><a href="https://www.rfc-editor.org/rfc/rfc7525#section-3.1.2" class="relref">Section 3.1.2</a> of [<a href="#RFC7525" class="xref">RFC7525</a>]</span>. <span>[<a href="#RFC8996" class="xref">DEPRECATE</a>]</span> forbids the use of DTLS 1.0.<a href="#section-1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conventions-and-terminology">
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
      </h2>
<p id="section-2-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-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">The following terms are used:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-3">
        <dt id="section-2-3.1">client:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.2">The endpoint initiating the DTLS connection.<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">association:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.4">Shared state between two endpoints established with
a DTLS handshake.<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.5">connection:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.6">Synonym for association.<a href="#section-2-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.7">endpoint:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.8">Either the client or server of the connection.<a href="#section-2-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.9">epoch:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.10">One set of cryptographic keys used for encryption and decryption.<a href="#section-2-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.11">handshake:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.12">An initial negotiation between client and server that establishes
the parameters of the connection.<a href="#section-2-3.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.13">peer:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.14">An endpoint. When discussing a particular endpoint, "peer" refers to
the endpoint that is remote to the primary subject of discussion.<a href="#section-2-3.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.15">receiver:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.16">An endpoint that is receiving records.<a href="#section-2-3.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.17">sender:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.18">An endpoint that is transmitting records.<a href="#section-2-3.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.19">server:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.20">The endpoint that did not initiate the DTLS connection.<a href="#section-2-3.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.21">CID:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.22">Connection ID.<a href="#section-2-3.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.23">MSL:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.24">Maximum Segment Lifetime.<a href="#section-2-3.24" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-4">The reader is assumed to be familiar with <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span>.
As in TLS 1.3, the HelloRetryRequest has the same format as a ServerHello
message, but for convenience we use the term HelloRetryRequest throughout
this document as if it were a distinct message.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">DTLS 1.3 uses network byte order (big-endian) format for encoding messages
based on the encoding format defined in <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span> and earlier (D)TLS specifications.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">The reader is also assumed to be familiar with <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>,
as this document applies the CID functionality to DTLS 1.3.<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">Figures in this document illustrate various combinations of the DTLS protocol exchanges, and the symbols have the following meaning:<a href="#section-2-7" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-8">
        <dt id="section-2-8.1">'+'</dt>
        <dd style="margin-left: 3.0em" id="section-2-8.2">indicates noteworthy extensions sent in the previously noted message.<a href="#section-2-8.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-8.3">'*'</dt>
        <dd style="margin-left: 3.0em" id="section-2-8.4">indicates optional or situation-dependent messages/extensions that are not always sent.<a href="#section-2-8.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-8.5">'{}'</dt>
        <dd style="margin-left: 3.0em" id="section-2-8.6">indicates messages protected using keys derived from a [sender]_handshake_traffic_secret.<a href="#section-2-8.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-8.7">'[]'</dt>
        <dd style="margin-left: 3.0em" id="section-2-8.8">indicates messages protected using keys derived from traffic_secret_N.<a href="#section-2-8.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="dtls-rational">
<section id="section-3">
      <h2 id="name-dtls-design-rationale-and-o">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-dtls-design-rationale-and-o" class="section-name selfRef">DTLS Design Rationale and Overview</a>
      </h2>
<p id="section-3-1">The basic design philosophy of DTLS is to construct "TLS over datagram transport".
Datagram transport neither requires nor provides reliable or in-order delivery of data.
The DTLS protocol preserves this property for application data.
Applications such as media streaming, Internet telephony, and online gaming use
datagram transport for communication due to the delay-sensitive nature
of transported data.  The behavior of such applications is unchanged when the
DTLS protocol is used to secure communication, since the DTLS protocol
does not compensate for lost or reordered data traffic. Note that while
low-latency streaming and gaming use DTLS to protect data (e.g., for
protection of a WebRTC data channel), telephony utilizes DTLS for
key establishment and the Secure Real-time Transport Protocol (SRTP) for
protection of data <span>[<a href="#RFC5763" class="xref">RFC5763</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">TLS cannot be used directly over datagram transports for the following four reasons:<a href="#section-3-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-3">
<li id="section-3-3.1">TLS relies on an implicit sequence number on records.  If a record is not
received, then the recipient will use the wrong sequence number when
attempting to remove record protection from subsequent records. DTLS solves
this problem by adding sequence numbers to records.<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-3.2">The TLS handshake is a lock-step cryptographic protocol.  Messages
must be transmitted and received in a defined order; any other
order is an error.  The DTLS handshake includes message sequence
numbers to enable fragmented message reassembly and in-order
delivery in case datagrams are lost or reordered.<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-3.3">Handshake messages are potentially larger than can be contained in a single
datagram.  DTLS adds fields to handshake messages to support fragmentation
and reassembly.<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
        <li id="section-3-3.4">Datagram transport protocols are susceptible to abusive behavior
effecting denial-of-service (DoS) attacks against nonparticipants.  DTLS adds a
return-routability check and DTLS 1.3 uses the TLS 1.3 HelloRetryRequest message
(see <a href="#dos" class="xref">Section 5.1</a> for details).<a href="#section-3-3.4" class="pilcrow">¶</a>
</li>
      </ol>
<div id="packet-loss">
<section id="section-3.1">
        <h3 id="name-packet-loss">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-packet-loss" class="section-name selfRef">Packet Loss</a>
        </h3>
<p id="section-3.1-1">DTLS uses a simple retransmission timer to handle packet loss.
<a href="#dtls-retransmission" class="xref">Figure 1</a> demonstrates the basic concept, using the first
phase of the DTLS handshake:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span id="name-dtls-retransmission-example"></span><div id="dtls-retransmission">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-3.1-2.1">
<pre>
         Client                                   Server
         ------                                   ------
         ClientHello           ------&gt;

                                 X&lt;-- HelloRetryRequest
                                                  (lost)

         [Timer Expires]

         ClientHello           ------&gt;
         (retransmit)
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-dtls-retransmission-example" class="selfRef">DTLS Retransmission Example</a>
          </figcaption></figure>
</div>
<p id="section-3.1-3">Once the client has transmitted the ClientHello message, it expects
to see a HelloRetryRequest or a ServerHello from the server. However, if the
timer expires, the client knows that either the
ClientHello or the response from the server has been lost, which
causes the client
to retransmit the ClientHello. When the server receives the retransmission,
it knows to retransmit its HelloRetryRequest or ServerHello.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">The server also maintains a retransmission timer for messages it
sends (other than HelloRetryRequest) and retransmits when that timer expires. Not
applying retransmissions to the HelloRetryRequest avoids the need to
create state on the server.  The HelloRetryRequest is designed to be
small enough that it will not itself be fragmented, thus avoiding
concerns about interleaving multiple HelloRetryRequests.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">For more detail on timeouts and retransmission,
see <a href="#timeout-retransmissions" class="xref">Section 5.8</a>.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reordering">
<section id="section-3.2">
        <h3 id="name-reordering">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-reordering" class="section-name selfRef">Reordering</a>
        </h3>
<p id="section-3.2-1">In DTLS, each handshake message is assigned a specific sequence
number.  When a peer receives a handshake
message, it can quickly determine whether that message is the next
message it expects.  If it is, then it processes it.  If not, it
queues it for future handling once all previous messages have been
received.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fragmentation">
<section id="section-3.3">
        <h3 id="name-fragmentation">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-fragmentation" class="section-name selfRef">Fragmentation</a>
        </h3>
<p id="section-3.3-1">TLS and DTLS handshake messages can be quite large (in theory up to
2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
datagrams are often limited to less than 1500 bytes if IP fragmentation is not
desired.  In order to compensate for this limitation, each DTLS
handshake message may be fragmented over several DTLS records, each
of which is intended to fit in a single UDP datagram
(see <a href="#pmtu-issues" class="xref">Section 4.4</a> for guidance). Each DTLS
handshake message contains both a fragment offset and a fragment
length.  Thus, a recipient in possession of all bytes of a handshake
message can reassemble the original unfragmented message.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="replay-detection">
<section id="section-3.4">
        <h3 id="name-replay-detection">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-replay-detection" class="section-name selfRef">Replay Detection</a>
        </h3>
<p id="section-3.4-1">DTLS optionally supports record replay detection.  The technique used
is the same as in IPsec AH/ESP, by maintaining a bitmap window of
received records.  Records that are too old to fit in the window and
records that have previously been received are silently discarded.
The replay detection feature is optional, since packet duplication is
not always malicious but can also occur due to routing errors.
Applications may conceivably detect duplicate packets and accordingly
modify their data transmission strategy.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="the-dtls-record-layer">
<section id="section-4">
      <h2 id="name-the-dtls-record-layer">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-the-dtls-record-layer" class="section-name selfRef">The DTLS Record Layer</a>
      </h2>
<p id="section-4-1">The DTLS 1.3 record layer is different from the TLS 1.3 record layer and
also different from the DTLS 1.2 record layer.<a href="#section-4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-2">
<li id="section-4-2.1">The DTLSCiphertext structure omits the superfluous version number and
type fields.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">DTLS adds an epoch and sequence number to the TLS record header.
This sequence number allows the recipient to correctly decrypt and verify DTLS records.
However, the number of bits used for the epoch and sequence number fields in
the DTLSCiphertext structure has been reduced from those in previous
        versions.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">
The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility
   with DTLS 1.2. However, this value is set as the least significant 2 octets
   of the connection epoch, which is an 8 octet counter incremented on every
   KeyUpdate. See <a href="#sequence-number-and-epoch" class="xref">Section 4.2</a> for details. The sequence number is set to
   be the low order 48 bits of the 64 bit sequence number. Plaintext records
   <span class="bcp14">MUST NOT</span> be sent with sequence numbers that would exceed 2^48-1, so the
   upper 16 bits will always be 0.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.4">The DTLSCiphertext structure has a variable-length header.<a href="#section-4-2.4" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-4-3">DTLSPlaintext records are used to send unprotected records and DTLSCiphertext
records are used to send protected records.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">The DTLS record formats are shown below. Unless explicitly stated the
meaning of the fields is unchanged from previous TLS/DTLS versions.<a href="#section-4-4" class="pilcrow">¶</a></p>
<span id="name-dtls-13-record-formats"></span><div id="dtls-record">
<figure id="figure-2">
        <div id="section-4-5.1">
<pre class="lang-tls-presentation sourcecode">
    struct {
        ContentType type;
        ProtocolVersion legacy_record_version;
        uint16 epoch = 0
        uint48 sequence_number;
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
    } DTLSPlaintext;

    struct {
         opaque content[DTLSPlaintext.length];
         ContentType type;
         uint8 zeros[length_of_padding];
    } DTLSInnerPlaintext;

    struct {
        opaque unified_hdr[variable];
        opaque encrypted_record[length];
    } DTLSCiphertext;
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-dtls-13-record-formats" class="selfRef">DTLS 1.3 Record Formats</a>
        </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4-6">
        <dt id="section-4-6.1">legacy_record_version:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.2">
  This value <span class="bcp14">MUST</span> be set to {254, 253} for all records other
than the initial ClientHello (i.e., one not generated after a HelloRetryRequest),
where it may also be {254, 255} for compatibility purposes.
        It <span class="bcp14">MUST</span> be ignored for all purposes. See <span>[<a href="#RFC8446" class="xref">TLS13</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#appendix-D.1" class="relref">Appendix D.1</a></span> for the rationale for this.<a href="#section-4-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.3">epoch:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.4">The least significant 2 bytes of the connection epoch value.<a href="#section-4-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.5">unified_hdr:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.6">
The unified header (unified_hdr) is a structure of variable length, shown in <a href="#cid_hdr" class="xref">Figure 3</a>.<a href="#section-4-6.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.7">encrypted_record:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.8">
  The encrypted form of the serialized DTLSInnerPlaintext structure.<a href="#section-4-6.8" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span id="name-dtls-13-unified-header"></span><div id="cid_hdr">
<figure id="figure-3">
        <div class="alignLeft art-text artwork" id="section-4-7.1">
<pre>
    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|0|1|C|S|L|E E|
    +-+-+-+-+-+-+-+-+
    | Connection ID |   Legend:
    | (if any,      |
    /  length as    /   C   - Connection ID (CID) present
    |  negotiated)  |   S   - Sequence number length
    +-+-+-+-+-+-+-+-+   L   - Length present
    |  8 or 16 bit  |   E   - Epoch
    |Sequence Number|
    +-+-+-+-+-+-+-+-+
    | 16 bit Length |
    | (if present)  |
    +-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-dtls-13-unified-header" class="selfRef">DTLS 1.3 Unified Header</a>
        </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4-8">
        <dt id="section-4-8.1">Fixed Bits:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.2">
  The three high bits of the first byte of the unified header are set to
001. This ensures that the value will fit within the DTLS region when
multiplexing is performed as described in <span>[<a href="#RFC7983" class="xref">RFC7983</a>]</span>. It also ensures
that distinguishing encrypted DTLS 1.3 records from encrypted DTLS 1.2
records is possible when they are carried on the same host/port quartet;
such multiplexing is only possible when CIDs <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>
are in use, in which case DTLS 1.2 records will have the content type tls12_cid (25).<a href="#section-4-8.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.3">C:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.4">
  The C bit (0x10) is set if the Connection ID is present.<a href="#section-4-8.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.5">S:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.6">
  The S bit (0x08) indicates the size of the sequence number.
0 means an 8-bit sequence number, 1 means 16-bit.
 Implementations <span class="bcp14">MAY</span> mix sequence numbers of different lengths
 on the same connection.<a href="#section-4-8.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.7">L:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.8">
  The L bit (0x04) is set if the length is present.<a href="#section-4-8.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.9">E:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.10">
  The two low bits (0x03) include the low-order two bits of the epoch.<a href="#section-4-8.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.11">Connection ID:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.12">
  Variable-length CID. The CID functionality
is described in <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>. An example
can be found in <a href="#connection-id-example" class="xref">Section 9.1</a>.<a href="#section-4-8.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.13">Sequence Number:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.14">
  The low-order 8 or 16 bits of the record sequence number.  This value is 16
bits if the S bit is set to 1, and 8 bits if the S bit is 0.<a href="#section-4-8.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-8.15">Length:</dt>
        <dd style="margin-left: 1.5em" id="section-4-8.16">
  Identical to the length field in a TLS 1.3 record.<a href="#section-4-8.16" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-9">As with previous versions of DTLS, multiple DTLSPlaintext
and DTLSCiphertext records can be included in the same
underlying transport datagram.<a href="#section-4-9" class="pilcrow">¶</a></p>
<p id="section-4-10"><a href="#hdr_examples" class="xref">Figure 4</a> illustrates different record headers.<a href="#section-4-10" class="pilcrow">¶</a></p>
<span id="name-dtls-13-header-examples"></span><div id="hdr_examples">
<figure id="figure-4">
        <div class="alignLeft art-text artwork" id="section-4-11.1">
<pre>
 0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7       0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
| Content Type  |     |0|0|1|1|1|1|E E|     |0|0|1|0|0|0|E E|
+-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|   16 bit      |     |               |     |8 bit Seq. No. |
|   Version     |     / Connection ID /     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+     |               |     |               |
|   16 bit      |     +-+-+-+-+-+-+-+-+     |   Encrypted   |
|    Epoch      |     |    16 bit     |     /   Record      /
+-+-+-+-+-+-+-+-+     |Sequence Number|     |               |
|               |     +-+-+-+-+-+-+-+-+     +-+-+-+-+-+-+-+-+
|               |     |   16 bit      |
|   48 bit      |     |   Length      |       DTLSCiphertext
|Sequence Number|     +-+-+-+-+-+-+-+-+         Structure
|               |     |               |         (minimal)
|               |     |  Encrypted    |
+-+-+-+-+-+-+-+-+     /  Record       /
|    16 bit     |     |               |
|    Length     |     +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|               |      DTLSCiphertext
|               |        Structure
/   Fragment    /          (full)
|               |
+-+-+-+-+-+-+-+-+

 DTLSPlaintext
   Structure
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-dtls-13-header-examples" class="selfRef">DTLS 1.3 Header Examples</a>
        </figcaption></figure>
</div>
<p id="section-4-12">The length field <span class="bcp14">MAY</span> be omitted by clearing the L bit, which means that the
record consumes the entire rest of the datagram in the lower
level transport. In this case, it is not possible to have multiple
DTLSCiphertext format records without length fields in the same datagram.
Omitting the length field <span class="bcp14">MUST</span> only be used for the last record in a
datagram. Implementations <span class="bcp14">MAY</span> mix records with and without length
fields on the same connection.<a href="#section-4-12" class="pilcrow">¶</a></p>
<p id="section-4-13">If a Connection ID is negotiated, then it <span class="bcp14">MUST</span> be contained in all
datagrams. Sending implementations <span class="bcp14">MUST NOT</span> mix records from multiple DTLS associations
in the same datagram. If the second or later record has a connection
ID which does not correspond to the same association used
for previous records, the rest of the datagram <span class="bcp14">MUST</span> be discarded.<a href="#section-4-13" class="pilcrow">¶</a></p>
<p id="section-4-14">When expanded, the epoch and sequence number can be combined into an
unpacked RecordNumber structure, as shown below:<a href="#section-4-14" class="pilcrow">¶</a></p>
<div id="section-4-15">
<pre class="lang-tls-presentation sourcecode">
    struct {
        uint64 epoch;
        uint64 sequence_number;
    } RecordNumber;
</pre><a href="#section-4-15" class="pilcrow">¶</a>
</div>
<p id="section-4-16">This 128-bit value is used in the ACK message as well as in the "record_sequence_number"
input to the Authenticated Encryption with Associated Data (AEAD) function.
      The entire header value shown in <a href="#hdr_examples" class="xref">Figure 4</a> (but prior to record number
encryption; see <a href="#rne" class="xref">Section 4.2.3</a>) is used as the additional data value for the AEAD
function. For instance, if the minimal variant is used,
the Associated Data (AD) is 2 octets long. Note that this design is different from the additional data
calculation for DTLS 1.2 and for DTLS 1.2 with Connection IDs.
In DTLS 1.3 the 64-bit sequence_number is used as the sequence number for
the AEAD computation; unlike DTLS 1.2, the epoch is not included.<a href="#section-4-16" class="pilcrow">¶</a></p>
<div id="demultiplexing-dtls-records">
<section id="section-4.1">
        <h3 id="name-demultiplexing-dtls-records">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-demultiplexing-dtls-records" class="section-name selfRef">Demultiplexing DTLS Records</a>
        </h3>
<p id="section-4.1-1">
          DTLS 1.3's header format is more complicated to demux than
DTLS 1.2, which always carried the content type as the first
byte. As described in <a href="#demux" class="xref">Figure 5</a>, the first byte determines how an incoming
DTLS record is demultiplexed. The first 3 bits of the first byte
distinguish a DTLS 1.3 encrypted record from record types used in
previous DTLS versions and plaintext DTLS 1.3 record types. Hence, the
range 32 (0b0010 0000) to 63 (0b0011 1111) needs to be excluded
from future allocations by IANA to avoid problems while demultiplexing;
see <a href="#iana-considerations" class="xref">Section 14</a>.
Implementations can demultiplex DTLS 1.3 records
by examining the first byte as follows:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.1-2.1">If the first byte is alert(21), handshake(22), or ack(proposed, 26),
the record <span class="bcp14">MUST</span> be interpreted as a DTLSPlaintext record.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.2">If the first byte is any other value, then receivers
<span class="bcp14">MUST</span> check to see if the leading bits of the first byte are
001. If so, the implementation <span class="bcp14">MUST</span> process the record as
DTLSCiphertext; the true content type will be inside the
protected portion.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.1-2.3">Otherwise, the record <span class="bcp14">MUST</span> be rejected as if it had failed
deprotection, as described in <a href="#handling-invalid-records" class="xref">Section 4.5.2</a>.<a href="#section-4.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.1-3"><a href="#demux" class="xref">Figure 5</a> shows this demultiplexing procedure graphically,
taking DTLS 1.3 and earlier versions of DTLS into account.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<span id="name-demultiplexing-dtls-12-and-"></span><div id="demux">
<figure id="figure-5">
          <div class="alignLeft art-text artwork" id="section-4.1-4.1">
<pre>
             +----------------+
             | Outer Content  |
             |   Type (OCT)   |
             |                |
             |   OCT == 20   -+--&gt; ChangeCipherSpec (DTLS &lt;1.3)
             |   OCT == 21   -+--&gt; Alert (Plaintext)
             |   OCT == 22   -+--&gt; DTLSHandshake (Plaintext)
             |   OCT == 23   -+--&gt; Application Data (DTLS &lt;1.3)
             |   OCT == 24   -+--&gt; Heartbeat (DTLS &lt;1.3)
packet  --&gt;  |   OCT == 25   -+--&gt; DTLSCiphertext with CID (DTLS 1.2)
             |   OCT == 26   -+--&gt; ACK (DTLS 1.3, Plaintext)
             |                |
             |                |   /+----------------+\
             | 31 &lt; OCT &lt; 64 -+--&gt; |DTLSCiphertext  |
             |                |    |(header bits    |
             |      else      |    | start with 001)|
             |       |        |   /+-------+--------+\
             +-------+--------+            |
                     |                     |
                     v          Decryption |
               +---------+          +------+
               |  Reject |          |
               +---------+          v
                            +----------------+
                            | Decrypted      |
                            | Content Type   |
                            | (DCT)          |
                            |                |
                            |     DCT == 21 -+--&gt; Alert
                            |     DCT == 22 -+--&gt; DTLSHandshake
                            |     DCT == 23 -+--&gt; Application Data
                            |     DCT == 24 -+--&gt; Heartbeat
                            |     DCT == 26 -+--&gt; ACK
                            |     else ------+--&gt; Error
                            +----------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-demultiplexing-dtls-12-and-" class="selfRef">Demultiplexing DTLS 1.2 and DTLS 1.3 Records</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sequence-number-and-epoch">
<section id="section-4.2">
        <h3 id="name-sequence-number-and-epoch">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-sequence-number-and-epoch" class="section-name selfRef">Sequence Number and Epoch</a>
        </h3>
<p id="section-4.2-1">DTLS uses an explicit or partly explicit sequence number, rather than an implicit one,
carried in the sequence_number field of the record.  Sequence numbers
are maintained separately for each epoch, with each sequence_number
initially being 0 for each epoch.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">The epoch number is initially zero and is incremented each time
keying material changes and a sender aims to rekey. More details
are provided in <a href="#dtls-epoch" class="xref">Section 6.1</a>.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<div id="processing-guidelines">
<section id="section-4.2.1">
          <h4 id="name-processing-guidelines">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-processing-guidelines" class="section-name selfRef">Processing Guidelines</a>
          </h4>
<p id="section-4.2.1-1">Because DTLS records could be reordered, a record from epoch
M may be received after epoch N (where N &gt; M) has begun.
Implementations <span class="bcp14">SHOULD</span> discard records from earlier epochs but
<span class="bcp14">MAY</span> choose to
retain keying material from previous epochs for up to the default MSL
specified for TCP <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span> to allow for packet reordering.  (Note that
the intention here is that implementers use the current guidance from
the IETF for MSL, as specified in <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span> or successors,
not that they attempt to interrogate the MSL that
the system TCP stack is using.)<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<p id="section-4.2.1-2">Conversely, it is possible for records that are protected with the
new epoch to be received prior to the completion of a
handshake.  For instance, the server may send its Finished message
and then start transmitting data.  Implementations <span class="bcp14">MAY</span> either buffer
or discard such records, though when DTLS is used over reliable
transports (e.g., SCTP <span>[<a href="#RFC4960" class="xref">RFC4960</a>]</span>), they <span class="bcp14">SHOULD</span> be buffered and
processed once the handshake completes.  Note that TLS's restrictions
on when records may be sent still apply, and the receiver treats the
records as if they were sent in the right order.<a href="#section-4.2.1-2" class="pilcrow">¶</a></p>
<p id="section-4.2.1-3">Implementations <span class="bcp14">MUST</span> send retransmissions of lost messages using the same
epoch and keying material as the original transmission.<a href="#section-4.2.1-3" class="pilcrow">¶</a></p>
<p id="section-4.2.1-4">Implementations <span class="bcp14">MUST</span> either abandon an association or rekey prior to
allowing the sequence number to wrap.<a href="#section-4.2.1-4" class="pilcrow">¶</a></p>
<p id="section-4.2.1-5">Implementations <span class="bcp14">MUST NOT</span> allow the epoch to wrap, but instead <span class="bcp14">MUST</span>
establish a new association, terminating the old association.<a href="#section-4.2.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reconstructing">
<section id="section-4.2.2">
          <h4 id="name-reconstructing-the-sequence">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-reconstructing-the-sequence" class="section-name selfRef">Reconstructing the Sequence Number and Epoch</a>
          </h4>
<p id="section-4.2.2-1">When receiving protected DTLS records, the recipient does not
have a full epoch or sequence number value in the record and so there is some
opportunity for ambiguity.  Because the full sequence number
is used to compute the per-record nonce and the epoch determines
the keys, failure to reconstruct these
values leads to failure to deprotect the record, and so implementations
<span class="bcp14">MAY</span> use a mechanism of their choice to determine the full values.
This section provides an algorithm which is comparatively simple
and which implementations are <span class="bcp14">RECOMMENDED</span> to follow.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">If the epoch bits match those of the current epoch, then
implementations <span class="bcp14">SHOULD</span> reconstruct the sequence number by computing
the full sequence number which is numerically closest to one plus the
sequence number of the highest successfully deprotected record in the
current epoch.<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2.2-3">During the handshake phase, the epoch bits unambiguously indicate the
correct key to use. After the
handshake is complete, if the epoch bits do not match those from the
current epoch, implementations <span class="bcp14">SHOULD</span> use the most recent past epoch
which has matching bits, and then reconstruct the sequence number for
that epoch as described above.<a href="#section-4.2.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="rne">
<section id="section-4.2.3">
          <h4 id="name-record-number-encryption">
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-record-number-encryption" class="section-name selfRef">Record Number Encryption</a>
          </h4>
<p id="section-4.2.3-1">In DTLS 1.3, when records are encrypted, record sequence numbers are
also encrypted. The basic pattern is that the underlying encryption
algorithm used with the AEAD algorithm is used to generate a mask
which is then XORed with the sequence number.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
<p id="section-4.2.3-2">When the AEAD is based on AES, then the mask is generated by
computing AES-ECB on the first 16 bytes of the ciphertext:<a href="#section-4.2.3-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.2.3-3">
<pre>
  Mask = AES-ECB(sn_key, Ciphertext[0..15])
</pre><a href="#section-4.2.3-3" class="pilcrow">¶</a>
</div>
<p id="section-4.2.3-4">When the AEAD is based on ChaCha20, then the mask is generated
by treating the first 4 bytes of the ciphertext as the block
counter and the next 12 bytes as the nonce, passing them to the ChaCha20
block function (<span><a href="https://www.rfc-editor.org/rfc/rfc8439#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC8439" class="xref">CHACHA</a>]</span>):<a href="#section-4.2.3-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.2.3-5">
<pre>
  Mask = ChaCha20(sn_key, Ciphertext[0..3], Ciphertext[4..15])
</pre><a href="#section-4.2.3-5" class="pilcrow">¶</a>
</div>
<p id="section-4.2.3-6">The sn_key is computed as follows:<a href="#section-4.2.3-6" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.2.3-7">
<pre>
  [sender]_sn_key = HKDF-Expand-Label(Secret, "sn", "", key_length)
</pre><a href="#section-4.2.3-7" class="pilcrow">¶</a>
</div>
<p id="section-4.2.3-8">[sender] denotes the sending side. The per-epoch Secret value to be used is described
in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.3" class="relref">Section 7.3</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>. Note that a new key is used for each epoch: because the epoch is sent in the clear, this does not result in ambiguity.<a href="#section-4.2.3-8" class="pilcrow">¶</a></p>
<p id="section-4.2.3-9">The encrypted sequence number is computed by XORing the leading
bytes of the mask with the on-the-wire representation of the
sequence number. Decryption is accomplished by the same process.<a href="#section-4.2.3-9" class="pilcrow">¶</a></p>
<p id="section-4.2.3-10">This procedure requires the ciphertext length to be at least 16 bytes. Receivers
<span class="bcp14">MUST</span> reject shorter records as if they had failed deprotection, as described in
<a href="#handling-invalid-records" class="xref">Section 4.5.2</a>. Senders <span class="bcp14">MUST</span> pad short plaintexts out (using the
conventional record padding mechanism) in order to make a suitable-length
ciphertext. Note that most of the DTLS AEAD algorithms have a 16 byte authentication
tag and need no padding. However, some algorithms, such as
TLS_AES_128_CCM_8_SHA256, have a shorter authentication tag and may require padding
for short inputs.<a href="#section-4.2.3-10" class="pilcrow">¶</a></p>
<p id="section-4.2.3-11">Future cipher suites, which are not based on AES or ChaCha20, <span class="bcp14">MUST</span> define
their own record sequence number encryption in order to be used with
DTLS.<a href="#section-4.2.3-11" class="pilcrow">¶</a></p>
<p id="section-4.2.3-12">Note that sequence number encryption is only applied to the DTLSCiphertext
structure and not to the DTLSPlaintext structure, even though it also contains a
sequence number.<a href="#section-4.2.3-12" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="transport-layer-mapping">
<section id="section-4.3">
        <h3 id="name-transport-layer-mapping">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-transport-layer-mapping" class="section-name selfRef">Transport Layer Mapping</a>
        </h3>
<p id="section-4.3-1">DTLS messages <span class="bcp14">MAY</span> be fragmented into multiple DTLS records.
Each DTLS record <span class="bcp14">MUST</span> fit within a single datagram.  In order to
avoid IP fragmentation, clients of the DTLS record layer <span class="bcp14">SHOULD</span>
attempt to size records so that they fit within any Path MTU (PMTU) estimates
obtained from the record layer. For more information about PMTU issues,
see <a href="#pmtu-issues" class="xref">Section 4.4</a>.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Multiple DTLS records <span class="bcp14">MAY</span> be placed in a single datagram.  Records are encoded
consecutively.  The length field from DTLS records containing that field can be
used to determine the boundaries between records.  The final record in a
datagram can omit the length field.  The first byte of the datagram payload <span class="bcp14">MUST</span>
be the beginning of a record.  Records <span class="bcp14">MUST NOT</span> span datagrams.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">DTLS records without CIDs do not contain any association
identifiers, and applications must arrange to multiplex between associations.
With UDP, the host/port number is used to look up the appropriate security
association for incoming records without CIDs.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4">Some transports, such as DCCP <span>[<a href="#RFC4340" class="xref">RFC4340</a>]</span>, provide their own sequence
numbers.  When carried over those transports, both the DTLS and the
transport sequence numbers will be present.  Although this introduces
a small amount of inefficiency, the transport layer and DTLS sequence
numbers serve different purposes; therefore, for conceptual simplicity,
it is superior to use both sequence numbers.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">Some transports provide congestion control for traffic
carried over them.  If the congestion window is sufficiently narrow,
DTLS handshake retransmissions may be held rather than transmitted
immediately, potentially leading to timeouts and spurious
retransmission.  When DTLS is used over such transports, care should
be taken not to overrun the likely congestion window. <span>[<a href="#RFC5238" class="xref">RFC5238</a>]</span>
defines a mapping of DTLS to DCCP that takes these issues into account.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pmtu-issues">
<section id="section-4.4">
        <h3 id="name-pmtu-issues">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-pmtu-issues" class="section-name selfRef">PMTU Issues</a>
        </h3>
<p id="section-4.4-1">In general, DTLS's philosophy is to leave PMTU discovery to the application.
However, DTLS cannot completely ignore the PMTU for three reasons:<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-2.1">The DTLS record framing expands the datagram size, thus lowering
the effective PMTU from the application's perspective.<a href="#section-4.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-2.2">In some implementations, the application may not directly talk to
the network, in which case the DTLS stack may absorb ICMP
"Datagram Too Big" indications <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> or ICMPv6
"Packet Too Big" indications <span>[<a href="#RFC4443" class="xref">RFC4443</a>]</span>.<a href="#section-4.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-2.3">The DTLS handshake messages can exceed the PMTU.<a href="#section-4.4-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.4-3">In order to deal with the first two issues, the DTLS record layer
<span class="bcp14">SHOULD</span> behave as described below.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">If PMTU estimates are available from the underlying transport
protocol, they should be made available to upper layer
protocols. In particular:<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-5.1">For DTLS over UDP, the upper layer protocol <span class="bcp14">SHOULD</span> be allowed to
obtain the PMTU estimate maintained in the IP layer.<a href="#section-4.4-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-5.2">For DTLS over DCCP, the upper layer protocol <span class="bcp14">SHOULD</span> be allowed to
obtain the current estimate of the PMTU.<a href="#section-4.4-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-5.3">For DTLS over TCP or SCTP, which automatically fragment and
reassemble datagrams, there is no PMTU limitation.  However, the
upper layer protocol <span class="bcp14">MUST NOT</span> write any record that exceeds the
maximum record size of 2^14 bytes.<a href="#section-4.4-5.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.4-6">The DTLS record layer <span class="bcp14">SHOULD</span> also allow the upper layer protocol to
discover the amount of record expansion expected by the DTLS
processing; alternately, it <span class="bcp14">MAY</span> report PMTU estimates minus the
estimated expansion from the transport layer and DTLS record
framing.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<p id="section-4.4-7">Note that DTLS does not defend against spoofed ICMP messages;
implementations <span class="bcp14">SHOULD</span> ignore any such messages that indicate
PMTUs below the IPv4 and IPv6 minimums of 576 and 1280 bytes,
respectively.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
<p id="section-4.4-8">If there is a transport protocol indication that the PMTU was exceeded
(either via ICMP or via a
refusal to send the datagram as in <span><a href="https://www.rfc-editor.org/rfc/rfc4340#section-14" class="relref">Section 14</a> of [<a href="#RFC4340" class="xref">RFC4340</a>]</span>), then the
DTLS record layer <span class="bcp14">MUST</span> inform the upper layer protocol of the error.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
<p id="section-4.4-9">The DTLS record layer <span class="bcp14">SHOULD NOT</span> interfere with upper layer protocols
performing PMTU discovery, whether via <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> and <span>[<a href="#RFC4821" class="xref">RFC4821</a>]</span> for
IPv4 or via <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> for IPv6.  In particular:<a href="#section-4.4-9" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-10.1">Where allowed by the underlying transport protocol, the upper
layer protocol <span class="bcp14">SHOULD</span> be allowed to set the state of the Don't Fragment (DF) bit
(in IPv4) or prohibit local fragmentation (in IPv6).<a href="#section-4.4-10.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-10.2">If the underlying transport protocol allows the application to
request PMTU probing (e.g., DCCP), the DTLS record layer <span class="bcp14">SHOULD</span>
honor this request.<a href="#section-4.4-10.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.4-11">The final issue is the DTLS handshake protocol.  From the perspective
of the DTLS record layer, this is merely another upper layer
protocol.  However, DTLS handshakes occur infrequently and involve
only a few round trips; therefore, the handshake protocol PMTU
handling places a premium on rapid completion over accurate PMTU
discovery.  In order to allow connections under these circumstances,
DTLS implementations <span class="bcp14">SHOULD</span> follow the following rules:<a href="#section-4.4-11" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-12.1">If the DTLS record layer informs the DTLS handshake layer that a
message is too big, the handshake layer <span class="bcp14">SHOULD</span> immediately attempt to fragment
the message, using any existing information about the PMTU.<a href="#section-4.4-12.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-12.2">If repeated retransmissions do not result in a response, and the
PMTU is unknown, subsequent retransmissions <span class="bcp14">SHOULD</span> back off to a
smaller record size, fragmenting the handshake message as
appropriate.  This specification does not specify an exact number of
retransmits to attempt before backing off, but 2-3 seems
appropriate.<a href="#section-4.4-12.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="record-payload-protection">
<section id="section-4.5">
        <h3 id="name-record-payload-protection">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-record-payload-protection" class="section-name selfRef">Record Payload Protection</a>
        </h3>
<p id="section-4.5-1">Like TLS, DTLS transmits data as a series of protected records.  The
rest of this section describes the details of that format.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<div id="anti-replay">
<section id="section-4.5.1">
          <h4 id="name-anti-replay">
<a href="#section-4.5.1" class="section-number selfRef">4.5.1. </a><a href="#name-anti-replay" class="section-name selfRef">Anti-Replay</a>
          </h4>
<p id="section-4.5.1-1">Each DTLS record contains a sequence number to provide replay protection.
Sequence number verification <span class="bcp14">SHOULD</span> be performed using the following
sliding window procedure, borrowed from <span><a href="https://www.rfc-editor.org/rfc/rfc4303#section-3.4.3" class="relref">Section 3.4.3</a> of [<a href="#RFC4303" class="xref">RFC4303</a>]</span>.
Because each epoch resets the sequence number space, a separate sliding
window is needed for each epoch.<a href="#section-4.5.1-1" class="pilcrow">¶</a></p>
<p id="section-4.5.1-2">The received record counter for an epoch <span class="bcp14">MUST</span> be initialized to
zero when that epoch is first used. For each received record, the
receiver <span class="bcp14">MUST</span> verify that the record contains a sequence number that
does not duplicate the sequence number of any other record received
in that epoch during the lifetime of the association.
This check <span class="bcp14">SHOULD</span> happen after
deprotecting the record; otherwise, the record discard might itself
serve as a timing channel for the record number. Note that computing
the full record number from the partial is still a potential timing
channel for the record number, though a less powerful one than whether
the record was deprotected.<a href="#section-4.5.1-2" class="pilcrow">¶</a></p>
<p id="section-4.5.1-3">Duplicates are rejected through the use of a sliding receive window.
(How the window is implemented is a local matter, but the following
text describes the functionality that the implementation must
exhibit.) The receiver <span class="bcp14">SHOULD</span> pick a window large enough to handle
any plausible reordering, which depends on the data rate.
(The receiver does not notify the sender of the window
size.)<a href="#section-4.5.1-3" class="pilcrow">¶</a></p>
<p id="section-4.5.1-4">The "right" edge of the window represents the highest validated
sequence number value received in the epoch.  Records that contain
sequence numbers lower than the "left" edge of the window are
rejected.  Records falling within the window are checked against a
list of received records within the window.  An efficient means for
performing this check, based on the use of a bit mask, is described in
<span><a href="https://www.rfc-editor.org/rfc/rfc4303#section-3.4.3" class="relref">Section 3.4.3</a> of [<a href="#RFC4303" class="xref">RFC4303</a>]</span>. If the received record falls within the
window and is new, or if the record is to the right of the window,
then the record is new.<a href="#section-4.5.1-4" class="pilcrow">¶</a></p>
<p id="section-4.5.1-5">The window <span class="bcp14">MUST NOT</span> be updated due to a received record until that record has been deprotected
successfully.<a href="#section-4.5.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="handling-invalid-records">
<section id="section-4.5.2">
          <h4 id="name-handling-invalid-records">
<a href="#section-4.5.2" class="section-number selfRef">4.5.2. </a><a href="#name-handling-invalid-records" class="section-name selfRef">Handling Invalid Records</a>
          </h4>
<p id="section-4.5.2-1">Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
invalid formatting, length, MAC, etc.).  In general, invalid records
<span class="bcp14">SHOULD</span> be silently discarded, thus preserving the association;
however, an error <span class="bcp14">MAY</span> be logged for diagnostic purposes.
Implementations which choose to generate an alert instead <span class="bcp14">MUST</span>
generate fatal alerts to avoid attacks where the attacker
repeatedly probes the implementation to see how it responds to
various types of error.  Note that if DTLS is run over UDP, then any
implementation which does this will be extremely susceptible to
DoS attacks because UDP forgery is so easy.
Thus, generating fatal alerts is <span class="bcp14">NOT RECOMMENDED</span> for such transports, both
to increase the reliability of DTLS service and to avoid the risk
of spoofing attacks sending traffic to unrelated third parties.<a href="#section-4.5.2-1" class="pilcrow">¶</a></p>
<p id="section-4.5.2-2">If DTLS is being carried over a transport that is resistant to
forgery (e.g., SCTP with SCTP-AUTH), then it is safer to send alerts
because an attacker will have difficulty forging a datagram that will
not be rejected by the transport layer.<a href="#section-4.5.2-2" class="pilcrow">¶</a></p>
<p id="section-4.5.2-3">Note that because invalid records are rejected at a layer lower than
the handshake state machine, they do not affect pending
retransmission timers.<a href="#section-4.5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="aead-limits">
<section id="section-4.5.3">
          <h4 id="name-aead-limits">
<a href="#section-4.5.3" class="section-number selfRef">4.5.3. </a><a href="#name-aead-limits" class="section-name selfRef">AEAD Limits</a>
          </h4>
<p id="section-4.5.3-1"><span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span> defines limits on the number of records that can
be protected using the same keys. These limits are specific to an AEAD
algorithm and apply equally to DTLS. Implementations <span class="bcp14">SHOULD NOT</span> protect more
records than allowed by the limit specified for the negotiated AEAD.
Implementations <span class="bcp14">SHOULD</span> initiate a key update before reaching this limit.<a href="#section-4.5.3-1" class="pilcrow">¶</a></p>
<p id="section-4.5.3-2"><span>[<a href="#RFC8446" class="xref">TLS13</a>]</span> does not specify a limit for AEAD_AES_128_CCM, but the analysis in
<a href="#ccm-bounds" class="xref">Appendix B</a> shows that a limit of 2^23 packets can be used to obtain the
same confidentiality protection as the limits specified in TLS.<a href="#section-4.5.3-2" class="pilcrow">¶</a></p>
<p id="section-4.5.3-3">The usage limits defined in TLS 1.3 exist for protection against attacks
on confidentiality and apply to successful applications of AEAD protection. The
integrity protections in authenticated encryption also depend on limiting the
number of attempts to forge packets. TLS achieves this by closing connections
after any record fails an authentication check. In comparison, DTLS ignores any
packet that cannot be authenticated, allowing multiple forgery attempts.<a href="#section-4.5.3-3" class="pilcrow">¶</a></p>
<p id="section-4.5.3-4">Implementations <span class="bcp14">MUST</span> count the number of received packets that fail
authentication with each key. If the number of packets that fail authentication
exceeds a limit that is specific to the AEAD in use, an implementation <span class="bcp14">SHOULD</span>
immediately close the connection. Implementations <span class="bcp14">SHOULD</span> initiate a key update
with update_requested before reaching this limit. Once a key update has been
initiated, the previous keys can be dropped when the limit is reached rather
than closing the connection. Applying a limit reduces the probability that an
attacker is able to successfully forge a packet; see <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> and
<span>[<a href="#ROBUST" class="xref">ROBUST</a>]</span>.<a href="#section-4.5.3-4" class="pilcrow">¶</a></p>
<p id="section-4.5.3-5">For AEAD_AES_128_GCM, AEAD_AES_256_GCM, and AEAD_CHACHA20_POLY1305, the limit
on the number of records that fail authentication is 2^36. Note that the
analysis in <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> supports a higher limit for  AEAD_AES_128_GCM and
AEAD_AES_256_GCM, but this specification recommends a lower limit. For
AEAD_AES_128_CCM, the limit on the number of records that fail authentication
is 2^23.5; see <a href="#ccm-bounds" class="xref">Appendix B</a>.<a href="#section-4.5.3-5" class="pilcrow">¶</a></p>
<p id="section-4.5.3-6">The AEAD_AES_128_CCM_8 AEAD, as used in TLS_AES_128_CCM_8_SHA256, does not have a
limit on the number of records that fail authentication that both limits the
probability of forgery by the same amount and does not expose implementations
to the risk of denial of service; see <a href="#ccm-short" class="xref">Appendix B.3</a>. Therefore,
TLS_AES_128_CCM_8_SHA256 <span class="bcp14">MUST NOT</span> be used in DTLS without additional safeguards
against forgery. Implementations <span class="bcp14">MUST</span> set usage limits for AEAD_AES_128_CCM_8
based on an understanding of any additional forgery protections that are used.<a href="#section-4.5.3-6" class="pilcrow">¶</a></p>
<p id="section-4.5.3-7">Any TLS cipher suite that is specified for use with DTLS <span class="bcp14">MUST</span> define limits on
the use of the associated AEAD function that preserves margins for both
confidentiality and integrity. That is, limits <span class="bcp14">MUST</span> be specified for the number
of packets that can be authenticated and for the number of packets that can fail
authentication before a key update is required. Providing a reference to any analysis upon which values are
based -- and any assumptions used in that analysis -- allows limits to be adapted
to varying usage conditions.<a href="#section-4.5.3-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="dtls">
<section id="section-5">
      <h2 id="name-the-dtls-handshake-protocol">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-the-dtls-handshake-protocol" class="section-name selfRef">The DTLS Handshake Protocol</a>
      </h2>
<p id="section-5-1">DTLS 1.3 reuses the TLS 1.3 handshake messages and flows, with
the following changes:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-2">
<li id="section-5-2.1">To handle message loss, reordering, and fragmentation, modifications to
the handshake header are necessary.<a href="#section-5-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.2">Retransmission timers are introduced to handle message loss.<a href="#section-5-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.3">A new ACK content type has been added for reliable message delivery of handshake messages.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-5-3">
In addition, DTLS reuses TLS 1.3's "cookie" extension to provide a return-routability
check as part of connection establishment. This is an important DoS
prevention mechanism for UDP-based protocols, unlike TCP-based protocols, for which
TCP establishes return-routability as part of the connection establishment.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">DTLS implementations do not use the TLS 1.3 "compatibility mode" described in
<span><a href="https://www.rfc-editor.org/rfc/rfc8446#appendix-D.4" class="relref">Appendix D.4</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>.  DTLS servers <span class="bcp14">MUST NOT</span> echo the
"legacy_session_id" value from the client and endpoints <span class="bcp14">MUST NOT</span> send ChangeCipherSpec
messages.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">With these exceptions, the DTLS message formats, flows, and logic are
the same as those of TLS 1.3.<a href="#section-5-5" class="pilcrow">¶</a></p>
<div id="dos">
<section id="section-5.1">
        <h3 id="name-denial-of-service-counterme">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-denial-of-service-counterme" class="section-name selfRef">Denial-of-Service Countermeasures</a>
        </h3>
<p id="section-5.1-1">Datagram security protocols are extremely susceptible to a variety of
DoS attacks.  Two attacks are of particular concern:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.1-2">
<li id="section-5.1-2.1">An attacker can consume excessive resources on the server by
transmitting a series of handshake initiation requests, causing
the server to allocate state and potentially to perform
expensive cryptographic operations.<a href="#section-5.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-5.1-2.2">An attacker can use the server as an amplifier by sending
connection initiation messages with a forged source address that belongs to a
victim.  The server then sends its response to the victim
machine, thus flooding it. Depending on the selected
parameters, this response message can be quite large, as
is the case for a Certificate message.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-5.1-3">In order to counter both of these attacks, DTLS borrows the stateless
cookie technique used by Photuris <span>[<a href="#RFC2522" class="xref">RFC2522</a>]</span> and IKE <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span>.  When
the client sends its ClientHello message to the server, the server
<span class="bcp14">MAY</span> respond with a HelloRetryRequest message. The HelloRetryRequest message,
as well as the "cookie" extension, is defined in TLS 1.3.
The HelloRetryRequest message contains a stateless cookie (see
<span>[<a href="#RFC8446" class="xref">TLS13</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.2" class="relref">Section 4.2.2</a></span>).
The client <span class="bcp14">MUST</span> send a new ClientHello
with the cookie added as an extension.  The server then verifies the cookie
and proceeds with the handshake only if it is valid.  This mechanism forces
the attacker/client to be able to receive the cookie, which makes DoS attacks
with spoofed IP addresses difficult.  This mechanism does not provide any defense
against DoS attacks mounted from valid IP addresses.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">The DTLS 1.3 specification changes how cookies are exchanged
compared to DTLS 1.2. DTLS 1.3 reuses the HelloRetryRequest message
and conveys the cookie to the client via an extension. The client
receiving the cookie uses the same extension to place
the cookie subsequently into a ClientHello message.
DTLS 1.2, on the other hand, used a separate message, namely the HelloVerifyRequest,
to pass a cookie to the client and did not utilize the extension mechanism.
For backwards compatibility reasons, the cookie field in the ClientHello
is present in DTLS 1.3 but is ignored by a DTLS 1.3-compliant server
implementation.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<p id="section-5.1-5">The exchange is shown in <a href="#dtls-cookie-exchange" class="xref">Figure 6</a>. Note that
the figure focuses on the cookie exchange; all other extensions
are omitted.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<span id="name-dtls-exchange-with-helloret"></span><div id="dtls-cookie-exchange">
<figure id="figure-6">
          <div class="alignLeft art-text artwork" id="section-5.1-6.1">
<pre>
      Client                                   Server
      ------                                   ------
      ClientHello           ------&gt;

                            &lt;----- HelloRetryRequest
                                    + cookie

      ClientHello           ------&gt;
       + cookie

      [Rest of handshake]
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-dtls-exchange-with-helloret" class="selfRef">DTLS Exchange with HelloRetryRequest Containing the "cookie" Extension</a>
          </figcaption></figure>
</div>
<p id="section-5.1-7">The "cookie" extension is defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.2" class="relref">Section 4.2.2</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>. When sending the
initial ClientHello, the client does not have a cookie yet. In this case,
the "cookie" extension is omitted and the legacy_cookie field in the ClientHello
message <span class="bcp14">MUST</span> be set to a zero-length vector (i.e., a zero-valued single byte length field).<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">When responding to a HelloRetryRequest, the client <span class="bcp14">MUST</span> create a new
ClientHello message following the description in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.1.2" class="relref">Section 4.1.2</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<p id="section-5.1-9">If the HelloRetryRequest message is used, the initial ClientHello and
the HelloRetryRequest are included in the calculation of the
transcript hash. The computation of the
message hash for the HelloRetryRequest is done according to the description
in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.1" class="relref">Section 4.4.1</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>.<a href="#section-5.1-9" class="pilcrow">¶</a></p>
<p id="section-5.1-10">The handshake transcript is not reset with the second ClientHello,
and a stateless server-cookie implementation requires the content or hash
of the initial ClientHello (and HelloRetryRequest)
to be stored in the cookie. The initial ClientHello is included in the
handshake transcript as a synthetic "message_hash" message, so only the hash
value is needed for the handshake to complete, though the complete
HelloRetryRequest contents are needed.<a href="#section-5.1-10" class="pilcrow">¶</a></p>
<p id="section-5.1-11">When the second ClientHello is received, the server can verify that
the cookie is valid and that the client can receive packets at the
given IP address. If the client's apparent IP address is embedded
in the cookie, this prevents an attacker from generating an acceptable
ClientHello apparently from another user.<a href="#section-5.1-11" class="pilcrow">¶</a></p>
<p id="section-5.1-12">One potential attack on this scheme is for the attacker to collect a
number of cookies from different addresses where it controls endpoints
and then reuse them to attack the server.
The server can defend against this attack by
changing the secret value frequently, thus invalidating those
cookies. If the server wishes to allow legitimate clients to
handshake through the transition (e.g., a client received a cookie with
Secret 1 and then sent the second ClientHello after the server has
changed to Secret 2), the server can have a limited window during
which it accepts both secrets.  <span>[<a href="#RFC7296" class="xref">RFC7296</a>]</span> suggests adding a key
identifier to cookies to detect this case. An alternative approach is
simply to try verifying with both secrets. It is <span class="bcp14">RECOMMENDED</span> that
servers implement a key rotation scheme that allows the server
to manage keys with overlapping lifetimes.<a href="#section-5.1-12" class="pilcrow">¶</a></p>
<p id="section-5.1-13">Alternatively, the server can store timestamps in the cookie and
reject cookies that were generated outside a certain
interval of time.<a href="#section-5.1-13" class="pilcrow">¶</a></p>
<p id="section-5.1-14">DTLS servers <span class="bcp14">SHOULD</span> perform a cookie exchange whenever a new
handshake is being performed.  If the server is being operated in an
environment where amplification is not a problem, e.g., where
ICE <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> has been used to establish bidirectional connectivity,
the server <span class="bcp14">MAY</span> be
configured not to perform a cookie exchange.  The default <span class="bcp14">SHOULD</span> be
that the exchange is performed, however.  In addition, the server <span class="bcp14">MAY</span>
choose not to do a cookie exchange when a session is resumed or, more
generically, when the DTLS handshake uses a PSK-based key exchange
and the IP address matches one associated with the PSK.
Servers which process 0-RTT requests and send 0.5-RTT responses without a cookie exchange risk being used in an amplification attack if the size of outgoing messages greatly exceeds the size of those that are received.
A server <span class="bcp14">SHOULD</span> limit the amount of data it sends toward a client address
to three times the amount of data sent by the client before
it verifies that the client is able to receive data at that address.
A client address is valid after a cookie exchange or handshake completion.
Clients <span class="bcp14">MUST</span> be prepared to do a cookie exchange with every
handshake. Note that cookies are only valid for the existing
handshake and cannot be stored for future handshakes.<a href="#section-5.1-14" class="pilcrow">¶</a></p>
<p id="section-5.1-15">If a server receives a ClientHello with an invalid cookie, it
<span class="bcp14">MUST</span> terminate the handshake with an "illegal_parameter" alert.
This allows the client to restart the connection from
scratch without a cookie.<a href="#section-5.1-15" class="pilcrow">¶</a></p>
<p id="section-5.1-16">As described in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.1.4" class="relref">Section 4.1.4</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>, clients <span class="bcp14">MUST</span>
abort the handshake with an "unexpected_message" alert in response
to any second HelloRetryRequest which was sent in the same connection
(i.e., where the ClientHello was itself in response to a HelloRetryRequest).<a href="#section-5.1-16" class="pilcrow">¶</a></p>
<p id="section-5.1-17">DTLS clients which do not want to receive a Connection ID <span class="bcp14">SHOULD</span>
still offer the "connection_id" extension <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span> unless
there is an application profile to the contrary. This permits
a server which wants to receive a CID to negotiate one.<a href="#section-5.1-17" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dtls-handshake-message-format">
<section id="section-5.2">
        <h3 id="name-dtls-handshake-message-form">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-dtls-handshake-message-form" class="section-name selfRef">DTLS Handshake Message Format</a>
        </h3>
<p id="section-5.2-1">DTLS uses the same Handshake messages as TLS 1.3. However,
prior to transmission they are converted to DTLSHandshake
messages, which contain extra data needed to support
message loss, reordering, and message fragmentation.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<div id="section-5.2-2">
<pre class="lang-tls-presentation sourcecode">
    enum {
        client_hello(1),
        server_hello(2),
        new_session_ticket(4),
        end_of_early_data(5),
        encrypted_extensions(8),
        request_connection_id(9),           /* New */
        new_connection_id(10),              /* New */
        certificate(11),
        certificate_request(13),
        certificate_verify(15),
        finished(20),
        key_update(24),
        message_hash(254),
        (255)
    } HandshakeType;
</pre><a href="#section-5.2-2" class="pilcrow">¶</a>
</div>
<div id="section-5.2-3">
<pre class="lang-tls-presentation sourcecode">
    struct {
        HandshakeType msg_type;    /* handshake type */
        uint24 length;             /* bytes in message */
        uint16 message_seq;        /* DTLS-required field */
        uint24 fragment_offset;    /* DTLS-required field */
        uint24 fragment_length;    /* DTLS-required field */
        select (msg_type) {
            case client_hello:          ClientHello;
            case server_hello:          ServerHello;
            case end_of_early_data:     EndOfEarlyData;
            case encrypted_extensions:  EncryptedExtensions;
            case certificate_request:   CertificateRequest;
            case certificate:           Certificate;
            case certificate_verify:    CertificateVerify;
            case finished:              Finished;
            case new_session_ticket:    NewSessionTicket;
            case key_update:            KeyUpdate;
            case request_connection_id: RequestConnectionId;
            case new_connection_id:     NewConnectionId;
        } body;
    } DTLSHandshake;
</pre><a href="#section-5.2-3" class="pilcrow">¶</a>
</div>
<p id="section-5.2-4">
  In DTLS 1.3, the message transcript is computed over the original
TLS 1.3-style Handshake messages without the message_seq,
fragment_offset, and fragment_length values. Note that this is
a change from DTLS 1.2 where those values were included
in the transcript.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2-5">The first message each side transmits in each association always has
message_seq = 0.  Whenever a new message is generated, the
message_seq value is incremented by one. When a message is
retransmitted, the old message_seq value is reused, i.e., not
incremented. From the perspective of the DTLS record layer, the retransmission is
a new record.  This record will have a new
DTLSPlaintext.sequence_number value.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.2-6">Note: In DTLS 1.2, the message_seq was reset to zero in case of a
rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2
shares similarities with a post-handshake message exchange in DTLS 1.3. However,
in DTLS 1.3 the message_seq is not reset, to allow distinguishing a
retransmission from a previously sent post-handshake message from a newly
sent post-handshake message.<a href="#section-5.2-6" class="pilcrow">¶</a></p>
<p id="section-5.2-7">DTLS implementations maintain (at least notionally) a
next_receive_seq counter.  This counter is initially set to zero.
When a handshake message is received, if its message_seq value matches
next_receive_seq, next_receive_seq is incremented and the message is
processed.  If the sequence number is less than next_receive_seq, the
message <span class="bcp14">MUST</span> be discarded.  If the sequence number is greater than
next_receive_seq, the implementation <span class="bcp14">SHOULD</span> queue the message but <span class="bcp14">MAY</span>
discard it.  (This is a simple space/bandwidth trade-off).<a href="#section-5.2-7" class="pilcrow">¶</a></p>
<p id="section-5.2-8">In addition to the handshake messages that are deprecated by the TLS 1.3
specification, DTLS 1.3 furthermore deprecates the HelloVerifyRequest message
originally defined in DTLS 1.0. DTLS 1.3-compliant implementations <span class="bcp14">MUST NOT</span>
use the HelloVerifyRequest to execute a return-routability check. A
dual-stack DTLS 1.2 / DTLS 1.3 client <span class="bcp14">MUST</span>, however, be prepared to
interact with a DTLS 1.2 server.<a href="#section-5.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="clienthello-message">
<section id="section-5.3">
        <h3 id="name-clienthello-message">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-clienthello-message" class="section-name selfRef">ClientHello Message</a>
        </h3>
<p id="section-5.3-1">The format of the ClientHello used by a DTLS 1.3 client differs from the
TLS 1.3 ClientHello format, as shown below.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<div id="section-5.3-2">
<pre class="lang-tls-presentation sourcecode">
    uint16 ProtocolVersion;
    opaque Random[32];

    uint8 CipherSuite[2];    /* Cryptographic suite selector */

    struct {
        ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
        Random random;
        opaque legacy_session_id&lt;0..32&gt;;
        opaque legacy_cookie&lt;0..2^8-1&gt;;                  // DTLS
        CipherSuite cipher_suites&lt;2..2^16-2&gt;;
        opaque legacy_compression_methods&lt;1..2^8-1&gt;;
        Extension extensions&lt;8..2^16-1&gt;;
    } ClientHello;
</pre><a href="#section-5.3-2" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-5.3-3">
          <dt id="section-5.3-3.1">legacy_version:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.2">
  In previous versions of DTLS, this field was used for version
negotiation and represented the highest version number supported by
the client. Experience has shown that many servers do not properly
implement version negotiation, leading to "version intolerance" in
which the server rejects an otherwise acceptable ClientHello with a
version number higher than it supports. In DTLS 1.3, the client
indicates its version preferences in the "supported_versions"
extension (see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.1" class="relref">Section 4.2.1</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>) and the
legacy_version field <span class="bcp14">MUST</span> be set to {254, 253}, which was the version
number for DTLS 1.2. The supported_versions entries for DTLS 1.0 and DTLS 1.2 are
0xfeff and 0xfefd (to match the wire versions). The value 0xfefc is used
to indicate DTLS 1.3.<a href="#section-5.3-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.3">random:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.4">
  Same as for TLS 1.3, except that the downgrade sentinels described
in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3" class="relref">Section 4.1.3</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span> when TLS 1.2
and TLS 1.1 and below are negotiated apply to DTLS 1.2 and DTLS 1.0, respectively.<a href="#section-5.3-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.5">legacy_session_id:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.6">
  Versions of TLS and DTLS before version 1.3 supported a "session resumption"
feature, which has been merged with pre-shared keys (PSK) in version 1.3.  A client
which has a cached session ID set by a pre-DTLS 1.3 server <span class="bcp14">SHOULD</span> set this
field to that value. Otherwise, it <span class="bcp14">MUST</span> be set as a zero-length vector
(i.e., a zero-valued single byte length field).<a href="#section-5.3-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.7">legacy_cookie:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.8">
  A DTLS 1.3-only client <span class="bcp14">MUST</span> set the legacy_cookie field to zero length.
If a DTLS 1.3 ClientHello is received with any other value in this field,
the server <span class="bcp14">MUST</span> abort the handshake with an "illegal_parameter" alert.<a href="#section-5.3-3.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.9">cipher_suites:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.10">
  Same as for TLS 1.3; only suites with DTLS-OK=Y may be used.<a href="#section-5.3-3.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.11">legacy_compression_methods:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.12">
  Same as for TLS 1.3.<a href="#section-5.3-3.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-5.3-3.13">extensions:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.14">
  Same as for TLS 1.3.<a href="#section-5.3-3.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="serverhello-message">
<section id="section-5.4">
        <h3 id="name-serverhello-message">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-serverhello-message" class="section-name selfRef">ServerHello Message</a>
        </h3>
<p id="section-5.4-1">The DTLS 1.3 ServerHello message is the same as the TLS 1.3
ServerHello message, except that the legacy_version field
is set to 0xfefd, indicating DTLS 1.2.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="handshake-message-fragmentation-and-reassembly">
<section id="section-5.5">
        <h3 id="name-handshake-message-fragmenta">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-handshake-message-fragmenta" class="section-name selfRef">Handshake Message Fragmentation and Reassembly</a>
        </h3>
<p id="section-5.5-1">As described in <a href="#transport-layer-mapping" class="xref">Section 4.3</a>, one or more handshake
messages may be carried in a single datagram. However, handshake messages are
potentially bigger than the size allowed by the underlying datagram transport.
DTLS provides a mechanism for fragmenting a handshake message over a
number of records, each of which can be transmitted in separate datagrams, thus
avoiding IP fragmentation.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">When transmitting the handshake message, the sender divides the
message into a series of N contiguous data ranges. The ranges <span class="bcp14">MUST NOT</span>
overlap.  The sender then creates N DTLSHandshake messages, all with the
same message_seq value as the original DTLSHandshake message.  Each new
message is labeled with the fragment_offset (the number of bytes
contained in previous fragments) and the fragment_length (the length
of this fragment).  The length field in all messages is the same as
the length field of the original message.  An unfragmented message is
a degenerate case with fragment_offset=0 and fragment_length=length.
Each handshake message fragment that is placed into a record
<span class="bcp14">MUST</span> be delivered in a single UDP datagram.<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<p id="section-5.5-3">When a DTLS implementation receives a handshake message fragment corresponding
to the next expected handshake message sequence number, it
<span class="bcp14">MUST</span> process it, either by buffering it until it has the entire
handshake message or by processing any in-order portions of the message.
The transcript consists of complete TLS Handshake messages (reassembled
as necessary). Note that this requires removing the message_seq,
fragment_offset, and fragment_length fields to create the Handshake
structure.<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<p id="section-5.5-4">
DTLS
implementations <span class="bcp14">MUST</span> be able to handle overlapping fragment ranges.
This allows senders to retransmit handshake messages with smaller
fragment sizes if the PMTU estimate changes. Senders <span class="bcp14">MUST NOT</span> change
handshake message bytes upon retransmission. Receivers <span class="bcp14">MAY</span> check
that retransmitted bytes are identical and <span class="bcp14">SHOULD</span> abort the handshake
with an "illegal_parameter" alert if the value of a byte changes.<a href="#section-5.5-4" class="pilcrow">¶</a></p>
<p id="section-5.5-5">Note that as with TLS, multiple handshake messages may be placed in
the same DTLS record, provided that there is room and that they are
part of the same flight.  Thus, there are two acceptable ways to pack
two DTLS handshake messages into the same datagram: in the same record or in
separate records.<a href="#section-5.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="end-of-early-data">
<section id="section-5.6">
        <h3 id="name-endofearlydata-message">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-endofearlydata-message" class="section-name selfRef">EndOfEarlyData Message</a>
        </h3>
<p id="section-5.6-1">The DTLS 1.3 handshake has one important difference from the
TLS 1.3 handshake: the EndOfEarlyData message is omitted both
from the wire and the handshake transcript. Because DTLS
records have epochs, EndOfEarlyData is not necessary to determine
when the early data is complete, and because DTLS is lossy,
attackers can trivially mount the deletion attacks that EndOfEarlyData
prevents in TLS. Servers <span class="bcp14">SHOULD NOT</span> accept records from epoch 1 indefinitely once they are able to process records from epoch 3. Though reordering of IP packets can result in records from epoch 1 arriving after records from epoch 3, this is not likely to persist for very long relative to the round trip time. Servers could discard epoch 1  keys after the first epoch 3 data arrives, or retain keys for processing epoch 1 data for a short period.
(See <a href="#dtls-epoch" class="xref">Section 6.1</a> for the definitions of each epoch.)<a href="#section-5.6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dtls-handshake-flights">
<section id="section-5.7">
        <h3 id="name-dtls-handshake-flights">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-dtls-handshake-flights" class="section-name selfRef">DTLS Handshake Flights</a>
        </h3>
<p id="section-5.7-1">DTLS handshake messages are grouped into a series of message flights. A flight starts with the
handshake message transmission of one peer and ends with the expected response from the
other peer. <a href="#tab-flights" class="xref">Table 1</a> contains a complete list of message combinations that constitute flights.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<span id="name-flight-handshake-message-co"></span><div id="tab-flights">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-flight-handshake-message-co" class="selfRef">Flight Handshake Message Combinations</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Note</th>
              <th class="text-left" rowspan="1" colspan="1">Client</th>
              <th class="text-left" rowspan="1" colspan="1">Server</th>
              <th class="text-left" rowspan="1" colspan="1">Handshake Messages</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">ClientHello</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">HelloRetryRequest</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">ServerHello, EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">Certificate, CertificateVerify, Finished</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1"> </td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">NewSessionTicket</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-5.7-3">Remarks:<a href="#section-5.7-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.7-4.1">
            <a href="#tab-flights" class="xref">Table 1</a> does not highlight any of the optional messages.<a href="#section-5.7-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.7-4.2">Regarding note (1): When a handshake flight is sent without any expected response, as is the case with
 the client's final flight or with the NewSessionTicket message, the flight must be
 acknowledged with an ACK message.<a href="#section-5.7-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.7-5">Below are several example message exchanges illustrating the flight concept.
The notational conventions from <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span> are used.<a href="#section-5.7-5" class="pilcrow">¶</a></p>
<span id="name-message-flights-for-a-full-"></span><div id="dtls-full">
<figure id="figure-7">
          <div class="alignLeft art-text artwork" id="section-5.7-6.1">
<pre>
Client                                            Server

                                                           +--------+
 ClientHello                                               | Flight |
                       --------&gt;                           +--------+

                                                           +--------+
                       &lt;--------        HelloRetryRequest  | Flight |
                                         + cookie          +--------+


                                                           +--------+
ClientHello                                                | Flight |
 + cookie              --------&gt;                           +--------+



                                              ServerHello
                                    {EncryptedExtensions}  +--------+
                                    {CertificateRequest*}  | Flight |
                                           {Certificate*}  +--------+
                                     {CertificateVerify*}
                                               {Finished}
                       &lt;--------      [Application Data*]



 {Certificate*}                                            +--------+
 {CertificateVerify*}                                      | Flight |
 {Finished}            --------&gt;                           +--------+
 [Application Data]
                                                           +--------+
                       &lt;--------                    [ACK]  | Flight |
                                      [Application Data*]  +--------+

 [Application Data]    &lt;-------&gt;      [Application Data]
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-message-flights-for-a-full-" class="selfRef">Message Flights for a Full DTLS Handshake (with Cookie Exchange)</a>
          </figcaption></figure>
</div>
<span id="name-message-flights-for-resumpt"></span><div id="dtls-psk">
<figure id="figure-8">
          <div class="alignLeft art-text artwork" id="section-5.7-7.1">
<pre>
 ClientHello                                              +--------+
  + pre_shared_key                                        | Flight |
  + psk_key_exchange_modes                                +--------+
  + key_share*         --------&gt;


                                             ServerHello
                                        + pre_shared_key  +--------+
                                            + key_share*  | Flight |
                                   {EncryptedExtensions}  +--------+
                       &lt;--------              {Finished}
                                     [Application Data*]
                                                          +--------+
 {Finished}            --------&gt;                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       &lt;--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    &lt;-------&gt;      [Application Data]
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-message-flights-for-resumpt" class="selfRef">Message Flights for Resumption and PSK Handshake (without Cookie Exchange)</a>
          </figcaption></figure>
</div>
<span id="name-message-flights-for-the-zer"></span><div id="dtls-zero-rtt">
<figure id="figure-9">
          <div class="alignLeft art-text artwork" id="section-5.7-8.1">
<pre>
Client                                            Server

 ClientHello
  + early_data
  + psk_key_exchange_modes                                +--------+
  + key_share*                                            | Flight |
  + pre_shared_key                                        +--------+
 (Application Data*)     --------&gt;

                                             ServerHello
                                        + pre_shared_key
                                            + key_share*  +--------+
                                   {EncryptedExtensions}  | Flight |
                                              {Finished}  +--------+
                       &lt;--------     [Application Data*]


                                                          +--------+
 {Finished}            --------&gt;                          | Flight |
 [Application Data*]                                      +--------+

                                                          +--------+
                       &lt;--------                   [ACK]  | Flight |
                                     [Application Data*]  +--------+

 [Application Data]    &lt;-------&gt;      [Application Data]
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-message-flights-for-the-zer" class="selfRef">Message Flights for the Zero-RTT Handshake</a>
          </figcaption></figure>
</div>
<span id="name-message-flights-for-the-new"></span><div id="dtls-post-handshake-ticket">
<figure id="figure-10">
          <div class="alignLeft art-text artwork" id="section-5.7-9.1">
<pre>
Client                                            Server

                                                          +--------+
                       &lt;--------       [NewSessionTicket] | Flight |
                                                          +--------+

                                                          +--------+
[ACK]                  --------&gt;                          | Flight |
                                                          +--------+
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-message-flights-for-the-new" class="selfRef">Message Flights for the NewSessionTicket Message</a>
          </figcaption></figure>
</div>
<p id="section-5.7-10">KeyUpdate, NewConnectionId, and RequestConnectionId follow a similar pattern
to NewSessionTicket: a single message sent by one side
followed by an ACK by the other.<a href="#section-5.7-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="timeout-retransmissions">
<section id="section-5.8">
        <h3 id="name-timeout-and-retransmission">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-timeout-and-retransmission" class="section-name selfRef">Timeout and Retransmission</a>
        </h3>
<div id="state-machine">
<section id="section-5.8.1">
          <h4 id="name-state-machine">
<a href="#section-5.8.1" class="section-number selfRef">5.8.1. </a><a href="#name-state-machine" class="section-name selfRef">State Machine</a>
          </h4>
<p id="section-5.8.1-1">DTLS uses a simple timeout and retransmission scheme with the
state machine shown in <a href="#dtls-timeout-state-machine" class="xref">Figure 11</a>.<a href="#section-5.8.1-1" class="pilcrow">¶</a></p>
<span id="name-dtls-timeout-and-retransmis"></span><div id="dtls-timeout-state-machine">
<figure id="figure-11">
            <div class="alignLeft art-text artwork" id="section-5.8.1-2.1">
<pre>
                             +-----------+
                             | PREPARING |
                +----------&gt; |           |
                |            |           |
                |            +-----------+
                |                  |
                |                  | Buffer next flight
                |                  |
                |                 \|/
                |            +-----------+
                |            |           |
                |            |  SENDING  |&lt;------------------+
                |            |           |                   |
                |            +-----------+                   |
        Receive |                  |                         |
           next |                  | Send flight or partial  |
         flight |                  | flight                  |
                |                  |                         |
                |                  | Set retransmit timer    |
                |                 \|/                        |
                |            +-----------+                   |
                |            |           |                   |
                +------------|  WAITING  |-------------------+
                |     +-----&gt;|           |   Timer expires   |
                |     |      +-----------+                   |
                |     |          |  |   |                    |
                |     |          |  |   |                    |
                |     +----------+  |   +--------------------+
                |    Receive record |   Read retransmit or ACK
        Receive |  (Maybe Send ACK) |
           last |                   |
         flight |                   | Receive ACK
                |                   | for last flight
               \|/                  |
                                    |
            +-----------+           |
            |           | &lt;---------+
            | FINISHED  |
            |           |
            +-----------+
                |  /|\
                |   |
                |   |
                +---+

          Server read retransmit
              Retransmit ACK
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-dtls-timeout-and-retransmis" class="selfRef">DTLS Timeout and Retransmission State Machine</a>
            </figcaption></figure>
</div>
<p id="section-5.8.1-3">The state machine has four basic states: PREPARING, SENDING, WAITING,
and FINISHED.<a href="#section-5.8.1-3" class="pilcrow">¶</a></p>
<p id="section-5.8.1-4">In the PREPARING state, the implementation does whatever computations
are necessary to prepare the next flight of messages.  It then
buffers them up for transmission (emptying the transmission
buffer first) and enters the SENDING state.<a href="#section-5.8.1-4" class="pilcrow">¶</a></p>
<p id="section-5.8.1-5">In the SENDING state, the implementation transmits the buffered
flight of messages. If the implementation has received one or more
ACKs (see <a href="#ack-msg" class="xref">Section 7</a>) from the peer, then it <span class="bcp14">SHOULD</span> omit any messages or
message fragments which have already been acknowledged. Once the messages
have been sent, the implementation then sets a retransmit timer
and enters the WAITING state.<a href="#section-5.8.1-5" class="pilcrow">¶</a></p>
<p id="section-5.8.1-6">There are four ways to exit the WAITING state:<a href="#section-5.8.1-6" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.8.1-7">
<li id="section-5.8.1-7.1">The retransmit timer expires: the implementation transitions to
the SENDING state, where it retransmits the flight, adjusts and re-arms the
retransmit timer (see <a href="#timer-values" class="xref">Section 5.8.2</a>), and returns to the WAITING state.<a href="#section-5.8.1-7.1" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.1-7.2">The implementation reads an ACK from the peer: upon receiving
an ACK for a partial flight (as mentioned in <a href="#sending-acks" class="xref">Section 7.1</a>),
the implementation transitions
to the SENDING state, where it retransmits the unacknowledged portion
of the flight, adjusts and re-arms the retransmit timer, and returns to the
WAITING state.
 Upon receiving an ACK for a complete flight,
the implementation cancels all retransmissions and either
remains in WAITING, or, if the ACK was for the final flight,
transitions to FINISHED.<a href="#section-5.8.1-7.2" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.1-7.3">The implementation reads a retransmitted flight from the peer
when none of the messages that it sent in response to that flight
   have been acknowledged: the
implementation transitions to the SENDING state, where it
retransmits the flight, adjusts and re-arms the retransmit timer, and returns
to the WAITING state.  The rationale here is that the receipt of a
duplicate message is the likely result of timer expiry on the peer
and therefore suggests that part of one's previous flight was
lost.<a href="#section-5.8.1-7.3" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.1-7.4">The implementation receives some or all of the next flight of messages: if
this is the final flight of messages, the implementation
transitions to FINISHED.  If the implementation needs to send a new
flight, it transitions to the PREPARING state. Partial reads
(whether partial messages or only some of the messages in the
flight) may also trigger the implementation to send an ACK, as
described in <a href="#sending-acks" class="xref">Section 7.1</a>.<a href="#section-5.8.1-7.4" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-5.8.1-8">Because DTLS clients send the first message (ClientHello), they start
in the PREPARING state.  DTLS servers start in the WAITING state, but
with empty buffers and no retransmit timer.<a href="#section-5.8.1-8" class="pilcrow">¶</a></p>
<p id="section-5.8.1-9">In addition, for at least twice the default MSL defined for <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span>,
when in the FINISHED state, the server <span class="bcp14">MUST</span> respond to retransmission
of the client's final flight with a retransmit of its ACK.<a href="#section-5.8.1-9" class="pilcrow">¶</a></p>
<p id="section-5.8.1-10">Note that because of packet loss, it is possible for one side to be
sending application data even though the other side has not received
the first side's Finished message.  Implementations <span class="bcp14">MUST</span> either
discard or buffer all application data records for epoch 3 and
above until they have received the Finished message from the
peer. Implementations <span class="bcp14">MAY</span> treat receipt of application data with a new
epoch prior to receipt of the corresponding Finished message as
evidence of reordering or packet loss and retransmit their final
flight immediately, shortcutting the retransmission timer.<a href="#section-5.8.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="timer-values">
<section id="section-5.8.2">
          <h4 id="name-timer-values">
<a href="#section-5.8.2" class="section-number selfRef">5.8.2. </a><a href="#name-timer-values" class="section-name selfRef">Timer Values</a>
          </h4>
<p id="section-5.8.2-1">The configuration of timer settings varies with implementations, and certain
deployment environments require timer value adjustments. Mishandling
of the timer can lead to serious congestion problems -- for example, if
many instances of a DTLS time out early and retransmit too quickly on
a congested link.<a href="#section-5.8.2-1" class="pilcrow">¶</a></p>
<p id="section-5.8.2-2">Unless implementations have deployment-specific and/or external information about the round trip time,
implementations <span class="bcp14">SHOULD</span> use an initial timer value of 1000 ms and double
the value at each retransmission, up to no less than 60 seconds (the maximum as specified in
RFC 6298 <span>[<a href="#RFC6298" class="xref">RFC6298</a>]</span>). Application-specific profiles <span class="bcp14">MAY</span>
recommend shorter or longer timer values. For instance:<a href="#section-5.8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8.2-3.1">Profiles for specific deployment environments, such as in low-power,
multi-hop mesh scenarios as used in some Internet of Things (IoT) networks,
<span class="bcp14">MAY</span> specify longer timeouts. See <span>[<a href="#I-D.ietf-uta-tls13-iot-profile" class="xref">IOT-PROFILE</a>]</span> for
more information about one such DTLS 1.3 IoT profile.<a href="#section-5.8.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.8.2-3.2">Real-time protocols <span class="bcp14">MAY</span> specify shorter timeouts. It is <span class="bcp14">RECOMMENDED</span>
that for DTLS-SRTP <span>[<a href="#RFC5764" class="xref">RFC5764</a>]</span>, a default timeout of
400 ms be used; because customer experience degrades with one-way latencies
of greater than 200 ms, real-time deployments are less likely
to have long latencies.<a href="#section-5.8.2-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.8.2-4">In settings where there is external information (for instance, from an ICE <span>[<a href="#RFC8445" class="xref">RFC8445</a>]</span> handshake, or from previous connections to the same server)
about the RTT, implementations <span class="bcp14">SHOULD</span> use 1.5 times that RTT estimate
as the retransmit timer.<a href="#section-5.8.2-4" class="pilcrow">¶</a></p>
<p id="section-5.8.2-5">Implementations <span class="bcp14">SHOULD</span> retain the current timer value until a
message is transmitted and acknowledged without having to
be retransmitted, at which time the value <span class="bcp14">SHOULD</span> be adjusted
to 1.5 times the measured round trip time for that
message. After a long period of idleness, no less
than 10 times the current timer value, implementations <span class="bcp14">MAY</span> reset the
timer to the initial value.<a href="#section-5.8.2-5" class="pilcrow">¶</a></p>
<p id="section-5.8.2-6">Note that because retransmission is for the handshake and not dataflow, the effect on
congestion of shorter timeouts is smaller than in generic protocols
such as TCP or QUIC. Experience with DTLS 1.2, which uses a
simpler "retransmit everything on timeout" approach, has not shown
serious congestion problems in practice.<a href="#section-5.8.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="large-flight-sizes">
<section id="section-5.8.3">
          <h4 id="name-large-flight-sizes">
<a href="#section-5.8.3" class="section-number selfRef">5.8.3. </a><a href="#name-large-flight-sizes" class="section-name selfRef">Large Flight Sizes</a>
          </h4>
<p id="section-5.8.3-1">DTLS does not have any built-in congestion control or rate control;
in general, this is not an issue because messages tend to be small.
However, in principle, some messages -- especially Certificate -- can
be quite large. If all the messages in a large flight are sent
at once, this can result in network congestion. A better strategy
is to send out only part of the flight, sending more when
messages are acknowledged. Several extensions have been standardized
to reduce the size of the Certificate message -- for example,
the "cached_info" extension <span>[<a href="#RFC7924" class="xref">RFC7924</a>]</span>; certificate
compression <span>[<a href="#RFC8879" class="xref">RFC8879</a>]</span>; and <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span>, which defines the "client_certificate_url"
extension allowing DTLS clients to send a sequence of Uniform
Resource Locators (URLs) instead of the client certificate.<a href="#section-5.8.3-1" class="pilcrow">¶</a></p>
<p id="section-5.8.3-2">DTLS stacks <span class="bcp14">SHOULD NOT</span> send more than 10 records in a single transmission.<a href="#section-5.8.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="state-machine-duplication">
<section id="section-5.8.4">
          <h4 id="name-state-machine-duplication-f">
<a href="#section-5.8.4" class="section-number selfRef">5.8.4. </a><a href="#name-state-machine-duplication-f" class="section-name selfRef">State Machine Duplication for Post-Handshake Messages</a>
          </h4>
<p id="section-5.8.4-1">DTLS 1.3 makes use of the following categories of post-handshake messages:<a href="#section-5.8.4-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.8.4-2">
<li id="section-5.8.4-2.1">NewSessionTicket<a href="#section-5.8.4-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.4-2.2">KeyUpdate<a href="#section-5.8.4-2.2" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.4-2.3">NewConnectionId<a href="#section-5.8.4-2.3" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.4-2.4">RequestConnectionId<a href="#section-5.8.4-2.4" class="pilcrow">¶</a>
</li>
            <li id="section-5.8.4-2.5">Post-handshake client authentication<a href="#section-5.8.4-2.5" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-5.8.4-3">Messages of each category can be sent independently, and reliability is established
via independent state machines, each of which behaves as described in <a href="#state-machine" class="xref">Section 5.8.1</a>.
For example, if a server sends a NewSessionTicket and a CertificateRequest message,
two independent state machines will be created.<a href="#section-5.8.4-3" class="pilcrow">¶</a></p>
<p id="section-5.8.4-4">Sending multiple instances of messages of
a given category without having completed earlier transmissions is allowed for some
categories, but not for others.
 Specifically, a server <span class="bcp14">MAY</span> send multiple NewSessionTicket
messages at once without awaiting ACKs for earlier NewSessionTicket messages first. Likewise, a
server <span class="bcp14">MAY</span> send multiple CertificateRequest messages at once without having completed
earlier client authentication requests before. In contrast, implementations <span class="bcp14">MUST NOT</span>
send KeyUpdate, NewConnectionId, or RequestConnectionId messages if an earlier message
of the same type has not yet been acknowledged.<a href="#section-5.8.4-4" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.8.4-5">Note: Except for post-handshake client authentication, which involves handshake messages
in both directions, post-handshake messages are single-flight, and their respective state
machines on the sender side reduce to waiting for an ACK and retransmitting the original
message. In particular, note that a RequestConnectionId message does not force the receiver
to send a NewConnectionId message in reply, and both messages are therefore treated
independently.<a href="#section-5.8.4-5" class="pilcrow">¶</a></p>
<p id="section-5.8.4-6">Creating and correctly updating multiple state machines requires feedback from the handshake
logic to the state machine layer, indicating which message belongs to which state machine.
For example, if a server sends multiple CertificateRequest messages and receives a Certificate
message in response, the corresponding state machine can only be determined after inspecting the
certificate_request_context field. Similarly, a server sending a single CertificateRequest
and receiving a NewConnectionId message in response can only decide that the NewConnectionId
message should be treated through an independent state machine after inspecting the handshake
message type.<a href="#section-5.8.4-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="cryptographic-label-prefix">
<section id="section-5.9">
        <h3 id="name-cryptographic-label-prefix">
<a href="#section-5.9" class="section-number selfRef">5.9. </a><a href="#name-cryptographic-label-prefix" class="section-name selfRef">Cryptographic Label Prefix</a>
        </h3>
<p id="section-5.9-1"><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">TLS13</a>]</span> specifies that HKDF-Expand-Label uses
a label prefix of "tls13 ". For DTLS 1.3, that label <span class="bcp14">SHALL</span> be
"dtls13".  This ensures key separation between DTLS 1.3 and
TLS 1.3. Note that there is no trailing space; this is necessary
in order to keep the overall label size inside of one hash
iteration because "DTLS" is one letter longer than "TLS".<a href="#section-5.9-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="alert-messages">
<section id="section-5.10">
        <h3 id="name-alert-messages">
<a href="#section-5.10" class="section-number selfRef">5.10. </a><a href="#name-alert-messages" class="section-name selfRef">Alert Messages</a>
        </h3>
<p id="section-5.10-1">Note that alert messages are not retransmitted at all, even when they
occur in the context of a handshake.  However, a DTLS implementation
which would ordinarily issue an alert <span class="bcp14">SHOULD</span> generate a new alert
message if the offending record is received again (e.g., as a
retransmitted handshake message).  Implementations <span class="bcp14">SHOULD</span> detect when
a peer is persistently sending bad messages and terminate the local
connection state after such misbehavior is detected. Note that alerts
are not reliably transmitted; implementations <span class="bcp14">SHOULD NOT</span> depend on
receiving alerts in order to signal errors or connection closure.<a href="#section-5.10-1" class="pilcrow">¶</a></p>
<p id="section-5.10-2">
Any data received with an epoch/sequence number pair after
that of a valid received closure alert <span class="bcp14">MUST</span> be ignored. Note:
this is a change from TLS 1.3 which depends on the order of
receipt rather than the epoch and sequence number.<a href="#section-5.10-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="establishing-new-associations-with-existing-parameters">
<section id="section-5.11">
        <h3 id="name-establishing-new-associatio">
<a href="#section-5.11" class="section-number selfRef">5.11. </a><a href="#name-establishing-new-associatio" class="section-name selfRef">Establishing New Associations with Existing Parameters</a>
        </h3>
<p id="section-5.11-1">If a DTLS client-server pair is configured in such a way that
repeated connections happen on the same host/port quartet, then it is
possible that a client will silently abandon one connection and then
initiate another with the same parameters (e.g., after a reboot).
This will appear to the server as a new handshake with epoch=0.  In
cases where a server believes it has an existing association on a
given host/port quartet and it receives an epoch=0 ClientHello, it
<span class="bcp14">SHOULD</span> proceed with a new handshake but <span class="bcp14">MUST NOT</span> destroy the existing
association until the client has demonstrated reachability either by
completing a cookie exchange or by completing a complete handshake
including delivering a verifiable Finished message.  After a correct
Finished message is received, the server <span class="bcp14">MUST</span> abandon the previous
association to avoid confusion between two valid associations with
overlapping epochs.  The reachability requirement prevents
off-path/blind attackers from destroying associations merely by
sending forged ClientHellos.<a href="#section-5.11-1" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5.11-2">Note: It is not always possible to distinguish which association
a given record is from. For instance, if the client performs
a handshake, abandons the connection, and then immediately starts
a new handshake, it may not be possible to tell which connection
a given protected record is for. In these cases, trial decryption
may be necessary, though implementations could use CIDs to avoid
the 5-tuple-based ambiguity.<a href="#section-5.11-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="example-of-handshake-with-timeout-and-retransmission">
<section id="section-6">
      <h2 id="name-example-of-handshake-with-t">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-example-of-handshake-with-t" class="section-name selfRef">Example of Handshake with Timeout and Retransmission</a>
      </h2>
<p id="section-6-1">The following is an example of a handshake with lost packets and
retransmissions. Note that the client sends an empty ACK message
because it can only acknowledge Record 2 sent by the server once it has
processed messages in Record 0 needed to establish epoch 2 keys, which
are needed to encrypt or decrypt messages found in Record 2.  <a href="#ack-msg" class="xref">Section 7</a>
provides the necessary background details for this interaction.
Note: For simplicity, we are not resetting record numbers in this
diagram, so "Record 1" is really "Epoch 2, Record 0", etc.<a href="#section-6-1" class="pilcrow">¶</a></p>
<span id="name-example-dtls-exchange-illus"></span><div id="dtls-msg-loss">
<figure id="figure-12">
        <div class="alignLeft art-text artwork" id="section-6-2.1">
<pre>
Client                                                Server
------                                                ------

 Record 0                  --------&gt;
 ClientHello
 (message_seq=0)

                             X&lt;-----                 Record 0
                             (lost)               ServerHello
                                              (message_seq=0)
                                                     Record 1
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)


                           &lt;--------                 Record 2
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)

 Record 1                  --------&gt;
 ACK []


                           &lt;--------                 Record 3
                                                  ServerHello
                                              (message_seq=0)
                                          EncryptedExtensions
                                              (message_seq=1)
                                                  Certificate
                                              (message_seq=2)

                           &lt;--------                 Record 4
                                            CertificateVerify
                                              (message_seq=3)
                                                     Finished
                                              (message_seq=4)


 Record 2                  --------&gt;
 Certificate
 (message_seq=1)
 CertificateVerify
 (message_seq=2)
 Finished
 (message_seq=3)

                           &lt;--------               Record 5
                                                    ACK [2]
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-example-dtls-exchange-illus" class="selfRef">Example DTLS Exchange Illustrating Message Loss</a>
        </figcaption></figure>
</div>
<div id="dtls-epoch">
<section id="section-6.1">
        <h3 id="name-epoch-values-and-rekeying">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-epoch-values-and-rekeying" class="section-name selfRef">Epoch Values and Rekeying</a>
        </h3>
<p id="section-6.1-1">A recipient of a DTLS message needs to select the correct keying material
in order to process an incoming message. With the possibility of message
 loss and reordering, an identifier is needed to determine which cipher state
has been used to protect the record payload. The epoch value fulfills this
role in DTLS. In addition to the TLS 1.3-defined key derivation steps (see
<span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-7" class="relref">Section 7</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>), a sender may want to rekey at any time during
the lifetime of the connection. It therefore needs to indicate that it is
updating its sending cryptographic keys.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">This version of DTLS assigns dedicated epoch values to messages in the
protocol exchange to allow identification of the correct cipher state:<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.1-3.1">Epoch value (0) is used with unencrypted messages. There are
three unencrypted messages in DTLS, namely ClientHello, ServerHello,
and HelloRetryRequest.<a href="#section-6.1-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-3.2">Epoch value (1) is used for messages protected using keys derived
from client_early_traffic_secret. Note that this epoch is skipped if
the client does not offer early data.<a href="#section-6.1-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-3.3">Epoch value (2) is used for messages protected using keys derived
from [sender]_handshake_traffic_secret. Messages transmitted during
the initial handshake, such as EncryptedExtensions,
CertificateRequest, Certificate, CertificateVerify, and Finished,
belong to this category. Note, however, that post-handshake messages are
protected under the appropriate application traffic key and are not included in this category.<a href="#section-6.1-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-3.4">Epoch value (3) is used for payloads protected using keys derived
from the initial [sender]_application_traffic_secret_0. This may include
handshake messages, such as post-handshake messages (e.g., a
NewSessionTicket message).<a href="#section-6.1-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-3.5">Epoch values (4 to 2^64-1) are used for payloads protected using keys from
the [sender]_application_traffic_secret_N (N&gt;0).<a href="#section-6.1-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.1-4">Using these reserved epoch values, a receiver knows what cipher state
has been used to encrypt and integrity protect a
message. Implementations that receive a record with an epoch value
for which no corresponding cipher state can be determined <span class="bcp14">SHOULD</span>
handle it as a record which fails deprotection.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">Note that epoch values do not wrap. If a DTLS implementation would
need to wrap the epoch value, it <span class="bcp14">MUST</span> terminate the connection.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<p id="section-6.1-6">The traffic key calculation is described in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.3" class="relref">Section 7.3</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>.<a href="#section-6.1-6" class="pilcrow">¶</a></p>
<p id="section-6.1-7"><a href="#dtls-msg-epoch" class="xref">Figure 13</a> illustrates the epoch values in an example DTLS handshake.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<span id="name-example-dtls-exchange-with-"></span><div id="dtls-msg-epoch">
<figure id="figure-13">
          <div class="alignLeft art-text artwork" id="section-6.1-8.1">
<pre>
Client                                             Server
------                                             ------

 Record 0
 ClientHello
 (epoch=0)
                            --------&gt;
                                                     Record 0
                            &lt;--------       HelloRetryRequest
                                                    (epoch=0)
 Record 1
 ClientHello                --------&gt;
 (epoch=0)
                                                     Record 1
                            &lt;--------             ServerHello
                                                    (epoch=0)
                                        {EncryptedExtensions}
                                                    (epoch=2)
                                                {Certificate}
                                                    (epoch=2)
                                          {CertificateVerify}
                                                    (epoch=2)
                                                   {Finished}
                                                    (epoch=2)
 Record 2
 {Certificate}              --------&gt;
 (epoch=2)
 {CertificateVerify}
 (epoch=2)
 {Finished}
 (epoch=2)
                                                     Record 2
                            &lt;--------                   [ACK]
                                                    (epoch=3)
 Record 3
 [Application Data]         --------&gt;
 (epoch=3)
                                                     Record 3
                            &lt;--------      [Application Data]
                                                    (epoch=3)

                         Some time later ...
                 (Post-Handshake Message Exchange)
                                                     Record 4
                            &lt;--------      [NewSessionTicket]
                                                    (epoch=3)
 Record 4
 [ACK]                      --------&gt;
 (epoch=3)

                         Some time later ...
                           (Rekeying)
                                                     Record 5
                            &lt;--------      [Application Data]
                                                    (epoch=4)
 Record 5
 [Application Data]         --------&gt;
 (epoch=4)
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-example-dtls-exchange-with-" class="selfRef">Example DTLS Exchange with Epoch Information</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="ack-msg">
<section id="section-7">
      <h2 id="name-ack-message">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-ack-message" class="section-name selfRef">ACK Message</a>
      </h2>
<p id="section-7-1">The ACK message is used by an endpoint to indicate which handshake records
it has received and processed from the other side. ACK is not
a handshake message but is rather a separate content type,
with code point 26. This avoids having ACK being added
to the handshake transcript. Note that ACKs can still be
sent in the same UDP datagram as handshake records.<a href="#section-7-1" class="pilcrow">¶</a></p>
<div id="section-7-2">
<pre class="lang-tls-presentation sourcecode">
    struct {
        RecordNumber record_numbers&lt;0..2^16-1&gt;;
    } ACK;
</pre><a href="#section-7-2" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-7-3">
        <dt id="section-7-3.1">record_numbers:</dt>
        <dd style="margin-left: 1.5em" id="section-7-3.2">
  A list of the records containing handshake messages in the current
flight which the endpoint has received and either processed or buffered,
in numerically increasing
order.<a href="#section-7-3.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-7-4">Implementations <span class="bcp14">MUST NOT</span> acknowledge records containing
handshake messages or fragments which have not been
processed or buffered. Otherwise, deadlock can ensue.
As an example, implementations <span class="bcp14">MUST NOT</span> send ACKs for
handshake messages which they discard because they are
not the next expected message.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">During the handshake, ACKs only cover the current outstanding flight (this is
possible because DTLS is generally a lock-step protocol). In particular,
receiving a message from a handshake flight implicitly acknowledges all
messages from the previous flight(s).  Accordingly, an ACK
from the server would not cover both the ClientHello and the client's Certificate message, because the ClientHello and client Certificate are in different
flights. Implementations can accomplish this by clearing their ACK
list upon receiving the start of the next flight.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">For post-handshake messages, ACKs <span class="bcp14">SHOULD</span> be sent once for each received
and processed handshake record (potentially subject to some delay) and <span class="bcp14">MAY</span>
cover more than one flight. This includes records containing messages which are
discarded because a previous copy has been received.<a href="#section-7-6" class="pilcrow">¶</a></p>
<p id="section-7-7">During the handshake, ACK records <span class="bcp14">MUST</span> be sent with an epoch which is
equal to or higher than the record which is being acknowledged.
Note that some care is required when processing flights spanning
multiple epochs. For instance, if the client receives only the ServerHello
and Certificate and wishes to ACK them in a single record,
it must do so in epoch 2, as it is required to use an epoch
greater than or equal to 2 and cannot yet send with any greater
epoch. Implementations <span class="bcp14">SHOULD</span> simply use the highest
current sending epoch, which will generally be the highest available.
After the handshake, implementations <span class="bcp14">MUST</span> use the highest available
sending epoch.<a href="#section-7-7" class="pilcrow">¶</a></p>
<div id="sending-acks">
<section id="section-7.1">
        <h3 id="name-sending-acks">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-sending-acks" class="section-name selfRef">Sending ACKs</a>
        </h3>
<p id="section-7.1-1">When an implementation detects a disruption in the receipt of the
current incoming flight, it <span class="bcp14">SHOULD</span> generate an ACK that covers the
messages from that flight which it has received and processed so far.
Implementations have some discretion about which events to treat
as signs of disruption, but it is <span class="bcp14">RECOMMENDED</span> that they generate
ACKs under two circumstances:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-2.1">When they receive a message or fragment which is out of order,
either because it is not the next expected message or because
it is not the next piece of the current message.<a href="#section-7.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.2">When they have received part of a flight and do not immediately
receive the rest of the flight (which may be in the same UDP
datagram). "Immediately" is hard to define. One approach is to
set a timer for 1/4 the current retransmit timer value when
the first record in the flight is received and then send an
ACK when that timer expires. Note: The 1/4 value here is somewhat
arbitrary. Given that the round trip estimates in the DTLS
handshake are generally very rough (or the default), any
value will be an approximation, and there is an inherent
compromise due to competition between retransmission due to over-aggressive ACKing
and over-aggressive timeout-based retransmission.
As a comparison point,
QUIC's loss-based recovery algorithms
(<span>[<a href="#RFC9002" class="xref">RFC9002</a>], <a href="https://www.rfc-editor.org/rfc/rfc9002#section-6.1.2" class="relref">Section 6.1.2</a></span>)
work out to a delay of about 1/3 of the retransmit timer.<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-3">In general, flights <span class="bcp14">MUST</span> be ACKed unless they are implicitly
acknowledged. In the present specification, the following flights are implicitly acknowledged
by the receipt of the next flight, which generally immediately follows the flight:<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.1-4">
<li id="section-7.1-4.1">Handshake flights other than the client's final flight of the
main handshake.<a href="#section-7.1-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.1-4.2">The server's post-handshake CertificateRequest.<a href="#section-7.1-4.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-7.1-5">ACKs <span class="bcp14">SHOULD NOT</span> be sent for these flights unless
        the responding flight cannot be generated immediately.
        All other flights <span class="bcp14">MUST</span> be ACKed.
In this case,
implementations <span class="bcp14">MAY</span> send explicit ACKs for the complete received
flight even though it will eventually also be implicitly acknowledged
through the responding flight. A notable example for this is
the case of client authentication in constrained
environments, where generating the CertificateVerify message can
take considerable time on the client.
Implementations <span class="bcp14">MAY</span> acknowledge the records corresponding to each transmission of
each flight or simply acknowledge the most recent one. In general,
implementations <span class="bcp14">SHOULD</span> ACK as many received packets as can fit
into the ACK record, as this provides the most complete information
and thus reduces the chance of spurious retransmission; if space
is limited, implementations <span class="bcp14">SHOULD</span> favor including records which
have not yet been acknowledged.<a href="#section-7.1-5" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.1-6">Note: While some post-handshake messages follow a request/response
pattern, this does not necessarily imply receipt.
For example, a KeyUpdate sent in response to a KeyUpdate with
request_update set to "update_requested" does not implicitly
acknowledge the earlier KeyUpdate message because the two KeyUpdate
messages might have crossed in flight.<a href="#section-7.1-6" class="pilcrow">¶</a></p>
<p id="section-7.1-7">ACKs <span class="bcp14">MUST NOT</span> be sent for records of any content type
other than handshake or for records which cannot be deprotected.<a href="#section-7.1-7" class="pilcrow">¶</a></p>
<p id="section-7.1-8">Note that in some cases it may be necessary to send an ACK which
does not contain any record numbers. For instance, a client
might receive an EncryptedExtensions message prior to receiving
a ServerHello. Because it cannot decrypt the EncryptedExtensions,
it cannot safely acknowledge it (as it might be damaged). If the client
does not send an ACK, the server will eventually retransmit
its first flight, but this might take far longer than the
actual round trip time between client and server. Having
the client send an empty ACK shortcuts this process.<a href="#section-7.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="receiving-acks">
<section id="section-7.2">
        <h3 id="name-receiving-acks">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-receiving-acks" class="section-name selfRef">Receiving ACKs</a>
        </h3>
<p id="section-7.2-1">When an implementation receives an ACK, it <span class="bcp14">SHOULD</span> record that the
messages or message fragments sent in the records being
ACKed were received and omit them from any future
retransmissions. Upon receipt of an ACK that leaves it with
only some messages from a flight having been acknowledged,
an implementation <span class="bcp14">SHOULD</span> retransmit the unacknowledged
messages or fragments. Note that this requires implementations to
track which messages appear in which records. Once all the messages in a flight have been
acknowledged, the implementation <span class="bcp14">MUST</span> cancel all retransmissions
of that flight.
Implementations <span class="bcp14">MUST</span> treat a record
as having been acknowledged if it appears in any ACK; this
prevents spurious retransmission in cases where a flight is
very large and the receiver is forced to elide acknowledgements
for records which have already been ACKed.
As noted above, the receipt of any record responding
to a given flight <span class="bcp14">MUST</span> be taken as an implicit acknowledgement for the entire
flight to which it is responding.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="design-rationale">
<section id="section-7.3">
        <h3 id="name-design-rationale">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-design-rationale" class="section-name selfRef">Design Rationale</a>
        </h3>
<p id="section-7.3-1">ACK messages are used in two circumstances, namely:<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3-2.1">On sign of disruption, or lack of progress; and<a href="#section-7.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-2.2">To indicate complete receipt of the last flight in a handshake.<a href="#section-7.3-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.3-3">In the first case, the use of the ACK message is optional, because
 the peer will retransmit in any case and therefore the ACK just
 allows for selective or early retransmission, as opposed to the
 timeout-based whole flight retransmission in previous
 versions of DTLS.
 When DTLS 1.3 is used in deployments
with lossy networks, such as low-power, long-range radio networks as well as
low-power mesh networks, the use of ACKs is recommended.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">The use of the ACK for the second case is mandatory for the proper functioning of the
protocol. For instance, the ACK message sent by the client in <a href="#dtls-msg-epoch" class="xref">Figure 13</a>
acknowledges receipt and processing of Record 4 (containing the NewSessionTicket
message), and if it is not sent, the server will continue retransmission
of the NewSessionTicket indefinitely until its maximum retransmission count is reached.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="key-updates">
<section id="section-8">
      <h2 id="name-key-updates">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-key-updates" class="section-name selfRef">Key Updates</a>
      </h2>
<p id="section-8-1">As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
indicate that they are updating their sending keys.  As with other
handshake messages with no built-in response, KeyUpdates <span class="bcp14">MUST</span> be
acknowledged.  In order to facilitate epoch reconstruction
(<a href="#reconstructing" class="xref">Section 4.2.2</a>), implementations <span class="bcp14">MUST NOT</span> send records with the new keys or
send a new KeyUpdate until the previous KeyUpdate has been
acknowledged (this avoids having too many epochs in active use).<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Due to loss and/or reordering, DTLS 1.3 implementations
may receive a record with an older epoch than the
current one (the requirements above preclude receiving
a newer record). They <span class="bcp14">SHOULD</span> attempt to process those records
with that epoch (see <a href="#reconstructing" class="xref">Section 4.2.2</a> for information
on determining the correct epoch) but <span class="bcp14">MAY</span> opt to discard
such out-of-epoch records.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Due to the possibility of an ACK message for a KeyUpdate being lost and thereby
preventing the sender of the KeyUpdate from updating its keying material,
receivers <span class="bcp14">MUST</span> retain the pre-update keying material until receipt and successful
decryption of a message using the new keys.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4"><a href="#dtls-key-update" class="xref">Figure 14</a> shows an example exchange illustrating that successful
ACK processing updates the keys of the KeyUpdate message sender, which is
reflected in the change of epoch values.<a href="#section-8-4" class="pilcrow">¶</a></p>
<span id="name-example-dtls-key-update"></span><div id="dtls-key-update">
<figure id="figure-14">
        <div class="alignLeft art-text artwork" id="section-8-5.1">
<pre>
Client                                             Server

      /-------------------------------------------\
     |                                             |
     |             Initial Handshake               |
      \-------------------------------------------/


 [Application Data]         --------&gt;
 (epoch=3)

                            &lt;--------      [Application Data]
                                                    (epoch=3)

      /-------------------------------------------\
     |                                             |
     |              Some time later ...            |
      \-------------------------------------------/


 [Application Data]         --------&gt;
 (epoch=3)


 [KeyUpdate]
 (+ update_requested        --------&gt;
 (epoch 3)


                            &lt;--------      [Application Data]
                                                    (epoch=3)


                                                        [ACK]
                            &lt;--------               (epoch=3)


 [Application Data]
 (epoch=4)                  --------&gt;



                            &lt;--------             [KeyUpdate]
                                                    (epoch=3)


 [ACK]                      --------&gt;
 (epoch=4)


                            &lt;--------      [Application Data]
                                                    (epoch=4)
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-example-dtls-key-update" class="selfRef">Example DTLS Key Update</a>
        </figcaption></figure>
</div>
<p id="section-8-6">
With a 128-bit key as in AES-128, rekeying 2^64 times has a high
probability of key reuse within a given connection. Note that even if
the key repeats, the IV is also independently generated. In order to
provide an extra margin of security, sending implementations <span class="bcp14">MUST NOT</span>
allow the epoch to exceed 2^48-1. In order to allow this value to
be changed later, receiving implementations <span class="bcp14">MUST NOT</span>
enforce this rule. If a sending implementation receives a KeyUpdate
with request_update set to "update_requested", it <span class="bcp14">MUST NOT</span> send
its own KeyUpdate if that would cause it to exceed these limits
and <span class="bcp14">SHOULD</span> instead ignore the "update_requested" flag.
Note: this overrides the requirement in TLS 1.3 to always
send a KeyUpdate in response to "update_requested".<a href="#section-8-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="connection-id-updates">
<section id="section-9">
      <h2 id="name-connection-id-updates">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-connection-id-updates" class="section-name selfRef">Connection ID Updates</a>
      </h2>
<p id="section-9-1">If the client and server have negotiated the "connection_id"
extension <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>, either side
can send a new CID that it wishes the other side to use
in a NewConnectionId message.<a href="#section-9-1" class="pilcrow">¶</a></p>
<div id="section-9-2">
<pre class="lang-tls-presentation sourcecode">
    enum {
        cid_immediate(0), cid_spare(1), (255)
    } ConnectionIdUsage;

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

    struct {
        ConnectionId cids&lt;0..2^16-1&gt;;
        ConnectionIdUsage usage;
    } NewConnectionId;
</pre><a href="#section-9-2" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-9-3">
        <dt id="section-9-3.1">cids:</dt>
        <dd style="margin-left: 1.5em" id="section-9-3.2">
  Indicates the set of CIDs that the sender wishes the peer to use.<a href="#section-9-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-3.3">usage:</dt>
        <dd style="margin-left: 1.5em" id="section-9-3.4">
  Indicates whether the new CIDs should be used immediately or are
spare.  If usage is set to "cid_immediate", then one of the new CIDs
<span class="bcp14">MUST</span> be used immediately for all future records. If it is set to
"cid_spare", then either an existing or new CID <span class="bcp14">MAY</span> be used.<a href="#section-9-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-9-4">Endpoints <span class="bcp14">SHOULD</span> use receiver-provided CIDs in the order they were provided.
Implementations which receive more spare CIDs than they wish to maintain
<span class="bcp14">MAY</span> simply discard any extra CIDs.
Endpoints <span class="bcp14">MUST NOT</span> have more than one NewConnectionId message outstanding.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">Implementations which either did not negotiate the "connection_id" extension
or which have negotiated receiving an empty CID <span class="bcp14">MUST NOT</span>
send NewConnectionId. Implementations <span class="bcp14">MUST NOT</span> send RequestConnectionId
when sending an empty Connection ID. Implementations which detect a violation
of these rules <span class="bcp14">MUST</span> terminate the connection with an "unexpected_message"
alert.<a href="#section-9-5" class="pilcrow">¶</a></p>
<p id="section-9-6">Implementations <span class="bcp14">SHOULD</span> use a new CID whenever sending on a new path
and <span class="bcp14">SHOULD</span> request new CIDs for this purpose if path changes are anticipated.<a href="#section-9-6" class="pilcrow">¶</a></p>
<div id="section-9-7">
<pre class="lang-tls-presentation sourcecode">
    struct {
      uint8 num_cids;
    } RequestConnectionId;
</pre><a href="#section-9-7" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-9-8">
        <dt id="section-9-8.1">num_cids:</dt>
        <dd style="margin-left: 1.5em" id="section-9-8.2">
  The number of CIDs desired.<a href="#section-9-8.2" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-9-9">Endpoints <span class="bcp14">SHOULD</span> respond to RequestConnectionId by sending a
NewConnectionId with usage "cid_spare" containing num_cids CIDs as soon as
possible.  Endpoints <span class="bcp14">MUST NOT</span> send a RequestConnectionId message
when an existing request is still unfulfilled; this implies that
endpoints need to request new CIDs well in advance.  An endpoint <span class="bcp14">MAY</span>
handle requests which it considers excessive by responding with
a NewConnectionId message containing fewer than num_cids CIDs,
including no CIDs at all. Endpoints <span class="bcp14">MAY</span> handle an excessive number
of RequestConnectionId messages by terminating the connection
using a "too_many_cids_requested" (alert number 52) alert.<a href="#section-9-9" class="pilcrow">¶</a></p>
<p id="section-9-10">Endpoints <span class="bcp14">MUST NOT</span> send either of these messages if they did not negotiate a
CID. If an implementation receives these messages when CIDs
were not negotiated, it <span class="bcp14">MUST</span> abort the connection with an "unexpected_message"
alert.<a href="#section-9-10" class="pilcrow">¶</a></p>
<div id="connection-id-example">
<section id="section-9.1">
        <h3 id="name-connection-id-example">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-connection-id-example" class="section-name selfRef">Connection ID Example</a>
        </h3>
<p id="section-9.1-1">Below is an example exchange for DTLS 1.3 using a single
CID in each direction.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-9.1-2">Note: The "connection_id" extension, which is used in ClientHello and ServerHello messages, is defined in
<span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>.<a href="#section-9.1-2" class="pilcrow">¶</a></p>
<span id="name-example-dtls-13-exchange-wi"></span><div id="dtls-example">
<figure id="figure-15">
          <div class="alignLeft art-text artwork" id="section-9.1-3.1">
<pre>
Client                                             Server
------                                             ------

ClientHello
(connection_id=5)
                            --------&gt;


                            &lt;--------       HelloRetryRequest
                                                     (cookie)

ClientHello                 --------&gt;
(connection_id=5)
  + cookie

                            &lt;--------             ServerHello
                                          (connection_id=100)
                                          EncryptedExtensions
                                                      (cid=5)
                                                  Certificate
                                                      (cid=5)
                                            CertificateVerify
                                                      (cid=5)
                                                     Finished
                                                      (cid=5)

Certificate                --------&gt;
(cid=100)
CertificateVerify
(cid=100)
Finished
(cid=100)
                           &lt;--------                      ACK
                                                      (cid=5)

Application Data           ========&gt;
(cid=100)
                           &lt;========         Application Data
                                                      (cid=5)
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-example-dtls-13-exchange-wi" class="selfRef">Example DTLS 1.3 Exchange with CIDs</a>
          </figcaption></figure>
</div>
<p id="section-9.1-4">If no CID is negotiated, then the receiver <span class="bcp14">MUST</span> reject any
records it receives that contain a CID.<a href="#section-9.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="application-data-protocol">
<section id="section-10">
      <h2 id="name-application-data-protocol">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-application-data-protocol" class="section-name selfRef">Application Data Protocol</a>
      </h2>
<p id="section-10-1">Application data messages are carried by the record layer and are split
into records
and encrypted based on the current connection state. The messages
are treated as transparent data to the record layer.<a href="#section-10-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-11">
      <h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-11-1">Security issues are discussed primarily in <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span>.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">The primary additional security consideration raised by DTLS is that
of denial of service by excessive resource consumption.  DTLS includes a cookie exchange designed to
protect against denial of service.  However, implementations that do
not use this cookie exchange are still vulnerable to DoS.  In
particular, DTLS servers that do not use the cookie exchange may be
used as attack amplifiers even if they themselves are not
experiencing DoS.  Therefore, DTLS servers <span class="bcp14">SHOULD</span> use the cookie
exchange unless there is good reason to believe that amplification is
not a threat in their environment.  Clients <span class="bcp14">MUST</span> be prepared to do a
cookie exchange with every handshake.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">Some key properties required of the cookie for the cookie-exchange mechanism
to be functional are described in <span><a href="https://www.rfc-editor.org/rfc/rfc2522#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC2522" class="xref">RFC2522</a>]</span>:<a href="#section-11-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11-4.1">The cookie <span class="bcp14">MUST</span> depend on the client's address.<a href="#section-11-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-4.2">It <span class="bcp14">MUST NOT</span> be possible for anyone other than the issuing entity to generate
cookies that are accepted as valid by that entity.  This typically entails
an integrity check based on a secret key.<a href="#section-11-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-4.3">Cookie generation and verification are triggered by unauthenticated parties,
and as such their resource consumption needs to be restrained in order to
avoid having the cookie-exchange mechanism itself serve as a DoS vector.<a href="#section-11-4.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-11-5">Although the cookie must allow the server to produce the right handshake
transcript, it <span class="bcp14">SHOULD</span> be constructed so that knowledge of the cookie
is insufficient to reproduce the ClientHello contents. Otherwise,
this may create problems with future extensions such as Encrypted Client Hello <span>[<a href="#TLS-ECH" class="xref">TLS-ECH</a>]</span>.<a href="#section-11-5" class="pilcrow">¶</a></p>
<p id="section-11-6">When cookies are generated using a keyed authentication mechanism,
it should be possible to rotate the associated
secret key, so that temporary compromise of the key does not permanently
compromise the integrity of the cookie-exchange mechanism.  Though this secret
is not as high-value as, e.g., a session-ticket-encryption key, rotating the
cookie-generation key on a similar timescale would ensure that the
key rotation functionality is exercised regularly and thus in working order.<a href="#section-11-6" class="pilcrow">¶</a></p>
<p id="section-11-7">The cookie exchange provides address validation during the initial handshake.
DTLS with Connection IDs allows for endpoint addresses to change during the
association; any such updated addresses are not covered by the cookie exchange
during the handshake.
DTLS implementations <span class="bcp14">MUST NOT</span> update the address they send to in response
to packets from a different address unless they first perform some
reachability test; no such test is defined in this specification
and a future specification would need to specify a complete procedure for
how and when to update addresses. Even
with such a test, an active on-path adversary can also black-hole traffic or
create a reflection attack against third parties because a DTLS peer
has no means to distinguish a genuine address update event (for
example, due to a NAT rebinding) from one that is malicious. This
attack is of concern when there is a large asymmetry of
request/response message sizes.<a href="#section-11-7" class="pilcrow">¶</a></p>
<p id="section-11-8">With the exception of order protection and non-replayability, the security
guarantees for DTLS 1.3 are the same as TLS 1.3. While TLS always provides
order protection and non-replayability, DTLS does not provide order protection
and may not provide replay protection.<a href="#section-11-8" class="pilcrow">¶</a></p>
<p id="section-11-9">Unlike TLS implementations, DTLS implementations <span class="bcp14">SHOULD NOT</span> respond
to invalid records by terminating the connection.<a href="#section-11-9" class="pilcrow">¶</a></p>
<p id="section-11-10">TLS 1.3 requires replay protection for 0-RTT data (or rather, for connections
that use 0-RTT data; see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-8" class="relref">Section 8</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>).  DTLS provides an optional
per-record replay-protection mechanism, since datagram protocols are
inherently subject to message reordering and replay.  These two
replay-protection mechanisms are orthogonal, and neither mechanism meets the
      requirements for the other.<a href="#section-11-10" class="pilcrow">¶</a></p>
<p id="section-11-11">
        DTLS 1.3's handshake transcript does not include the new DTLS fields,
which makes it have the same format as TLS 1.3. However, the DTLS 1.3 and
TLS 1.3 transcripts are disjoint because they use different version
numbers. Additionally, the DTLS 1.3 key schedule uses a different label
and so will produce different keys for the same transcript.<a href="#section-11-11" class="pilcrow">¶</a></p>
<p id="section-11-12">The security and privacy properties of the CID for DTLS 1.3 build
on top of what is described for DTLS 1.2 in <span>[<a href="#RFC9146" class="xref">RFC9146</a>]</span>. There are,
however, several differences:<a href="#section-11-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11-13.1">In both versions of DTLS, extension negotiation is used to agree on the use of the CID
feature and the CID values. In both versions, the CID is carried in the DTLS record header (if negotiated).
However, the way the CID is included in the record header differs between the two versions.<a href="#section-11-13.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-13.2">The use of the post-handshake message allows the client and the server
to update their CIDs, and those values are exchanged with confidentiality
protection.<a href="#section-11-13.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-13.3">The ability to use multiple CIDs allows for improved privacy properties
in multihomed scenarios. When only a single CID is in use on multiple
paths from such a host, an adversary can correlate the communication
interaction across paths, which adds further privacy concerns. In order
to prevent this, implementations <span class="bcp14">SHOULD</span> attempt to use fresh CIDs
whenever they change local addresses or ports (though this is not always
possible to detect). The RequestConnectionId message can be used by a peer
to ask for new CIDs to ensure that a pool of suitable CIDs is available.<a href="#section-11-13.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-13.4">The mechanism for encrypting sequence numbers (<a href="#rne" class="xref">Section 4.2.3</a>) prevents
trivial tracking by on-path adversaries that attempt to correlate the
pattern of sequence numbers received on different paths; such tracking
could occur even when different CIDs are used on each path, in the
absence of sequence number encryption. Switching CIDs based on certain
events, or even regularly, helps against tracking by on-path
adversaries.  Note that sequence number encryption is used for all
encrypted DTLS 1.3 records irrespective of whether a CID is used or
not.  Unlike the sequence number, the epoch is not encrypted because it acts as a key identifier, which
may improve correlation of packets from a single connection across
different network paths.<a href="#section-11-13.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-11-13.5">DTLS 1.3 encrypts handshake messages much earlier than in previous
DTLS versions. Therefore, less information identifying the DTLS client, such as
the client certificate, is available to an on-path adversary.<a href="#section-11-13.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="changes-since-dtls-12">
<section id="section-12">
      <h2 id="name-changes-since-dtls-12">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-changes-since-dtls-12" class="section-name selfRef">Changes since DTLS 1.2</a>
      </h2>
<p id="section-12-1">Since TLS 1.3 introduces a large number of changes with respect to TLS 1.2, the list
of changes from DTLS 1.2 to DTLS 1.3 is equally large. For this reason,
this section focuses on the most important changes only.<a href="#section-12-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12-2.1">New handshake pattern, which leads to a shorter message exchange.<a href="#section-12-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.2">Only AEAD ciphers are supported. Additional data calculation has been simplified.<a href="#section-12-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.3">Removed support for weaker and older cryptographic algorithms.<a href="#section-12-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.4">HelloRetryRequest of TLS 1.3 used instead of HelloVerifyRequest.<a href="#section-12-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.5">More flexible cipher suite negotiation.<a href="#section-12-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.6">New session resumption mechanism.<a href="#section-12-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.7">PSK authentication redefined.<a href="#section-12-2.7" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.8">New key derivation hierarchy utilizing a new key derivation construct.<a href="#section-12-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.9">Improved version negotiation.<a href="#section-12-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.10">Optimized record layer encoding and thereby its size.<a href="#section-12-2.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.11">Added CID functionality.<a href="#section-12-2.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-12-2.12">Sequence numbers are encrypted.<a href="#section-12-2.12" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="updates-affecting-dtls-12">
<section id="section-13">
      <h2 id="name-updates-affecting-dtls-12">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-updates-affecting-dtls-12" class="section-name selfRef">Updates Affecting DTLS 1.2</a>
      </h2>
<p id="section-13-1">This document defines several changes that optionally affect
implementations of DTLS 1.2, including those which do not also support
DTLS 1.3.<a href="#section-13-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-13-2.1">A version downgrade protection mechanism as described
in <span>[<a href="#RFC8446" class="xref">TLS13</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.1.3" class="relref">Section 4.1.3</a></span> and applying to DTLS as
described in <a href="#clienthello-message" class="xref">Section 5.3</a>.<a href="#section-13-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-13-2.2">The updates described in <span>[<a href="#RFC8446" class="xref">TLS13</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#section-1.3" class="relref">Section 1.3</a></span>.<a href="#section-13-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-13-2.3">The new compliance requirements described in <span>[<a href="#RFC8446" class="xref">TLS13</a>], <a href="https://www.rfc-editor.org/rfc/rfc8446#section-9.3" class="relref">Section 9.3</a></span>.<a href="#section-13-2.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="iana-considerations">
<section id="section-14">
      <h2 id="name-iana-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-14-1">IANA has allocated the content type value 26 in the "TLS ContentType"
registry for the ACK message, defined in <a href="#ack-msg" class="xref">Section 7</a>.
The value for the "DTLS-OK" column is "Y".  IANA has reserved
the content type range 32-63 so that content types in this range are not
allocated.<a href="#section-14-1" class="pilcrow">¶</a></p>
<p id="section-14-2">IANA has allocated value 52 for the "too_many_cids_requested" alert in
the "TLS Alerts" registry. The value for the "DTLS-OK" column is "Y".<a href="#section-14-2" class="pilcrow">¶</a></p>
<p id="section-14-3">IANA has allocated two values in the "TLS HandshakeType"
registry, defined in <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span>, for request_connection_id (9) and
new_connection_id (10), as defined in this document.  The value for the
"DTLS-OK" column is "Y".<a href="#section-14-3" class="pilcrow">¶</a></p>
<p id="section-14-4">IANA has added this RFC as a reference to the "TLS Cipher Suites" registry
along with the following Note:<a href="#section-14-4" class="pilcrow">¶</a></p>
<blockquote id="section-14-5">
Any TLS cipher suite that is specified for use with DTLS <span class="bcp14">MUST</span>
define limits on the use of the associated AEAD function that
preserves margins for both confidentiality and integrity,
as specified in <a href="#aead-limits" class="xref">Section 4.5.3</a> of RFC 9147.<a href="#section-14-5" class="pilcrow">¶</a>
</blockquote>
</section>
</div>
<section id="section-15">
      <h2 id="name-references">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-15.1">
        <h3 id="name-normative-references">
<a href="#section-15.1" class="section-number selfRef">15.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC8439">[CHACHA]</dt>
        <dd>
<span class="refAuthor">Nir, Y.</span> and <span class="refAuthor">A. Langley</span>, <span class="refTitle">"ChaCha20 and Poly1305 for IETF Protocols"</span>, <span class="seriesInfo">RFC 8439</span>, <span class="seriesInfo">DOI 10.17487/RFC8439</span>, <time datetime="2018-06" class="refDate">June 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8439">https://www.rfc-editor.org/info/rfc8439</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0768">[RFC0768]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"User Datagram Protocol"</span>, <span class="seriesInfo">STD 6</span>, <span class="seriesInfo">RFC 768</span>, <span class="seriesInfo">DOI 10.17487/RFC0768</span>, <time datetime="1980-08" class="refDate">August 1980</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc768">https://www.rfc-editor.org/info/rfc768</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span> and <span class="refAuthor">S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
<dd class="break"></dd>
<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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC4443">[RFC4443]</dt>
        <dd>
<span class="refAuthor">Conta, A.</span>, <span class="refAuthor">Deering, S.</span>, and <span class="refAuthor">M. Gupta, Ed.</span>, <span class="refTitle">"Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 89</span>, <span class="seriesInfo">RFC 4443</span>, <span class="seriesInfo">DOI 10.17487/RFC4443</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4443">https://www.rfc-editor.org/info/rfc4443</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4821">[RFC4821]</dt>
        <dd>
<span class="refAuthor">Mathis, M.</span> and <span class="refAuthor">J. Heffner</span>, <span class="refTitle">"Packetization Layer Path MTU Discovery"</span>, <span class="seriesInfo">RFC 4821</span>, <span class="seriesInfo">DOI 10.17487/RFC4821</span>, <time datetime="2007-03" class="refDate">March 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4821">https://www.rfc-editor.org/info/rfc4821</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6298">[RFC6298]</dt>
        <dd>
<span class="refAuthor">Paxson, V.</span>, <span class="refAuthor">Allman, M.</span>, <span class="refAuthor">Chu, J.</span>, and <span class="refAuthor">M. Sargent</span>, <span class="refTitle">"Computing TCP's Retransmission Timer"</span>, <span class="seriesInfo">RFC 6298</span>, <span class="seriesInfo">DOI 10.17487/RFC6298</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6298">https://www.rfc-editor.org/info/rfc6298</a>&gt;</span>. </dd>
<dd class="break"></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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC9146">[RFC9146]</dt>
        <dd>
<span class="refAuthor">Rescorla, E., Ed.</span>, <span class="refAuthor">Tschofenig, H., Ed.</span>, <span class="refAuthor">Fossati, T.</span>, and <span class="refAuthor">A. Kraus</span>, <span class="refTitle">"Connection Identifier for DTLS 1.2"</span>, <span class="seriesInfo">RFC 9146</span>, <span class="seriesInfo">DOI 10.17487/RFC9146</span>, <time datetime="2022-03" class="refDate">March 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9146">https://www.rfc-editor.org/info/rfc9146</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[TLS13]</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" class="refDate">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>
<dd class="break"></dd>
</dl>
</section>
<section id="section-15.2">
        <h3 id="name-informative-references">
<a href="#section-15.2" class="section-number selfRef">15.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="AEAD-LIMITS">[AEAD-LIMITS]</dt>
        <dd>
<span class="refAuthor">Günther, F.</span>, <span class="refAuthor">Thomson, M.</span>, and <span class="refAuthor">C. A. Wood</span>, <span class="refTitle">"Usage Limits on AEAD Algorithms"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-irtf-cfrg-aead-limits-04</span>, <time datetime="2022-03-07" class="refDate">7 March 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04">https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-aead-limits-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="AEBounds">[AEBounds]</dt>
        <dd>
<span class="refAuthor">Luykx, A.</span> and <span class="refAuthor">K. Paterson</span>, <span class="refTitle">"Limits on Authenticated Encryption Use in TLS"</span>, <time datetime="2017-08-28" class="refDate">28 August 2017</time>, <span>&lt;<a href="https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf">https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CCM-ANALYSIS">[CCM-ANALYSIS]</dt>
        <dd>
<span class="refAuthor">Jonsson, J.</span>, <span class="refTitle">"On the Security of CTR + CBC-MAC"</span>, <span class="refContent">Selected Areas in Cryptography pp. 76-93</span>, <span class="seriesInfo">DOI 10.1007/3-540-36492-7_7</span>, <time datetime="2003-02" class="refDate">February 2003</time>, <span>&lt;<a href="https://doi.org/10.1007/3-540-36492-7_7">https://doi.org/10.1007/3-540-36492-7_7</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8996">[DEPRECATE]</dt>
        <dd>
<span class="refAuthor">Moriarty, K.</span> and <span class="refAuthor">S. Farrell</span>, <span class="refTitle">"Deprecating TLS 1.0 and TLS 1.1"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 8996</span>, <span class="seriesInfo">DOI 10.17487/RFC8996</span>, <time datetime="2021-03" class="refDate">March 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8996">https://www.rfc-editor.org/info/rfc8996</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-uta-tls13-iot-profile">[IOT-PROFILE]</dt>
        <dd>
<span class="refAuthor">Tschofenig, H.</span> and <span class="refAuthor">T. Fossati</span>, <span class="refTitle">"TLS/DTLS 1.3 Profiles for the Internet of Things"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-uta-tls13-iot-profile-04</span>, <time datetime="2022-03-07" class="refDate">7 March 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04">https://datatracker.ietf.org/doc/html/draft-ietf-uta-tls13-iot-profile-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2522">[RFC2522]</dt>
        <dd>
<span class="refAuthor">Karn, P.</span> and <span class="refAuthor">W. Simpson</span>, <span class="refTitle">"Photuris: Session-Key Management Protocol"</span>, <span class="seriesInfo">RFC 2522</span>, <span class="seriesInfo">DOI 10.17487/RFC2522</span>, <time datetime="1999-03" class="refDate">March 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2522">https://www.rfc-editor.org/info/rfc2522</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4303">[RFC4303]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4303</span>, <span class="seriesInfo">DOI 10.17487/RFC4303</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4303">https://www.rfc-editor.org/info/rfc4303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4340">[RFC4340]</dt>
        <dd>
<span class="refAuthor">Kohler, E.</span>, <span class="refAuthor">Handley, M.</span>, and <span class="refAuthor">S. Floyd</span>, <span class="refTitle">"Datagram Congestion Control Protocol (DCCP)"</span>, <span class="seriesInfo">RFC 4340</span>, <span class="seriesInfo">DOI 10.17487/RFC4340</span>, <time datetime="2006-03" class="refDate">March 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4340">https://www.rfc-editor.org/info/rfc4340</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4346">[RFC4346]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.1"</span>, <span class="seriesInfo">RFC 4346</span>, <span class="seriesInfo">DOI 10.17487/RFC4346</span>, <time datetime="2006-04" class="refDate">April 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4346">https://www.rfc-editor.org/info/rfc4346</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4347">[RFC4347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security"</span>, <span class="seriesInfo">RFC 4347</span>, <span class="seriesInfo">DOI 10.17487/RFC4347</span>, <time datetime="2006-04" class="refDate">April 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4347">https://www.rfc-editor.org/info/rfc4347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4960">[RFC4960]</dt>
        <dd>
<span class="refAuthor">Stewart, R., Ed.</span>, <span class="refTitle">"Stream Control Transmission Protocol"</span>, <span class="seriesInfo">RFC 4960</span>, <span class="seriesInfo">DOI 10.17487/RFC4960</span>, <time datetime="2007-09" class="refDate">September 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4960">https://www.rfc-editor.org/info/rfc4960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5238">[RFC5238]</dt>
        <dd>
<span class="refAuthor">Phelan, T.</span>, <span class="refTitle">"Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)"</span>, <span class="seriesInfo">RFC 5238</span>, <span class="seriesInfo">DOI 10.17487/RFC5238</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5238">https://www.rfc-editor.org/info/rfc5238</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5246">[RFC5246]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">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" class="refDate">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>
<dd class="break"></dd>
<dt id="RFC5763">[RFC5763]</dt>
        <dd>
<span class="refAuthor">Fischl, J.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 5763</span>, <span class="seriesInfo">DOI 10.17487/RFC5763</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5763">https://www.rfc-editor.org/info/rfc5763</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5764">[RFC5764]</dt>
        <dd>
<span class="refAuthor">McGrew, D.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)"</span>, <span class="seriesInfo">RFC 5764</span>, <span class="seriesInfo">DOI 10.17487/RFC5764</span>, <time datetime="2010-05" class="refDate">May 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5764">https://www.rfc-editor.org/info/rfc5764</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[RFC6066]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6347">[RFC6347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7296">[RFC7296]</dt>
        <dd>
<span class="refAuthor">Kaufman, C.</span>, <span class="refAuthor">Hoffman, P.</span>, <span class="refAuthor">Nir, Y.</span>, <span class="refAuthor">Eronen, P.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Internet Key Exchange Protocol Version 2 (IKEv2)"</span>, <span class="seriesInfo">STD 79</span>, <span class="seriesInfo">RFC 7296</span>, <span class="seriesInfo">DOI 10.17487/RFC7296</span>, <time datetime="2014-10" class="refDate">October 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7296">https://www.rfc-editor.org/info/rfc7296</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span>, <span class="refAuthor">Holz, R.</span>, and <span class="refAuthor">P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7924">[RFC7924]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span> and <span class="refAuthor">H. Tschofenig</span>, <span class="refTitle">"Transport Layer Security (TLS) Cached Information Extension"</span>, <span class="seriesInfo">RFC 7924</span>, <span class="seriesInfo">DOI 10.17487/RFC7924</span>, <time datetime="2016-07" class="refDate">July 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7924">https://www.rfc-editor.org/info/rfc7924</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7983">[RFC7983]</dt>
        <dd>
<span class="refAuthor">Petit-Huguenin, M.</span> and <span class="refAuthor">G. Salgueiro</span>, <span class="refTitle">"Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 7983</span>, <span class="seriesInfo">DOI 10.17487/RFC7983</span>, <time datetime="2016-09" class="refDate">September 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7983">https://www.rfc-editor.org/info/rfc7983</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8201">[RFC8201]</dt>
        <dd>
<span class="refAuthor">McCann, J.</span>, <span class="refAuthor">Deering, S.</span>, <span class="refAuthor">Mogul, J.</span>, and <span class="refAuthor">R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8445">[RFC8445]</dt>
        <dd>
<span class="refAuthor">Keranen, A.</span>, <span class="refAuthor">Holmberg, C.</span>, and <span class="refAuthor">J. Rosenberg</span>, <span class="refTitle">"Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal"</span>, <span class="seriesInfo">RFC 8445</span>, <span class="seriesInfo">DOI 10.17487/RFC8445</span>, <time datetime="2018-07" class="refDate">July 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8445">https://www.rfc-editor.org/info/rfc8445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8879">[RFC8879]</dt>
        <dd>
<span class="refAuthor">Ghedini, A.</span> and <span class="refAuthor">V. Vasiliev</span>, <span class="refTitle">"TLS Certificate Compression"</span>, <span class="seriesInfo">RFC 8879</span>, <span class="seriesInfo">DOI 10.17487/RFC8879</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8879">https://www.rfc-editor.org/info/rfc8879</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9002">[RFC9002]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">I. Swett, Ed.</span>, <span class="refTitle">"QUIC Loss Detection and Congestion Control"</span>, <span class="seriesInfo">RFC 9002</span>, <span class="seriesInfo">DOI 10.17487/RFC9002</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9002">https://www.rfc-editor.org/info/rfc9002</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ROBUST">[ROBUST]</dt>
        <dd>
<span class="refAuthor">Fischlin, M.</span>, <span class="refAuthor">Günther, F.</span>, and <span class="refAuthor">C. Janson</span>, <span class="refTitle">"Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3"</span>, <span class="refContent">received 15 June 2020, last revised 22 February 2021</span>, <span>&lt;<a href="https://eprint.iacr.org/2020/718">https://eprint.iacr.org/2020/718</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="TLS-ECH">[TLS-ECH]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Oku, K.</span>, <span class="refAuthor">Sullivan, N.</span>, and <span class="refAuthor">C.A. Wood</span>, <span class="refTitle">"TLS Encrypted Client Hello"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-tls-esni-14</span>, <time datetime="2022-02-13" class="refDate">13 February 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14">https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="protocol-data-structures-and-constant-values">
<section id="appendix-A">
      <h2 id="name-protocol-data-structures-an">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-protocol-data-structures-an" class="section-name selfRef">Protocol Data Structures and Constant Values</a>
      </h2>
<p id="appendix-A-1">This section provides the normative protocol types and constants definitions.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<div id="record-layer">
<section id="appendix-A.1">
        <h3 id="name-record-layer">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-record-layer" class="section-name selfRef">Record Layer</a>
        </h3>
<div class="alignLeft art-text artwork" id="appendix-A.1-1">
<pre>
    struct {
        ContentType type;
        ProtocolVersion legacy_record_version;
        uint16 epoch = 0
        uint48 sequence_number;
        uint16 length;
        opaque fragment[DTLSPlaintext.length];
    } DTLSPlaintext;

    struct {
         opaque content[DTLSPlaintext.length];
         ContentType type;
         uint8 zeros[length_of_padding];
    } DTLSInnerPlaintext;

    struct {
        opaque unified_hdr[variable];
        opaque encrypted_record[length];
    } DTLSCiphertext;

    0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |0|0|1|C|S|L|E E|
    +-+-+-+-+-+-+-+-+
    | Connection ID |   Legend:
    | (if any,      |
    /  length as    /   C   - Connection ID (CID) present
    |  negotiated)  |   S   - Sequence number length
    +-+-+-+-+-+-+-+-+   L   - Length present
    |  8 or 16 bit  |   E   - Epoch
    |Sequence Number|
    +-+-+-+-+-+-+-+-+
    | 16 bit Length |
    | (if present)  |
    +-+-+-+-+-+-+-+-+

    struct {
        uint64 epoch;
        uint64 sequence_number;
    } RecordNumber;
</pre><a href="#appendix-A.1-1" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="handshake-protocol">
<section id="appendix-A.2">
        <h3 id="name-handshake-protocol">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-handshake-protocol" class="section-name selfRef">Handshake Protocol</a>
        </h3>
<div id="appendix-A.2-1">
<pre class="lang-tls-presentation sourcecode">
    enum {
        hello_request_RESERVED(0),
        client_hello(1),
        server_hello(2),
        hello_verify_request_RESERVED(3),
        new_session_ticket(4),
        end_of_early_data(5),
        hello_retry_request_RESERVED(6),
        encrypted_extensions(8),
        request_connection_id(9),           /* New */
        new_connection_id(10),              /* New */
        certificate(11),
        server_key_exchange_RESERVED(12),
        certificate_request(13),
        server_hello_done_RESERVED(14),
        certificate_verify(15),
        client_key_exchange_RESERVED(16),
        finished(20),
        certificate_url_RESERVED(21),
        certificate_status_RESERVED(22),
        supplemental_data_RESERVED(23),
        key_update(24),
        message_hash(254),
        (255)
    } HandshakeType;

    struct {
        HandshakeType msg_type;    /* handshake type */
        uint24 length;             /* bytes in message */
        uint16 message_seq;        /* DTLS-required field */
        uint24 fragment_offset;    /* DTLS-required field */
        uint24 fragment_length;    /* DTLS-required field */
        select (msg_type) {
            case client_hello:          ClientHello;
            case server_hello:          ServerHello;
            case end_of_early_data:     EndOfEarlyData;
            case encrypted_extensions:  EncryptedExtensions;
            case certificate_request:   CertificateRequest;
            case certificate:           Certificate;
            case certificate_verify:    CertificateVerify;
            case finished:              Finished;
            case new_session_ticket:    NewSessionTicket;
            case key_update:            KeyUpdate;
            case request_connection_id: RequestConnectionId;
            case new_connection_id:     NewConnectionId;
        } body;
    } Handshake;

    uint16 ProtocolVersion;
    opaque Random[32];

    uint8 CipherSuite[2];    /* Cryptographic suite selector */

    struct {
        ProtocolVersion legacy_version = { 254,253 }; // DTLSv1.2
        Random random;
        opaque legacy_session_id&lt;0..32&gt;;
        opaque legacy_cookie&lt;0..2^8-1&gt;;                  // DTLS
        CipherSuite cipher_suites&lt;2..2^16-2&gt;;
        opaque legacy_compression_methods&lt;1..2^8-1&gt;;
        Extension extensions&lt;8..2^16-1&gt;;
    } ClientHello;
</pre><a href="#appendix-A.2-1" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="acks">
<section id="appendix-A.3">
        <h3 id="name-acks">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-acks" class="section-name selfRef">ACKs</a>
        </h3>
<div id="appendix-A.3-1">
<pre class="lang-tls-presentation sourcecode">
    struct {
        RecordNumber record_numbers&lt;0..2^16-1&gt;;
    } ACK;
</pre><a href="#appendix-A.3-1" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="connection-id-management">
<section id="appendix-A.4">
        <h3 id="name-connection-id-management">
<a href="#appendix-A.4" class="section-number selfRef">A.4. </a><a href="#name-connection-id-management" class="section-name selfRef">Connection ID Management</a>
        </h3>
<div id="appendix-A.4-1">
<pre class="lang-tls-presentation sourcecode">
    enum {
        cid_immediate(0), cid_spare(1), (255)
    } ConnectionIdUsage;

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

    struct {
        ConnectionId cids&lt;0..2^16-1&gt;;
        ConnectionIdUsage usage;
    } NewConnectionId;

    struct {
      uint8 num_cids;
    } RequestConnectionId;
</pre><a href="#appendix-A.4-1" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="ccm-bounds">
<section id="appendix-B">
      <h2 id="name-analysis-of-limits-on-ccm-u">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-analysis-of-limits-on-ccm-u" class="section-name selfRef">Analysis of Limits on CCM Usage</a>
      </h2>
<p id="appendix-B-1">TLS <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span> and <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span> do not specify limits on key usage for
AEAD_AES_128_CCM.
 However, any AEAD that is used with DTLS requires limits on
use that ensure that both confidentiality and integrity are preserved. This
section documents that analysis for AEAD_AES_128_CCM.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2"><span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> is used as the basis of this
analysis. The results of that analysis are used to derive usage limits that are
based on those chosen in <span>[<a href="#RFC8446" class="xref">TLS13</a>]</span>.<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<p id="appendix-B-3">This analysis uses symbols for multiplication (*), division (/), and
exponentiation (^), plus parentheses for establishing precedence. The following
symbols are also used:<a href="#appendix-B-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="appendix-B-4">
        <dt id="appendix-B-4.1">t:</dt>
        <dd style="margin-left: 2.0em" id="appendix-B-4.2">
  The size of the authentication tag in bits. For this cipher, t is 128.<a href="#appendix-B-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-4.3">n:</dt>
        <dd style="margin-left: 2.0em" id="appendix-B-4.4">
  The size of the block function in bits. For this cipher, n is 128.<a href="#appendix-B-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-4.5">l:</dt>
        <dd style="margin-left: 2.0em" id="appendix-B-4.6">
  The number of blocks in each packet (see below).<a href="#appendix-B-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-4.7">q:</dt>
        <dd style="margin-left: 2.0em" id="appendix-B-4.8">
  The number of genuine packets created and protected by endpoints. This value
is the bound on the number of packets that can be protected before updating
keys.<a href="#appendix-B-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="appendix-B-4.9">v:</dt>
        <dd style="margin-left: 2.0em" id="appendix-B-4.10">
  The number of forged packets that endpoints will accept. This value is the
bound on the number of forged packets that an endpoint can reject before
updating keys.<a href="#appendix-B-4.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="appendix-B-5">The analysis of AEAD_AES_128_CCM relies on a count of the number of block
operations involved in producing each message. For simplicity, and to match the
analysis of other AEAD functions in <span>[<a href="#AEBounds" class="xref">AEBounds</a>]</span>, this analysis assumes a
packet length of 2^10 blocks and a packet size limit of 2^14 bytes.<a href="#appendix-B-5" class="pilcrow">¶</a></p>
<p id="appendix-B-6">For AEAD_AES_128_CCM, the total number of block cipher operations is the sum
of: the length of the associated data in blocks, the length of the ciphertext in blocks, and the length of the plaintext in blocks, plus 1. In this analysis,
this is simplified to a value of twice the maximum length of a record in blocks
(that is, <code>2l = 2^11</code>). This simplification is based on the associated data
being limited to one block.<a href="#appendix-B-6" class="pilcrow">¶</a></p>
<div id="ccm-confidentiality">
<section id="appendix-B.1">
        <h3 id="name-confidentiality-limits">
<a href="#appendix-B.1" class="section-number selfRef">B.1. </a><a href="#name-confidentiality-limits" class="section-name selfRef">Confidentiality Limits</a>
        </h3>
<p id="appendix-B.1-1">For confidentiality, Theorem 2 in <span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> establishes that an attacker
gains a distinguishing advantage over an ideal pseudorandom permutation (PRP) of
no more than:<a href="#appendix-B.1-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-B.1-2">
<pre>
(2l * q)^2 / 2^n
</pre><a href="#appendix-B.1-2" class="pilcrow">¶</a>
</div>
<p id="appendix-B.1-3">For a target advantage in a single-key setting of 2^-60, which matches that used by TLS 1.3, as summarized in <span>[<a href="#AEAD-LIMITS" class="xref">AEAD-LIMITS</a>]</span>, this results in the relation:<a href="#appendix-B.1-3" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-B.1-4">
<pre>
q &lt;= 2^23
</pre><a href="#appendix-B.1-4" class="pilcrow">¶</a>
</div>
<p id="appendix-B.1-5">That is, endpoints cannot protect more than 2^23 packets with the same set of
keys without causing an attacker to gain a larger advantage than the target of
2^-60.<a href="#appendix-B.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ccm-integrity">
<section id="appendix-B.2">
        <h3 id="name-integrity-limits">
<a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-integrity-limits" class="section-name selfRef">Integrity Limits</a>
        </h3>
<p id="appendix-B.2-1">For integrity, Theorem 1 in <span>[<a href="#CCM-ANALYSIS" class="xref">CCM-ANALYSIS</a>]</span> establishes that an attacker
gains an advantage over an ideal PRP of no more than:<a href="#appendix-B.2-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-B.2-2">
<pre>
v / 2^t + (2l * (v + q))^2 / 2^n
</pre><a href="#appendix-B.2-2" class="pilcrow">¶</a>
</div>
<p id="appendix-B.2-3">The goal is to limit this advantage to 2^-57, to match the target in
TLS 1.3, as summarized in <span>[<a href="#AEAD-LIMITS" class="xref">AEAD-LIMITS</a>]</span>. As <code>t</code> and <code>n</code> are both 128, the first term is negligible relative
to the second, so that term can be removed without a significant effect on the
result. This produces the relation:<a href="#appendix-B.2-3" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-B.2-4">
<pre>
v + q &lt;= 2^24.5
</pre><a href="#appendix-B.2-4" class="pilcrow">¶</a>
</div>
<p id="appendix-B.2-5">Using the previously established value of 2^23 for <code>q</code> and rounding, this leads
to an upper limit on <code>v</code> of 2^23.5. That is, endpoints cannot attempt to
authenticate more than 2^23.5 packets with the same set of keys without causing
an attacker to gain a larger advantage than the target of 2^-57.<a href="#appendix-B.2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ccm-short">
<section id="appendix-B.3">
        <h3 id="name-limits-for-aead_aes_128_ccm">
<a href="#appendix-B.3" class="section-number selfRef">B.3. </a><a href="#name-limits-for-aead_aes_128_ccm" class="section-name selfRef">Limits for AEAD_AES_128_CCM_8</a>
        </h3>
<p id="appendix-B.3-1">The TLS_AES_128_CCM_8_SHA256 cipher suite uses the AEAD_AES_128_CCM_8 function,
which uses a short authentication tag (that is, t=64).<a href="#appendix-B.3-1" class="pilcrow">¶</a></p>
<p id="appendix-B.3-2">The confidentiality limits of AEAD_AES_128_CCM_8 are the same as those for
AEAD_AES_128_CCM, as this does not depend on the tag length; see
<a href="#ccm-confidentiality" class="xref">Appendix B.1</a>.<a href="#appendix-B.3-2" class="pilcrow">¶</a></p>
<p id="appendix-B.3-3">The shorter tag length of 64 bits means that the simplification used in
<a href="#ccm-integrity" class="xref">Appendix B.2</a> does not apply to AEAD_AES_128_CCM_8. If the goal is to
preserve the same margins as other cipher suites, then the limit on forgeries
is largely dictated by the first term of the advantage formula:<a href="#appendix-B.3-3" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="appendix-B.3-4">
<pre>
v &lt;= 2^7
</pre><a href="#appendix-B.3-4" class="pilcrow">¶</a>
</div>
<p id="appendix-B.3-5">As this represents attempts that fail authentication, applying this limit might
be feasible in some environments. However, applying this limit in an
implementation intended for general use exposes connections to an inexpensive
denial-of-service attack.<a href="#appendix-B.3-5" class="pilcrow">¶</a></p>
<p id="appendix-B.3-6">This analysis supports the view that TLS_AES_128_CCM_8_SHA256 is not suitable
for general use. Specifically, TLS_AES_128_CCM_8_SHA256 cannot be used without
additional measures to prevent forgery of records, or to mitigate the effect of
forgeries. This might require understanding the constraints that exist in a
particular deployment or application. For instance, it might be possible to set
a different target for the advantage an attacker gains based on an
understanding of the constraints imposed on a specific usage of DTLS.<a href="#appendix-B.3-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="implementation-pitfalls">
<section id="appendix-C">
      <h2 id="name-implementation-pitfalls">
<a href="#appendix-C" class="section-number selfRef">Appendix C. </a><a href="#name-implementation-pitfalls" class="section-name selfRef">Implementation Pitfalls</a>
      </h2>
<p id="appendix-C-1">In addition to the aspects of TLS that have been a source of interoperability
and security problems (<span><a href="https://www.rfc-editor.org/rfc/rfc8446#appendix-C.3" class="relref">Appendix C.3</a> of [<a href="#RFC8446" class="xref">TLS13</a>]</span>), DTLS presents a few new
potential sources of issues, noted here.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-C-2.1">Do you correctly handle messages received from multiple epochs during a key
transition?  This includes locating the correct key as well as performing
replay detection, if enabled.<a href="#appendix-C-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.2">Do you retransmit handshake messages that are not (implicitly or explicitly)
acknowledged (<a href="#timeout-retransmissions" class="xref">Section 5.8</a>)?<a href="#appendix-C-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.3">Do you correctly handle handshake message fragments received, including
when they are out of order?<a href="#appendix-C-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.4">Do you correctly handle handshake messages received out of order?
This may include either buffering or discarding them.<a href="#appendix-C-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.5">Do you limit how much data you send to a peer before its address is
validated?<a href="#appendix-C-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-C-2.6">Do you verify that the explicit record length is contained within the
datagram in which it is contained?<a href="#appendix-C-2.6" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="contributors">
<section id="appendix-D">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="appendix-D-1">Many people have contributed to previous DTLS versions, and they are acknowledged
in prior versions of DTLS specifications or in the referenced specifications.<a href="#appendix-D-1" class="pilcrow">¶</a></p>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Hanno Becker</span></div>
<div dir="auto" class="left"><span class="org">Arm Limited</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:Hanno.Becker@arm.com" class="email">Hanno.Becker@arm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">David Benjamin</span></div>
<div dir="auto" class="left"><span class="org">Google</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:davidben@google.com" class="email">davidben@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Thomas Fossati</span></div>
<div dir="auto" class="left"><span class="org">Arm Limited</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:thomas.fossati@arm.com" class="email">thomas.fossati@arm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tobias Gondrom</span></div>
<div dir="auto" class="left"><span class="org">Huawei</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tobias.gondrom@gondrom.org" class="email">tobias.gondrom@gondrom.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Felix Günther</span></div>
<div dir="auto" class="left"><span class="org">ETH Zurich</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mail@felixguenther.info" class="email">mail@felixguenther.info</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Benjamin Kaduk</span></div>
<div dir="auto" class="left"><span class="org">Akamai Technologies</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kaduk@mit.edu" class="email">kaduk@mit.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ilari Liusvaara</span></div>
<div dir="auto" class="left"><span class="org">Independent</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ilariliusvaara@welho.com" class="email">ilariliusvaara@welho.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Martin Thomson</span></div>
<div dir="auto" class="left"><span class="org">Mozilla</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:martin.thomson@gmail.com" class="email">martin.thomson@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christopher A. Wood</span></div>
<div dir="auto" class="left"><span class="org">Cloudflare</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:caw@heapingbits.net" class="email">caw@heapingbits.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Yin Xinxing</span></div>
<div dir="auto" class="left"><span class="org">Huawei</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:yinxinxing@huawei.com" class="email">yinxinxing@huawei.com</a>
</div>
</address>
<p id="appendix-D-2"> The
sequence number encryption concept is taken from QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span>. We would
like to thank the authors of RFC 9000 for their work. <span class="contact-name">Felix Günther</span> and <span class="contact-name">Martin  Thomson</span> contributed the analysis in <a href="#ccm-bounds" class="xref">Appendix B</a>.
      We would like to thank <span class="contact-name">Jonathan Hammell</span>, <span class="contact-name">Bernard Aboba</span>, and <span class="contact-name">Andy Cunningham</span> for their review comments.<a href="#appendix-D-2" class="pilcrow">¶</a></p>
<p id="appendix-D-3">Additionally, we would like to thank the IESG members for their review comments: <span class="contact-name">Martin Duke</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Francesca Palombini</span>, <span class="contact-name">Lars Eggert</span>, <span class="contact-name">Zaheduzzaman Sarker</span>, <span class="contact-name">John Scudder</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Robert Wilton</span>, <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Murray Kucherawy</span>, <span class="contact-name">Martin Vigoureux</span>, and <span class="contact-name">Alvaro Retana</span>.<a href="#appendix-D-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-E">
      <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">Eric Rescorla</span></div>
<div dir="auto" class="left"><span class="org">Mozilla</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ekr@rtfm.com" class="email">ekr@rtfm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Hannes Tschofenig</span></div>
<div dir="auto" class="left"><span class="org">Arm Limited</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:hannes.tschofenig@arm.com" class="email">hannes.tschofenig@arm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Nagendra Modadugu</span></div>
<div dir="auto" class="left"><span class="org">Google, Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:nagendra@cs.stanford.edu" class="email">nagendra@cs.stanford.edu</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>