File: rfc9230.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 (2455 lines) | stat: -rw-r--r-- 109,824 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 9230: Oblivious DNS over HTTPS</title>
<meta content="Eric Kinnear" name="author">
<meta content="Patrick McManus" name="author">
<meta content="Tommy Pauly" name="author">
<meta content="Tanya Verma" name="author">
<meta content="Christopher A. Wood" name="author">
<meta content="
       This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers
via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of
DNS operations by not allowing any one server entity to be aware of both the client IP
address and the content of DNS queries and answers. 
       This experimental protocol has been developed outside the IETF and is published here to
guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation. 
    " name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="Privacy" name="keyword">
<meta content="DNS Privacy" name="keyword">
<meta content="DoH" name="keyword">
<meta content="ODoH" name="keyword">
<meta content="HPKE" name="keyword">
<meta content="9230" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.10
    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.7.1
    MarkupSafe 2.0.1
    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="rfc9230.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;
  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;
  }
  pre.breakable {
    break-inside: auto;
  }
  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/rfc9230" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-pauly-dprive-oblivious-doh-11" 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 9230</td>
<td class="center">Oblivious DoH</td>
<td class="right">June 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Kinnear, et al.</td>
<td class="center">Experimental</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9230" class="eref">9230</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-06" class="published">June 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. Kinnear</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">P. McManus</div>
<div class="org">Fastly</div>
</div>
<div class="author">
      <div class="author-name">T. Pauly</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">T. Verma</div>
<div class="org">Cloudflare</div>
</div>
<div class="author">
      <div class="author-name">C.A. Wood</div>
<div class="org">Cloudflare</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9230</h1>
<h1 id="title">Oblivious DNS over HTTPS</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers
via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of
DNS operations by not allowing any one server entity to be aware of both the client IP
address and the content of DNS queries and answers.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This experimental protocol has been developed outside the IETF and is published here to
guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  This is a contribution to the RFC Series,
            independently of any other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for publication
            by the RFC Editor are not candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9230">https://www.rfc-editor.org/info/rfc9230</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.<a href="#section-boilerplate.2-2" 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>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-specification-of-requiremen" class="xref">Specification of Requirements</a></p>
</li>
            </ul>
</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-terminology" class="xref">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-deployment-requirements" class="xref">Deployment Requirements</a></p>
</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-http-exchange" class="xref">HTTP Exchange</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-http-request" class="xref">HTTP Request</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-http-request-example" class="xref">HTTP Request Example</a></p>
</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-http-response" class="xref">HTTP Response</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-http-response-example" class="xref">HTTP Response Example</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-http-metadata" class="xref">HTTP Metadata</a></p>
</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-configuration-and-public-ke" class="xref">Configuration and Public Key Format</a></p>
</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-protocol-encoding" class="xref">Protocol Encoding</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-message-format" class="xref">Message Format</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-encryption-and-decryption-r" class="xref">Encryption and Decryption Routines</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-oblivious-client-behavior" class="xref">Oblivious Client Behavior</a></p>
</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-oblivious-target-behavior" class="xref">Oblivious Target Behavior</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-compliance-requirements" class="xref">Compliance Requirements</a></p>
</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-experiment-overview" class="xref">Experiment Overview</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>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-denial-of-service" class="xref">Denial of Service</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-proxy-policies" class="xref">Proxy Policies</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="xref">11.3</a>.  <a href="#name-authentication" class="xref">Authentication</a></p>
</li>
            </ul>
</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-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-oblivious-doh-message-media" class="xref">Oblivious DoH Message Media Type</a></p>
</li>
            </ul>
</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-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.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.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.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.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-use-of-generic-proxy-servic" class="xref">Use of Generic Proxy Services</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="#appendix-B" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-C" 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">DNS over HTTPS (DoH) <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span> defines a mechanism to allow DNS messages to be
transmitted in HTTP messages protected with TLS. This provides improved confidentiality
and authentication for DNS interactions in various circumstances.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">While DoH can prevent eavesdroppers from directly reading the contents of DNS exchanges,
clients cannot send DNS queries to and receive answers from servers without revealing
their local IP address (and thus information about the identity or location of the client)
to the server.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Proposals such as Oblivious DNS <span>[<a href="#I-D.annee-dprive-oblivious-dns" class="xref">OBLIVIOUS-DNS</a>]</span> increase privacy
by ensuring that no single DNS server is aware of both the client IP address and the message
contents.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">This document defines Oblivious DoH, an experimental protocol built on DoH that permits proxied
resolution, in which DNS messages are encrypted so that no server can independently read
both the client IP address and the DNS message contents.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">As with DoH, DNS messages exchanged over Oblivious DoH are fully formed DNS messages.
Clients that want to receive answers that are relevant to the network they are on without
revealing their exact IP address can thus use the EDNS0 Client Subnet option (<span>[<a href="#RFC7871" class="xref">RFC7871</a>], <a href="https://www.rfc-editor.org/rfc/rfc7871#section-7.1.2" class="relref">Section 7.1.2</a></span>)
to provide a hint to the resolver using Oblivious DoH.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This mechanism is intended to be used as one mechanism for resolving privacy-sensitive
content in the broader context of DNS privacy.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">This experimental protocol has been developed outside the IETF and is published here to
guide implementation, ensure interoperability among implementations, and enable
wide-scale experimentation. See <a href="#experiment" class="xref">Section 10</a> for more details about the experiment.<a href="#section-1-7" class="pilcrow">¶</a></p>
<div id="specification-of-requirements">
<section id="section-1.1">
        <h3 id="name-specification-of-requiremen">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-specification-of-requiremen" class="section-name selfRef">Specification of Requirements</a>
        </h3>
<p id="section-1.1-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
       "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>",
       "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>",
       "<span class="bcp14">SHOULD NOT</span>",
       "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
       "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
       are to be interpreted as described in BCP 14
       <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only
       when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="terminology">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">This document defines the following terms:<a href="#section-2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-2">
        <dt id="section-2-2.1">
Oblivious Client:  </dt>
        <dd style="margin-left: 1.5em" id="section-2-2.2">
          <p id="section-2-2.2.1">A client that sends DNS queries to an Oblivious Target, through an Oblivious Proxy. The Client is responsible for selecting the combination of Proxy and Target to use for a given query.<a href="#section-2-2.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.3">
Oblivious Proxy:  </dt>
        <dd style="margin-left: 1.5em" id="section-2-2.4">
          <p id="section-2-2.4.1">An HTTP server that proxies encrypted DNS queries and responses between an Oblivious Client and an
Oblivious Target and is identified by a URI Template <span>[<a href="#RFC6570" class="xref">RFC6570</a>]</span> (see <a href="#oblivious-request" class="xref">Section 4.1</a>).
Note that this Oblivious Proxy is not acting as a full HTTP proxy but is instead a specialized
server used to forward Oblivious DNS messages.<a href="#section-2-2.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.5">
Oblivious Target:  </dt>
        <dd style="margin-left: 1.5em" id="section-2-2.6">
          <p id="section-2-2.6.1">An HTTP server that receives and decrypts encrypted Oblivious Client DNS queries from an Oblivious Proxy
and returns encrypted DNS responses via that same Proxy. In order to provide DNS responses, the Target
can be a DNS resolver, be co-located with a resolver, or forward to a resolver.<a href="#section-2-2.6.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-3">Throughout the rest of this document, we use the terms "Client", "Proxy", and "Target" to refer to an Oblivious Client, 
Oblivious Proxy, and Oblivious Target, respectively.<a href="#section-2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="deployment-requirements">
<section id="section-3">
      <h2 id="name-deployment-requirements">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-deployment-requirements" class="section-name selfRef">Deployment Requirements</a>
      </h2>
<p id="section-3-1">Oblivious DoH requires, at a minimum:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">An Oblivious Proxy server, identified by a URI Template.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.2">An Oblivious Target server. The Target and Proxy are expected to be non-colluding (see 
<a href="#security-considerations" class="xref">Section 11</a>).<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-2.3">One or more Target public keys for encrypting DNS queries sent to a Target via a Proxy
(<a href="#publickey" class="xref">Section 5</a>). These keys guarantee that only the intended Target can decrypt Client queries.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">The mechanism for discovering and provisioning the Proxy URI Template and Target public keys
is out of scope for this document.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="http-exchange">
<section id="section-4">
      <h2 id="name-http-exchange">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-http-exchange" class="section-name selfRef">HTTP Exchange</a>
      </h2>
<p id="section-4-1">Unlike direct resolution, oblivious hostname resolution over DoH involves three parties:<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 Client, which generates queries.<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.2">The Proxy, which receives encrypted queries from the Client and passes them on to a Target.<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-2.3">The Target, which receives proxied queries from the Client via the Proxy and produces proxied
answers.<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
      </ol>
<span id="name-oblivious-doh-exchange"></span><div id="fig-doh-exchange">
<figure id="figure-1">
        <div class="alignLeft art-text artwork" id="section-4-3.1">
<pre>
     --- [ Request encrypted with Target public key ] --&gt;
+---------+             +-----------+             +-----------+
| Client  +-------------&gt; Oblivious +-------------&gt; Oblivious |
|         &lt;-------------+   Proxy   &lt;-------------+  Target   |
+---------+             +-----------+             +-----------+
    &lt;-- [   Response encrypted with symmetric key   ] ---
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-oblivious-doh-exchange" class="selfRef">Oblivious DoH Exchange</a>
        </figcaption></figure>
</div>
<div id="oblivious-request">
<section id="section-4.1">
        <h3 id="name-http-request">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-http-request" class="section-name selfRef">HTTP Request</a>
        </h3>
<p id="section-4.1-1">Oblivious DoH queries are created by the Client and are sent to the Proxy as HTTP
requests using the POST method. Clients are configured with a Proxy URI Template
<span>[<a href="#RFC6570" class="xref">RFC6570</a>]</span> and the Target URI. The scheme for both the Proxy URI Template and
the Target URI <span class="bcp14">MUST</span> be "https". The Proxy URI Template uses the Level 3 encoding
defined in
<span><a href="https://www.rfc-editor.org/rfc/rfc6570#section-1.2" class="relref">Section 1.2</a> of [<a href="#RFC6570" class="xref">RFC6570</a>]</span> and contains two variables: "targethost",
which indicates the hostname of the Target server; and "targetpath",
which indicates the path on which the Target is accessible. Examples of
Proxy URI Templates are shown below:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.1-2">
<pre>
https://dnsproxy.example/dns-query{?targethost,targetpath}
https://dnsproxy.example/{targethost}/{targetpath}
</pre><a href="#section-4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-4.1-3">The URI Template <span class="bcp14">MUST</span> contain both the "targethost" and "targetpath" variables exactly
once and <span class="bcp14">MUST NOT</span> contain any other variables. The variables <span class="bcp14">MUST</span> be within the path
or query components of the URI. Clients <span class="bcp14">MUST</span> ignore configurations that do not conform
to this template. See <a href="#request-example" class="xref">Section 4.2</a> for an example request.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">Oblivious DoH messages have no cache value, since both requests and responses are
encrypted using ephemeral key material. Requests and responses <span class="bcp14">MUST NOT</span> be cached.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">Clients <span class="bcp14">MUST</span> set the HTTP Content-Type header to "application/oblivious-dns-message"
to indicate that this request is an Oblivious DoH query intended for proxying. Clients
also <span class="bcp14">SHOULD</span> set this same value for the HTTP Accept header.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">A correctly encoded request has the HTTP Content-Type header "application/oblivious-dns-message",
uses the HTTP POST method, and contains "targethost" and "targetpath" variables. If the Proxy
fails to match the "targethost" and "targetpath" variables from the path, it <span class="bcp14">MUST</span> treat the
request as malformed. The Proxy constructs the URI of the Target with the "https" scheme, 
using the value of "targethost" as the URI host and the percent-decoded value of "targetpath" as the
URI path. Proxies <span class="bcp14">MUST</span> check that Client requests are correctly encoded and <span class="bcp14">MUST</span> return a
4xx (Client Error) if the check fails, along with the Proxy-Status response header
with an "error" parameter of type "http_request_error" <span>[<a href="#RFC9209" class="xref">RFC9209</a>]</span>.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">Proxies <span class="bcp14">MAY</span> choose to not forward connections to non-standard ports. In such cases, Proxies
can indicate the error with a 403 response status code, along with a Proxy-Status response
header with an "error" parameter of type "http_request_denied" and with an appropriate
explanation in "details".<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">If the Proxy cannot establish a connection to the Target, it can indicate the error with a 
502 response status code, along with a Proxy-Status response header with an "error" parameter
whose type indicates the reason. For example, if DNS resolution fails, the error type might be
"dns_timeout", whereas if the TLS connection fails, the error type might be "tls_protocol_error".<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">Upon receipt of requests from a Proxy, Targets <span class="bcp14">MUST</span> validate that the request has the HTTP
Content-Type header "application/oblivious-dns-message" and uses the HTTP POST method.
Targets can respond with a 4xx response status code if this check fails.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request-example">
<section id="section-4.2">
        <h3 id="name-http-request-example">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-http-request-example" class="section-name selfRef">HTTP Request Example</a>
        </h3>
<p id="section-4.2-1">The following example shows how a Client requests that a Proxy, "dnsproxy.example",
forward an encrypted message to "dnstarget.example". The URI Template for the
Proxy is "https://dnsproxy.example/dns-query{?targethost,targetpath}". The URI for
the Target is "https://dnstarget.example/dns-query".<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<div id="section-4.2-2">
<pre class="lang-http-message sourcecode">
:method = POST
:scheme = https
:authority = dnsproxy.example
:path = /dns-query?targethost=dnstarget.example&amp;targetpath=/dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106

&lt;Bytes containing an encrypted Oblivious DNS query&gt;
</pre><a href="#section-4.2-2" class="pilcrow">¶</a>
</div>
<p id="section-4.2-3">The Proxy then sends the following request on to the Target:<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<div id="section-4.2-4">
<pre class="lang-http-message sourcecode">
:method = POST
:scheme = https
:authority = dnstarget.example
:path = /dns-query
accept = application/oblivious-dns-message
content-type = application/oblivious-dns-message
content-length = 106

&lt;Bytes containing an encrypted Oblivious DNS query&gt;
</pre><a href="#section-4.2-4" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="oblivious-response">
<section id="section-4.3">
        <h3 id="name-http-response">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-http-response" class="section-name selfRef">HTTP Response</a>
        </h3>
<p id="section-4.3-1">The response to an Oblivious DoH query is generated by the Target. It <span class="bcp14">MUST</span> set the
Content-Type HTTP header to "application/oblivious-dns-message" for all successful responses.
The body of the response contains an encrypted DNS message; see <a href="#encryption" class="xref">Section 6</a>.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">The response from a Target <span class="bcp14">MUST</span> set the Content-Type HTTP header to "application/oblivious-dns-message", and that same type
<span class="bcp14">MUST</span> be used on all successful responses sent by the Proxy to the Client. A Client <span class="bcp14">MUST</span> only consider a response that contains the
Content-Type header before processing the payload. A response without the appropriate header <span class="bcp14">MUST</span> be
treated as an error and be handled appropriately. All other aspects of the HTTP response and error handling are
inherited from standard DoH.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">Proxies forward responses from the Target to the Client, without any modifications to the body or status code.
The Proxy also <span class="bcp14">SHOULD</span> add a Proxy-Status response header with a "received-status" parameter indicating
that the status code was generated by the Target.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4">Note that if a Client receives a 3xx status code and chooses to follow a redirect, the subsequent request
<span class="bcp14">MUST</span> also be performed through a Proxy in order to avoid directly exposing requests to the Target.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">Requests that cannot be processed by the Target result in 4xx (Client Error) responses. If the Target
and Client keys do not match, it is an authorization failure (HTTP status code 401; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-15.5.2" class="relref">Section 15.5.2</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>). Otherwise, if the Client's request is invalid, such as in the case of decryption
failure, wrong message type, or deserialization failure, this is a bad request (HTTP status code 400; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-15.5.1" class="relref">Section 15.5.1</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>).<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">Even in the case of DNS responses indicating failure, such as SERVFAIL or NXDOMAIN, a successful HTTP response
with a 2xx status code is used as long as the DNS response is valid. This is identical to how DoH <span>[<a href="#RFC8484" class="xref">RFC8484</a>]</span>
handles HTTP response codes.<a href="#section-4.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="http-response-example">
<section id="section-4.4">
        <h3 id="name-http-response-example">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-http-response-example" class="section-name selfRef">HTTP Response Example</a>
        </h3>
<p id="section-4.4-1">The following example shows a 2xx (Successful) response that can be sent from a Target to
a Client via a Proxy.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<div id="section-4.4-2">
<pre class="lang-http-message sourcecode">
:status = 200
content-type = application/oblivious-dns-message
content-length = 154

&lt;Bytes containing an encrypted Oblivious DNS response&gt;
</pre><a href="#section-4.4-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="http-metadata">
<section id="section-4.5">
        <h3 id="name-http-metadata">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-http-metadata" class="section-name selfRef">HTTP Metadata</a>
        </h3>
<p id="section-4.5-1">Proxies forward requests and responses between Clients and Targets as specified in <a href="#oblivious-request" class="xref">Section 4.1</a>.
Metadata sent with these messages could inadvertently weaken or remove Oblivious DoH privacy properties.
Proxies <span class="bcp14">MUST NOT</span> send any Client-identifying information about Clients to Targets, such as
"Forwarded" HTTP headers <span>[<a href="#RFC7239" class="xref">RFC7239</a>]</span>. Additionally, Clients <span class="bcp14">MUST NOT</span> include any private state in
requests to Proxies, such as HTTP cookies. See <a href="#authentication" class="xref">Section 11.3</a> for related discussion about
Client authentication information.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="publickey">
<section id="section-5">
      <h2 id="name-configuration-and-public-ke">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-configuration-and-public-ke" class="section-name selfRef">Configuration and Public Key Format</a>
      </h2>
<p id="section-5-1">In order to send a message to a Target, the Client needs to know a public key to use
for encrypting its queries. The mechanism for discovering this configuration is
out of scope for this document.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Servers ought to rotate public keys regularly. It is <span class="bcp14">RECOMMENDED</span> that servers rotate keys
every day. Shorter rotation windows reduce the anonymity set of Clients that might use
the public key, whereas longer rotation windows widen the time frame of possible compromise.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">An Oblivious DNS public key configuration is a structure encoded, using TLS-style
encoding <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>, as follows:<a href="#section-5-3" class="pilcrow">¶</a></p>
<div id="section-5-4">
<pre class="lang-tls-presentation sourcecode">
struct {
   uint16 kem_id;
   uint16 kdf_id;
   uint16 aead_id;
   opaque public_key&lt;1..2^16-1&gt;;
} ObliviousDoHConfigContents;

struct {
   uint16 version;
   uint16 length;
   select (ObliviousDoHConfig.version) {
      case 0x0001: ObliviousDoHConfigContents contents;
   }
} ObliviousDoHConfig;

ObliviousDoHConfig ObliviousDoHConfigs&lt;1..2^16-1&gt;;
</pre><a href="#section-5-4" class="pilcrow">¶</a>
</div>
<p id="section-5-5">The <code>ObliviousDoHConfigs</code> structure contains one or more <code>ObliviousDoHConfig</code> structures in decreasing order of
preference. This allows a server to support multiple versions of Oblivious DoH and multiple sets of Oblivious DoH
parameters.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">An <code>ObliviousDoHConfig</code> structure contains a versioned representation of an Oblivious DoH configuration,
with the following fields.<a href="#section-5-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5-7">
        <dt id="section-5-7.1">
version:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-7.2">
          <p id="section-5-7.2.1">The version of Oblivious DoH for which this configuration is used. Clients <span class="bcp14">MUST</span> ignore any
<code>ObliviousDoHConfig</code> structure with a version they do not support. The version of Oblivious DoH
specified in this document is <code>0x0001</code>.<a href="#section-5-7.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-7.3">
length:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-7.4">
          <p id="section-5-7.4.1">The length, in bytes, of the next field.<a href="#section-5-7.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-7.5">
contents:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-7.6">
          <p id="section-5-7.6.1">An opaque byte string whose contents depend on the version. For this
specification, the contents are an <code>ObliviousDoHConfigContents</code> structure.<a href="#section-5-7.6.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-8">An <code>ObliviousDoHConfigContents</code> structure contains the information needed to encrypt a message under
<code>ObliviousDoHConfigContents.public_key</code> such that only the owner of the corresponding private
key can decrypt the message. The values for <code>ObliviousDoHConfigContents.kem_id</code>,
<code>ObliviousDoHConfigContents.kdf_id</code>, and <code>ObliviousDoHConfigContents.aead_id</code>
are described in <span><a href="https://www.rfc-editor.org/rfc/rfc9180#section-7" class="relref">Section 7</a> of [<a href="#RFC9180" class="xref">HPKE</a>]</span>. The fields in this structure
are as follows:<a href="#section-5-8" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5-9">
        <dt id="section-5-9.1">
kem_id:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-9.2">
          <p id="section-5-9.2.1">The hybrid public key encryption (HPKE) key encapsulation mechanism (KEM) identifier corresponding to <code>public_key</code>. Clients <span class="bcp14">MUST</span> ignore any
<code>ObliviousDoHConfig</code> structure with a key using a KEM they do not support.<a href="#section-5-9.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-9.3">
kdf_id:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-9.4">
          <p id="section-5-9.4.1">The HPKE key derivation function (KDF) identifier corresponding to <code>public_key</code>. Clients <span class="bcp14">MUST</span> ignore any
<code>ObliviousDoHConfig</code> structure with a key using a KDF they do not support.<a href="#section-5-9.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-9.5">
aead_id:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-9.6">
          <p id="section-5-9.6.1">The HPKE authenticated encryption with associated data (AEAD) identifier corresponding to <code>public_key</code>. Clients <span class="bcp14">MUST</span> ignore any
<code>ObliviousDoHConfig</code> structure with a key using an AEAD they do not support.<a href="#section-5-9.6.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-5-9.7">
public_key:  </dt>
        <dd style="margin-left: 1.5em" id="section-5-9.8">
          <p id="section-5-9.8.1">The HPKE public key used by the Client to encrypt Oblivious DoH queries.<a href="#section-5-9.8.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="encryption">
<section id="section-6">
      <h2 id="name-protocol-encoding">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-protocol-encoding" class="section-name selfRef">Protocol Encoding</a>
      </h2>
<p id="section-6-1">This section includes encoding and wire format details for Oblivious DoH, as well
as routines for encrypting and decrypting encoded values.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div id="encoding">
<section id="section-6.1">
        <h3 id="name-message-format">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-message-format" class="section-name selfRef">Message Format</a>
        </h3>
<p id="section-6.1-1">There are two types of Oblivious DoH messages: Queries (0x01) and Responses (0x02).
Both messages carry the following information:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-6.1-2">
<li id="section-6.1-2.1">A DNS message, which is either a Query or Response, depending on context.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-6.1-2.2">Padding of arbitrary length, which <span class="bcp14">MUST</span> contain all zeros.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-6.1-3">They are encoded using the following structure:<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<div id="section-6.1-4">
<pre class="lang-tls-presentation sourcecode">
struct {
   opaque dns_message&lt;1..2^16-1&gt;;
   opaque padding&lt;0..2^16-1&gt;;
} ObliviousDoHMessagePlaintext;
</pre><a href="#section-6.1-4" class="pilcrow">¶</a>
</div>
<p id="section-6.1-5">Both Query and Response messages use the <code>ObliviousDoHMessagePlaintext</code> format.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<div id="section-6.1-6">
<pre class="lang-tls-presentation sourcecode">
ObliviousDoHMessagePlaintext ObliviousDoHQuery;
ObliviousDoHMessagePlaintext ObliviousDoHResponse;
</pre><a href="#section-6.1-6" class="pilcrow">¶</a>
</div>
<p id="section-6.1-7">An encrypted <code>ObliviousDoHMessagePlaintext</code> parameter is carried in an <code>ObliviousDoHMessage</code>
message, encoded as follows:<a href="#section-6.1-7" class="pilcrow">¶</a></p>
<div id="section-6.1-8">
<pre class="lang-tls-presentation sourcecode">
struct {
   uint8  message_type;
   opaque key_id&lt;0..2^16-1&gt;;
   opaque encrypted_message&lt;1..2^16-1&gt;;
} ObliviousDoHMessage;
</pre><a href="#section-6.1-8" class="pilcrow">¶</a>
</div>
<p id="section-6.1-9">The <code>ObliviousDoHMessage</code> structure contains the following fields:<a href="#section-6.1-9" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-6.1-10">
          <dt id="section-6.1-10.1">
message_type:  </dt>
          <dd style="margin-left: 1.5em" id="section-6.1-10.2">
            <p id="section-6.1-10.2.1">A one-byte identifier for the type of message. Query messages use <code>message_type</code> 0x01, and Response
messages use <code>message_type</code> 0x02.<a href="#section-6.1-10.2.1" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-6.1-10.3">
key_id:  </dt>
          <dd style="margin-left: 1.5em" id="section-6.1-10.4">
            <p id="section-6.1-10.4.1">The identifier of the corresponding <code>ObliviousDoHConfigContents</code> key. This is computed as
<code>Expand(Extract("", config), "odoh key id", Nh)</code>, where <code>config</code> is the <code>ObliviousDoHConfigContents</code> structure
and <code>Extract</code>, <code>Expand</code>, and <code>Nh</code> are as specified by the HPKE cipher suite KDF corresponding to
<code>config.kdf_id</code>.<a href="#section-6.1-10.4.1" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-6.1-10.5">
encrypted_message:  </dt>
          <dd style="margin-left: 1.5em" id="section-6.1-10.6">
            <p id="section-6.1-10.6.1">An encrypted message for the Oblivious Target (for Query messages) or Client (for Response messages).
Implementations <span class="bcp14">MAY</span> enforce limits on the size of this field, depending on the size of plaintext DNS
messages. (DNS queries, for example, will not reach the size limit of 2^16-1 in practice.)<a href="#section-6.1-10.6.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-6.1-11">The contents of <code>ObliviousDoHMessage.encrypted_message</code> depend on <code>ObliviousDoHMessage.message_type</code>.
In particular, <code>ObliviousDoHMessage.encrypted_message</code> is an encryption of an <code>ObliviousDoHQuery</code> message
if the message is a Query and an encryption of <code>ObliviousDoHResponse</code> if the message is a Response.<a href="#section-6.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="encryption-and-decryption-routines">
<section id="section-6.2">
        <h3 id="name-encryption-and-decryption-r">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-encryption-and-decryption-r" class="section-name selfRef">Encryption and Decryption Routines</a>
        </h3>
<p id="section-6.2-1">Clients use the following utility functions for encrypting a Query and decrypting
a Response as described in <a href="#odoh-Client" class="xref">Section 7</a>.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">encrypt_query_body: Encrypt an Oblivious DoH query.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-3">
<pre class="lang-pseudocode sourcecode">
def encrypt_query_body(pkR, key_id, Q_plain):
  enc, context = SetupBaseS(pkR, "odoh query")
  aad = 0x01 || len(key_id) || key_id
  ct = context.Seal(aad, Q_plain)
  Q_encrypted = enc || ct
  return Q_encrypted
</pre><a href="#section-6.2-3" class="pilcrow">¶</a>
</div>
<ul class="normal">
<li class="normal" id="section-6.2-4.1">decrypt_response_body: Decrypt an Oblivious DoH response.<a href="#section-6.2-4.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-5">
<pre class="lang-pseudocode sourcecode">
def decrypt_response_body(context, Q_plain, R_encrypted, resp_nonce):
  aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)
  aad = 0x02 || len(resp_nonce) || resp_nonce
  R_plain, error = Open(key, nonce, aad, R_encrypted)
  return R_plain, error
</pre><a href="#section-6.2-5" class="pilcrow">¶</a>
</div>
<p id="section-6.2-6">The <code>derive_secrets</code> function is described below.<a href="#section-6.2-6" class="pilcrow">¶</a></p>
<p id="section-6.2-7">Targets use the following utility functions in processing queries and producing
responses as described in <a href="#odoh-target" class="xref">Section 8</a>.<a href="#section-6.2-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-8.1">setup_query_context: Set up an HPKE context used for decrypting an Oblivious DoH query.<a href="#section-6.2-8.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-9">
<pre class="lang-pseudocode sourcecode">
def setup_query_context(skR, key_id, Q_encrypted):
  enc || ct = Q_encrypted
  context = SetupBaseR(enc, skR, "odoh query")
  return context
</pre><a href="#section-6.2-9" class="pilcrow">¶</a>
</div>
<ul class="normal">
<li class="normal" id="section-6.2-10.1">decrypt_query_body: Decrypt an Oblivious DoH query.<a href="#section-6.2-10.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-11">
<pre class="lang-pseudocode sourcecode">
def decrypt_query_body(context, key_id, Q_encrypted):
  aad = 0x01 || len(key_id) || key_id
  enc || ct = Q_encrypted
  Q_plain, error = context.Open(aad, ct)
  return Q_plain, error
</pre><a href="#section-6.2-11" class="pilcrow">¶</a>
</div>
<ul class="normal">
<li class="normal" id="section-6.2-12.1">derive_secrets: Derive keying material used for encrypting an Oblivious DoH response.<a href="#section-6.2-12.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-13">
<pre class="lang-pseudocode sourcecode">
def derive_secrets(context, Q_plain, resp_nonce):
  secret = context.Export("odoh response", Nk)
  salt = Q_plain || len(resp_nonce) || resp_nonce
  prk = Extract(salt, secret)
  key = Expand(odoh_prk, "odoh key", Nk)
  nonce = Expand(odoh_prk, "odoh nonce", Nn)
  return key, nonce
</pre><a href="#section-6.2-13" class="pilcrow">¶</a>
</div>
<p id="section-6.2-14">The <code>random(N)</code> function returns <code>N</code> cryptographically secure random bytes
from a good source of entropy <span>[<a href="#RFC4086" class="xref">RFC4086</a>]</span>. The <code>max(A, B)</code> function returns
<code>A</code> if <code>A &gt; B</code>, and <code>B</code> otherwise.<a href="#section-6.2-14" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-15.1">encrypt_response_body: Encrypt an Oblivious DoH response.<a href="#section-6.2-15.1" class="pilcrow">¶</a>
</li>
        </ul>
<div id="section-6.2-16">
<pre class="lang-pseudocode sourcecode">
def encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce):
  aad = 0x02 || len(resp_nonce) || resp_nonce
  R_encrypted = Seal(aead_key, aead_nonce, aad, R_plain)
  return R_encrypted
</pre><a href="#section-6.2-16" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</div>
<div id="odoh-Client">
<section id="section-7">
      <h2 id="name-oblivious-client-behavior">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-oblivious-client-behavior" class="section-name selfRef">Oblivious Client Behavior</a>
      </h2>
<p id="section-7-1">Let <code>M</code> be a DNS message (query) a Client wishes to protect with Oblivious DoH.
When sending an Oblivious DoH Query for resolving <code>M</code> to an Oblivious Target with
<code>ObliviousDoHConfigContents</code> <code>config</code>, a Client does the following:<a href="#section-7-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-2">
<li id="section-7-2.1">Creates an <code>ObliviousDoHQuery</code> structure, carrying the message M and padding, to produce Q_plain.<a href="#section-7-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.2">Deserializes <code>config.public_key</code> to produce a public key pkR of type <code>config.kem_id</code>.<a href="#section-7-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.3">Computes the encrypted message as <code>Q_encrypted = encrypt_query_body(pkR, key_id, Q_plain)</code>,
where <code>key_id</code> is as computed in <a href="#encryption" class="xref">Section 6</a>. Note also that <code>len(key_id)</code> outputs the length of <code>key_id</code>
as a two-byte unsigned integer.<a href="#section-7-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-7-2.4">Outputs an <code>ObliviousDoHMessage</code> message <code>Q</code>, where <code>Q.message_type = 0x01</code>, <code>Q.key_id</code> carries <code>key_id</code>,
and <code>Q.encrypted_message = Q_encrypted</code>.<a href="#section-7-2.4" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-7-3">The Client then sends <code>Q</code> to the Proxy according to <a href="#oblivious-request" class="xref">Section 4.1</a>.
Once the Client receives a response <code>R</code>, encrypted as specified in <a href="#odoh-target" class="xref">Section 8</a>,
it uses <code>decrypt_response_body</code> to decrypt <code>R.encrypted_message</code> (using <code>R.key_id</code> as
a nonce) and produce R_plain. Clients <span class="bcp14">MUST</span> validate <code>R_plain.padding</code> (as all zeros)
before using <code>R_plain.dns_message</code>.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="odoh-target">
<section id="section-8">
      <h2 id="name-oblivious-target-behavior">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-oblivious-target-behavior" class="section-name selfRef">Oblivious Target Behavior</a>
      </h2>
<p id="section-8-1">Targets that receive a Query message Q decrypt and process it as follows:<a href="#section-8-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-8-2">
<li id="section-8-2.1">Look up the <code>ObliviousDoHConfigContents</code> information according to <code>Q.key_id</code>. If no such key exists,
the Target <span class="bcp14">MAY</span> discard the query, and if so, it <span class="bcp14">MUST</span> return a 401 (Unauthorized) response
to the Proxy. Otherwise, let <code>skR</code> be the private key corresponding to this public key,
or one chosen for trial decryption.<a href="#section-8-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.2">Compute <code>context = setup_query_context(skR, Q.key_id, Q.encrypted_message)</code>.<a href="#section-8-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.3">Compute <code>Q_plain, error = decrypt_query_body(context, Q.key_id, Q.encrypted_message)</code>.<a href="#section-8-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.4">If no error was returned and <code>Q_plain.padding</code> is valid (all zeros), resolve
<code>Q_plain.dns_message</code> as needed, yielding a DNS message M. Otherwise, if an error
was returned or the padding was invalid, return a 400 (Client Error) response to the Proxy.<a href="#section-8-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.5">Create an <code>ObliviousDoHResponseBody</code> structure, carrying the message <code>M</code> and padding,
to produce <code>R_plain</code>.<a href="#section-8-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.6">Create a fresh nonce <code>resp_nonce = random(max(Nn, Nk))</code>.<a href="#section-8-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.7">Compute <code>aead_key, aead_nonce = derive_secrets(context, Q_plain, resp_nonce)</code>.<a href="#section-8-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.8">Compute <code>R_encrypted = encrypt_response_body(R_plain, aead_key, aead_nonce, resp_nonce)</code>.
The <code>key_id</code> field used for encryption carries <code>resp_nonce</code> in order for Clients to
derive the same secrets. Also, the <code>Seal</code> function is the function that is associated with the
HPKE AEAD.<a href="#section-8-2.8" class="pilcrow">¶</a>
</li>
        <li id="section-8-2.9">Output an <code>ObliviousDoHMessage</code> message <code>R</code>, where <code>R.message_type = 0x02</code>,
<code>R.key_id = resp_nonce</code>, and <code>R.encrypted_message = R_encrypted</code>.<a href="#section-8-2.9" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-8-3">The Target then sends <code>R</code> in a 2xx (Successful) response to the Proxy; see <a href="#oblivious-response" class="xref">Section 4.3</a>.
The Proxy forwards the message <code>R</code> without modification back to the Client as the HTTP response
to the Client's original HTTP request. In the event of an error (non-2xx status code), the
Proxy forwards the Target error to the Client; see <a href="#oblivious-response" class="xref">Section 4.3</a>.<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="compliance">
<section id="section-9">
      <h2 id="name-compliance-requirements">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-compliance-requirements" class="section-name selfRef">Compliance Requirements</a>
      </h2>
<p id="section-9-1">Oblivious DoH uses HPKE for public key encryption <span>[<a href="#RFC9180" class="xref">HPKE</a>]</span>.
In the absence of an application profile standard specifying otherwise, a compliant
Oblivious DoH implementation <span class="bcp14">MUST</span> support the following HPKE cipher suite:<a href="#section-9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9-2">
        <dt id="section-9-2.1">KEM:</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.2">DHKEM(X25519, HKDF-SHA256) (see <span>[<a href="#RFC9180" class="xref">HPKE</a>], <a href="https://www.rfc-editor.org/rfc/rfc9180#section-7.1" class="relref">Section 7.1</a></span>)<a href="#section-9-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.3">KDF:</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.4">HKDF-SHA256 (see <span>[<a href="#RFC9180" class="xref">HPKE</a>], <a href="https://www.rfc-editor.org/rfc/rfc9180#section-7.2" class="relref">Section 7.2</a></span>)<a href="#section-9-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.5">AEAD:</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.6">AES-128-GCM (see <span>[<a href="#RFC9180" class="xref">HPKE</a>], <a href="https://www.rfc-editor.org/rfc/rfc9180#section-7.3" class="relref">Section 7.3</a></span>)<a href="#section-9-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="experiment">
<section id="section-10">
      <h2 id="name-experiment-overview">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-experiment-overview" class="section-name selfRef">Experiment Overview</a>
      </h2>
<p id="section-10-1">This document describes an experimental protocol built on DoH. The purpose of this
experiment is to assess deployment configuration viability and related performance
impacts on DNS resolution by measuring key performance indicators such as resolution
latency. Experiment participants will test various parameters affecting service operation
and performance, including mechanisms for discovery and configuration of DoH Proxies
and Targets, as well as performance implications of connection reuse and pools where
appropriate. The results of this experiment will be used to influence future protocol
design and deployment efforts related to Oblivious DoH, such as Oblivious HTTP
<span>[<a href="#I-D.ietf-ohai-ohttp" class="xref">OHTP</a>]</span>. Implementations of DoH that are not involved in the
experiment will not recognize this protocol and will not participate in the experiment.
It is anticipated that the use of Oblivious DoH will be widespread and that this experiment will be of long duration.<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">Oblivious DoH aims to keep knowledge of the true query origin and its contents known only to Clients.
As a simplified model, consider a case where there exist two Clients C1 and C2, one Proxy P, and
one Target T. Oblivious DoH assumes an extended Dolev-Yao style attacker <span>[<a href="#Dolev-Yao" class="xref">Dolev-Yao</a>]</span> that can observe all
network activity and can adaptively compromise either P or T, but not C1 or C2. Note that compromising
both P and T is equivalent to collusion between these two parties in practice. Once compromised,
the attacker has access to all session information and private key material. (This generalizes to
arbitrarily many Clients, Proxies, and Targets, with the constraints that (1) not all Targets and Proxies
are simultaneously compromised and (2) at least two Clients are left uncompromised.) The attacker is
prohibited from sending Client-identifying information, such as IP addresses, to Targets. (This would
allow the attacker to trivially link a query to the corresponding Client.)<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">In this model, both C1 and C2 send Oblivious DoH queries Q1 and Q2, respectively, through P to T,
and T provides answers A1 and A2. The attacker aims to link C1 to (Q1, A1) and C2 to (Q2, A2), respectively.
The attacker succeeds if this linkability is possible without any additional interaction. (For example,
if T is compromised, it could return a DNS answer corresponding to an entity it controls and then observe
the subsequent connection from a Client, learning its identity in the process. Such attacks are out of
scope for this model.)<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">Oblivious DoH security prevents such linkability. Informally, this means:<a href="#section-11-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-11-4">
<li id="section-11-4.1">Queries and answers are known only to Clients and Targets in possession of the corresponding
response key and HPKE keying material. In particular, Proxies know the origin and destination
of an oblivious query, yet do not know the plaintext query. Likewise, Targets know only the oblivious
query origin, i.e., the Proxy, and the plaintext query. Only the Client knows both the plaintext
query contents and destination.<a href="#section-11-4.1" class="pilcrow">¶</a>
</li>
        <li id="section-11-4.2">Target resolvers cannot link queries from the same Client in the absence of unique per-Client
keys.<a href="#section-11-4.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-11-5">Traffic analysis mitigations are outside the scope of this document. In particular, this document
does not prescribe padding lengths for <code>ObliviousDoHQuery</code> and <code>ObliviousDoHResponse</code> messages.
Implementations <span class="bcp14">SHOULD</span> follow the guidance in <span>[<a href="#RFC8467" class="xref">RFC8467</a>]</span> for choosing padding length.<a href="#section-11-5" class="pilcrow">¶</a></p>
<p id="section-11-6">Oblivious DoH security does not depend on Proxy and Target indistinguishability. Specifically, an
on-path attacker could determine whether a connection to a specific endpoint is used for oblivious or
direct DoH queries. However, this has no effect on the confidentiality goals listed above.<a href="#section-11-6" class="pilcrow">¶</a></p>
<div id="denial-of-service">
<section id="section-11.1">
        <h3 id="name-denial-of-service">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-denial-of-service" class="section-name selfRef">Denial of Service</a>
        </h3>
<p id="section-11.1-1">Malicious Clients (or Proxies) can send bogus Oblivious DoH queries to Targets as a Denial-of-Service
(DoS) attack. Target servers can throttle processing requests if such an event occurs. Additionally,
since Targets provide explicit errors upon decryption failure, i.e., if ciphertext decryption fails
or if the plaintext DNS message is malformed, Proxies can throttle specific Clients in response to
these errors. In general, however, Targets trust Proxies to not overwhelm the Target, and it is
expected that Proxies implement either some form of rate limiting or client authentication to limit
abuse; see <a href="#authentication" class="xref">Section 11.3</a>.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">Malicious Targets or Proxies can send bogus answers in response to Oblivious DoH queries. Response
decryption failure is a signal that either the Proxy or Target is misbehaving. Clients can choose to
stop using one or both of these servers in the event of such failure. However, as noted above, malicious
Targets and Proxies are out of scope for the threat model.<a href="#section-11.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="proxy-policies">
<section id="section-11.2">
        <h3 id="name-proxy-policies">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-proxy-policies" class="section-name selfRef">Proxy Policies</a>
        </h3>
<p id="section-11.2-1">Proxies are free to enforce any forwarding policy they desire for Clients. For example, they can choose
to only forward requests to known or otherwise trusted Targets.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
<p id="section-11.2-2">Proxies that do not reuse connections to Targets for many Clients may allow Targets to link individual
queries to unknown Targets. To mitigate this linkability vector, it is <span class="bcp14">RECOMMENDED</span> that Proxies pool
and reuse connections to Targets. Note that this benefits performance as well as privacy, since
queries do not incur any delay that might otherwise result from Proxy-to-Target connection establishment.<a href="#section-11.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authentication">
<section id="section-11.3">
        <h3 id="name-authentication">
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-authentication" class="section-name selfRef">Authentication</a>
        </h3>
<p id="section-11.3-1">Depending on the deployment scenario, Proxies and Targets might require authentication before use.
Regardless of the authentication mechanism in place, Proxies <span class="bcp14">MUST NOT</span> reveal any Client
authentication information to Targets. This is required so Targets cannot uniquely identify
individual Clients.<a href="#section-11.3-1" class="pilcrow">¶</a></p>
<p id="section-11.3-2">Note that if Targets require Proxies to authenticate at the HTTP or  application layer before use,
this ought to be done before attempting to forward any Client query to the Target. This will allow
Proxies to distinguish 401 (Unauthorized) response codes due to authentication failure from
401 response codes due to Client key mismatch; see <a href="#oblivious-response" class="xref">Section 4.3</a>.<a href="#section-11.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iana">
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-12-1">This document makes changes to the "Media Types" registry.
The changes are described in the following subsection.<a href="#section-12-1" class="pilcrow">¶</a></p>
<div id="oblivious-doh-message-media-type">
<section id="section-12.1">
        <h3 id="name-oblivious-doh-message-media">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-oblivious-doh-message-media" class="section-name selfRef">Oblivious DoH Message Media Type</a>
        </h3>
<p id="section-12.1-1">This document registers a new media type, "application/oblivious-dns-message".<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.1-2">
          <dt id="section-12.1-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.2">application<a href="#section-12.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.4">oblivious-dns-message<a href="#section-12.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.6">N/A<a href="#section-12.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.8">N/A<a href="#section-12.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.10">This is a binary format, containing encrypted DNS
requests and responses encoded as <code>ObliviousDoHMessage</code> values, as defined
in <a href="#encoding" class="xref">Section 6.1</a>.<a href="#section-12.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.12">See this document. The content is an encrypted DNS
message, and not executable code.<a href="#section-12.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.14">This document specifies the format of
conforming messages and the interpretation thereof; see <a href="#encoding" class="xref">Section 6.1</a>.<a href="#section-12.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.16">This document<a href="#section-12.1-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.18">This media type is intended
to be used by Clients wishing to hide their DNS queries when
using DNS over HTTPS.<a href="#section-12.1-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.19">Additional information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.20">N/A<a href="#section-12.1-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.21">Person and email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.22">See the
Authors' Addresses section.<a href="#section-12.1-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.23">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.24">COMMON<a href="#section-12.1-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.25">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.26">N/A<a href="#section-12.1-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.27">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.28">Tommy Pauly (tpauly@apple.com)<a href="#section-12.1-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.29">Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.30">IETF<a href="#section-12.1-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.1-2.31">Provisional registration? (standards tree only):</dt>
          <dd style="margin-left: 1.5em" id="section-12.1-2.32">No<a href="#section-12.1-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC9180">[HPKE]</dt>
        <dd>
<span class="refAuthor">Barnes, R.</span>, <span class="refAuthor">Bhargavan, K.</span>, <span class="refAuthor">Lipp, B.</span>, and <span class="refAuthor">C. Wood</span>, <span class="refTitle">"Hybrid Public Key Encryption"</span>, <span class="seriesInfo">RFC 9180</span>, <span class="seriesInfo">DOI 10.17487/RFC9180</span>, <time datetime="2022-02" class="refDate">February 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9180">https://www.rfc-editor.org/info/rfc9180</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9110">[HTTP]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9110">https://www.rfc-editor.org/info/rfc9110</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="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refAuthor">Schiller, J.</span>, and <span class="refAuthor">S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6570">[RFC6570]</dt>
        <dd>
<span class="refAuthor">Gregorio, J.</span>, <span class="refAuthor">Fielding, R.</span>, <span class="refAuthor">Hadley, M.</span>, <span class="refAuthor">Nottingham, M.</span>, and <span class="refAuthor">D. Orchard</span>, <span class="refTitle">"URI Template"</span>, <span class="seriesInfo">RFC 6570</span>, <span class="seriesInfo">DOI 10.17487/RFC6570</span>, <time datetime="2012-03" class="refDate">March 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6570">https://www.rfc-editor.org/info/rfc6570</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="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" 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>
<dt id="RFC8467">[RFC8467]</dt>
        <dd>
<span class="refAuthor">Mayrhofer, A.</span>, <span class="refTitle">"Padding Policies for Extension Mechanisms for DNS (EDNS(0))"</span>, <span class="seriesInfo">RFC 8467</span>, <span class="seriesInfo">DOI 10.17487/RFC8467</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8467">https://www.rfc-editor.org/info/rfc8467</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8484">[RFC8484]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span> and <span class="refAuthor">P. McManus</span>, <span class="refTitle">"DNS Queries over HTTPS (DoH)"</span>, <span class="seriesInfo">RFC 8484</span>, <span class="seriesInfo">DOI 10.17487/RFC8484</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8484">https://www.rfc-editor.org/info/rfc8484</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9209">[RFC9209]</dt>
      <dd>
<span class="refAuthor">Nottingham, M.</span> and <span class="refAuthor">P. Sikora</span>, <span class="refTitle">"The Proxy-Status HTTP Response Header Field"</span>, <span class="seriesInfo">RFC 9209</span>, <span class="seriesInfo">DOI 10.17487/RFC9209</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9209">https://www.rfc-editor.org/info/rfc9209</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="Dolev-Yao">[Dolev-Yao]</dt>
        <dd>
<span class="refAuthor">Dolev, D.</span> and <span class="refAuthor">A. C. Yao</span>, <span class="refTitle">"On the Security of Public Key Protocols"</span>, <span class="refContent">IEEE Transactions on Information Theory, Vol. IT-29, No. 2</span>, <span class="seriesInfo">DOI 10.1109/TIT.1983.1056650</span>, <time datetime="1983-03" class="refDate">March 1983</time>, <span>&lt;<a href="https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-01056650.pdf">https://www.cs.huji.ac.il/~dolev/pubs/dolev-yao-ieee-01056650.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.annee-dprive-oblivious-dns">[OBLIVIOUS-DNS]</dt>
        <dd>
<span class="refAuthor">Edmundson, A.</span>, <span class="refAuthor">Schmitt, P.</span>, <span class="refAuthor">Feamster, N.</span>, and <span class="refAuthor">A. Mankin</span>, <span class="refTitle">"Oblivious DNS - Strong Privacy for DNS Queries"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-annee-dprive-oblivious-dns-00</span>, <time datetime="2018-07-02" class="refDate">2 July 2018</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-annee-dprive-oblivious-dns-00">https://datatracker.ietf.org/doc/html/draft-annee-dprive-oblivious-dns-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-ohai-ohttp">[OHTP]</dt>
        <dd>
<span class="refAuthor">Thomson, M.</span> and <span class="refAuthor">C.A. Wood</span>, <span class="refTitle">"Oblivious HTTP"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-ohai-ohttp-01</span>, <time datetime="2022-02-15" class="refDate">15 February 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp-01">https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7239">[RFC7239]</dt>
        <dd>
<span class="refAuthor">Petersson, A.</span> and <span class="refAuthor">M. Nilsson</span>, <span class="refTitle">"Forwarded HTTP Extension"</span>, <span class="seriesInfo">RFC 7239</span>, <span class="seriesInfo">DOI 10.17487/RFC7239</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7239">https://www.rfc-editor.org/info/rfc7239</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7871">[RFC7871]</dt>
      <dd>
<span class="refAuthor">Contavalli, C.</span>, <span class="refAuthor">van der Gaast, W.</span>, <span class="refAuthor">Lawrence, D.</span>, and <span class="refAuthor">W. Kumari</span>, <span class="refTitle">"Client Subnet in DNS Queries"</span>, <span class="seriesInfo">RFC 7871</span>, <span class="seriesInfo">DOI 10.17487/RFC7871</span>, <time datetime="2016-05" class="refDate">May 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7871">https://www.rfc-editor.org/info/rfc7871</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="use-of-generic-proxy-services">
<section id="appendix-A">
      <h2 id="name-use-of-generic-proxy-servic">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-use-of-generic-proxy-servic" class="section-name selfRef">Use of Generic Proxy Services</a>
      </h2>
<p id="appendix-A-1">Using DoH over anonymizing proxy services such as Tor can also achieve the desired goal of separating
query origins from their contents. However, there are several reasons why such systems are undesirable
as contrasted with Oblivious DoH:<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="appendix-A-2">
<li id="appendix-A-2.1">Tor is meant to be a generic connection-level anonymity system, and it incurs higher latency costs
and protocol complexity for the purpose of proxying individual DNS queries. In contrast, Oblivious DoH
is a lightweight protocol built on DoH, implemented as an application-layer proxy, that can be enabled
as a default mode for users that need increased privacy.<a href="#appendix-A-2.1" class="pilcrow">¶</a>
</li>
        <li id="appendix-A-2.2">As a one-hop proxy, Oblivious DoH encourages connectionless proxies to mitigate Client query correlation
with few round trips. In contrast, multi-hop systems such as Tor often run secure connections (TLS) end to end,
which means that DoH servers could track queries over the same connection. Using a fresh DoH connection
per query would incur a non-negligible penalty in connection setup time.<a href="#appendix-A-2.2" class="pilcrow">¶</a>
</li>
      </ol>
</section>
</div>
<div id="acknowledgments">
<section id="appendix-B">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-B-1">This work is inspired by Oblivious DNS <span>[<a href="#I-D.annee-dprive-oblivious-dns" class="xref">OBLIVIOUS-DNS</a>]</span>. Thanks to all of the
authors of that document. Thanks to
<span class="contact-name">Nafeez Ahamed</span>,
<span class="contact-name">Elliot Briggs</span>,
<span class="contact-name">Marwan Fayed</span>,
<span class="contact-name">Jonathan Hoyland</span>,
<span class="contact-name">Frederic Jacobs</span>,
<span class="contact-name">Tommy Jensen</span>,
<span class="contact-name">Erik Nygren</span>,
<span class="contact-name">Paul Schmitt</span>,
<span class="contact-name">Brian Swander</span>, and
<span class="contact-name">Peter Wu</span>
for their feedback and input.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-C">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eric Kinnear</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">California</span> <span class="postal-code">95014</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:ekinnear@apple.com" class="email">ekinnear@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Patrick McManus</span></div>
<div dir="auto" class="left"><span class="org">Fastly</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mcmanus@ducksong.com" class="email">mcmanus@ducksong.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tommy Pauly</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">California</span> <span class="postal-code">95014</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tpauly@apple.com" class="email">tpauly@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tanya Verma</span></div>
<div dir="auto" class="left"><span class="org">Cloudflare</span></div>
<div dir="auto" class="left"><span class="street-address">101 Townsend St</span></div>
<div dir="auto" class="left">
<span class="locality">San Francisco</span>, <span class="region">California</span> <span class="postal-code">94107</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:vermatanyax@gmail.com" class="email">vermatanyax@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 dir="auto" class="left"><span class="street-address">101 Townsend St</span></div>
<div dir="auto" class="left">
<span class="locality">San Francisco</span>, <span class="region">California</span> <span class="postal-code">94107</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:caw@heapingbits.net" class="email">caw@heapingbits.net</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>