<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-doh-digests-00" category="info">

  <front>
    <title>DOH Digests</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date year="2018" month="July" day="02"/>

    <area>ART</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The lack of flexible configuration and selection mechanisms for DOH servers is identified as suboptimal for privacy and performance in some applications.</t>

<t>This document makes a straw-man proposal for an improvement.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>One of the core motivations for DOH <xref target="I-D.ietf-doh-dns-over-https"/> is to improve end-user privacy by obfuscating the stream of DNS requests that the DOH client makes. It does this by mixing DOH requests into a stream of “normal” HTTP requests to a configured Web server; for example, a large Web site or a Content Delivery Network.</t>

<t>However, DOH intentionally avoids defining a mechanism for configuring a particular DOH server for a given application or host. So far, the most common way to do so is to select one from a pre-configured list of services in an application, such as a Web browser.</t>

<t>Typically, the list of available DOH services is vetted by the application’s vendor to assure that they will honour the application’s requirements for handling of sensitive data (i.e., the client’s DNS request stream) and similar concerns.</t>

<t>This document proposes a means of selecting a DOH server that encourages the deployment of DOH servers by sharing some of its additional benefits with servers that are good candidates for serving DOH traffic.</t>

<section anchor="dohs-additional-benefits-for-associated-services" title="DOH’s Additional Benefits for Associated Services">

<t>When a DOH server is colocated with (or closely coordinated with) other network services – especially HTTP services – those associated services enjoy a few additional benefits beyond those seen by adopting DOH in the first place.</t>

<t><list style="symbols">
  <t>Associated services have an additional privacy benefit; there is one less party involved in the interaction, whereas “normal” DNS and DOH to an unassociated HTTP server require a third party to resolve names.</t>
  <t>Removing a third party also removes a separate point of potential failure, improving control over service quality and availability. See <xref target="fragile"/> for further discussion.</t>
  <t>Finally, the DOH server can use DNS to optimise the provision of associated services. For example, DNS results can be optimised based on the client’s request stream with a higher degree of certainty.</t>
</list></t>

<t>In the future, a DOH server might might use Secondary Certificates <xref target="I-D.ietf-httpbis-http2-secondary-certs"/> to further optimise performance of associated services, by using the information in the DNS request stream to aggregate all of its traffic into a small number of connections (possibly only one), thereby allowing greater coordination of congestion control and avoiding connection setup costs.</t>

</section>
<section anchor="achieving-dohs-privacy-goals-through-diversity" title="Achieving DOH’s Privacy Goals through Diversity">

<t>Overall, a major goal for deployment of DOH is to assure that DNS connectivity is robust and private. Arguably, this is best served by having a diverse set of available DOH servers that are colocated with popular HTTP content, so that it’s more difficult to discriminate DOH from “regular” HTTP, and so the it’s more difficult to block DOH services, due to the high impact of blocking a popular site.</t>

<t>One way to encourage the development of such a set is to offer the additional benefits above to parties that are good candidates for serving such traffic. When clients can direct their DOH queries to the HTTP server which will eventually serve their traffic, it provides both better privacy properties and better performance and availability to a broader set of servers.</t>

<t>This is a marked improvement over the static configuration mechanism commonly in place now; accruing such privacy, availability, and performance benefits to whatever DOH server the application or user selects means that only parties who have a relationship with that service will realise these benefits.</t>

<t>This document proposes one way to achieve this.</t>

</section>
</section>
<section anchor="conventions-and-definitions" title="Conventions and Definitions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>

</section>
<section anchor="doh-digests" title="DOH Digests">

<t>A DOH Digest is a Bloom filter indicating the set of hosts a given DOH server should be used for.</t>

<section anchor="using-doh-digests" title="Using DOH Digests">

<t>When an application has a valid DOH digest for a given DOH server, it tests the digest for each DNS request it makes by hostname; if the hostname (after normalisation) is found in the digest, all DNS requests regarding that hostname SHOULD be sent to the corresponding DOH server. If multiple DOH digests match a given hostname, any matching DOH server MAY be used; the client SHOULD select one of the candidates randomly.</t>

<t>If the DOH service is unavailable, produces errors (HTTP or DNS), or the application otherwise fails to obtain an answer from it, the application MAY (but is not required to) fall back to using another configured DOH server, or to using “normal” DNS.</t>

<t>Likewise, hosts that do not match any configured bloom filter SHOULD be sent to a randomly selected DOH server that is available.</t>

<t>The means of discovering a DOH digest for a given DOH server is out of scope for this document, but generally it will be pre-arranged between the application and the DOH server.</t>

<t>The nature of this arrangment is highly dependent upon the application and its desired properties. That said, a number of requirements are placed upon this arrangement.</t>

<t><list style="symbols">
  <t>The digest MUST be conveyed in a manner that is secure and authenticated; e.g., TLS with appropriate certificate checks. Clients MUST enforce this.</t>
  <t>The application MUST consider the DOH service as meeting whatever criteria it deems fit for configuring a “catch-all” DOH service (e.g., in terms of privacy, service availability, etc.), since false positives might be sent to the service, and hosts not matched by any configured bloom filter might be sent to it.</t>
  <t>The digest MUST be updated on a periodic basis; e.g., once a day. Clients SHOULD NOT use stale digests.</t>
</list></t>

</section>
<section anchor="the-doh-digest-format" title="The DOH Digest Format">

<t>TBD - likely just a bloom filter.</t>

</section>
<section anchor="hostname-normalisation" title="Hostname Normalisation">

<t>TBD</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>Because a DOH digest allows a DOH server to claim traffic from an arbitrary hostname, applications need to take extreme care in selecting the DOH servers they will be accepted from, as well as assuring that their integrity and authentication have not been compromised.</t>

<t>Applications might mitigate this by monitoring DOH servers for such abuse and terminating their ability to use DOH digests when it is found.</t>

<t>TBD - more advanced mitigations</t>

<t>A hostname is effectively captured by a DOH server until the digest that reflects any change in its status is updated in the application. This delay should not result in any loss of functionality, since the “old” configuration will still direct requests to a functional DOH server.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document currently has no IANA actions, but may grow some as the document progresses.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>




    </references>

    <references title='Informative References'>

<reference anchor="fragile" target="https://arxiv.org/pdf/1806.08420.pdf">
  <front>
    <title>Oh, What a Fragile Web We Weave: Third-party Service Dependencies In Modern Webservices and Implications</title>
    <author initials="A." surname="Kashaf" fullname="Aqsa Kashaf">
      <organization></organization>
    </author>
    <author initials="C." surname="Zarate" fullname="Carolina Zarate">
      <organization></organization>
    </author>
    <author initials="H." surname="Wang" fullname="Hanruo Wang">
      <organization></organization>
    </author>
    <author initials="Y." surname="Agarwal" fullname="Yuvraj Agarwal">
      <organization></organization>
    </author>
    <author initials="V." surname="Sekar" fullname="Vyas Sekar">
      <organization></organization>
    </author>
    <date year="2018" month="June"/>
  </front>
</reference>




<reference anchor="I-D.ietf-doh-dns-over-https">
<front>
<title>DNS Queries over HTTPS (DoH)</title>

<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
    <organization />
</author>

<author initials='P' surname='McManus' fullname='Patrick McManus'>
    <organization />
</author>

<date month='June' day='27' year='2018' />

<abstract><t>This document describes how to make DNS queries over HTTPS.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-doh-dns-over-https-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-doh-dns-over-https-12.txt' />
</reference>



<reference anchor="I-D.ietf-httpbis-http2-secondary-certs">
<front>
<title>Secondary Certificate Authentication in HTTP/2</title>

<author initials='M' surname='Bishop' fullname='Mike Bishop'>
    <organization />
</author>

<author initials='N' surname='Sullivan' fullname='Nick Sullivan'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='June' day='27' year='2018' />

<abstract><t>A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established.  The means by which these credentials are used with requests is defined.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-http2-secondary-certs-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-http2-secondary-certs-02.txt' />
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAHziOVsAA41ZXXPbuBV9569AnYc6O5LiZHa2WeehVexN7Wlsp7HTzLbT
6UAkKCEmCS4ASlEz+9977r0gRdrenWYSWyJA3O97zkXm83kWbazMqTq/uVDn
dm1CDFnh8kbXeFh4XcZ542K0zXqj63nhNvNCds1PTrJcR7N2fn+qbFO6LLOt
P1XRdyG+Ojn58eRVpr3Rp2r58S7bOX+/9q5rT7N7s8e34lRdNtH4xsT5OcnJ
shB1U/xHV66B7L0JWWtP1b+iy2cqOB+9KQM+7Wv68O8s013cOH+aqXmm8Mc2
4VRdLdT1oC4/FkuutL9/uOL8Wjf2vzpa15zyE1NrW52qGhb/hX4soBwvdB6a
bGJsw+mLF7vdbtGvvsiyxvkaZ2wNnfHx3dmrly9/PIUv4JHRQun12lZG5ETt
1yYeTtT+q90uoM+LtihfvHx98sPi5PX3r04W+CovSJCObjYz9Xmjo9LqnRyo
PpsV/uGvhiB1t7G+mLfax726NX5rc6POTWuawjS5NQE+V1eugNvpxSA7goLf
1WXdVjZnb4QjllogvKfq1cnL1/OTH/jJ4HL6M0++Xf4StPqbDhtdThfOtHeV
bbT6p/Y4arp4oRvfOfVZN+vpws/d1usvarnWfqer6do/9jrArnvtsyybz+dK
r0L0Okfy3G2MqnR+r1ypysp8tSs4J3dNadedZ6vYymAqk/O32uQbxD/UQSFS
XADkD+ODsvgLh0VbWlMoiAzdyrXR1rriva23W53v+cDWeA50A0/bBolaG6Xb
gysXpBoORFF1Nc5Utb4njytSfDfHizjOtS6ks/Hd1niyNbR7IWbWtigqk2XP
qGa8Kzo2IctuGkP2xg2Z6o2qHfJN5A5Gffv258v5+cKaWEr9NmGO0/2cs+/X
X8na6HqhCqky7+CIwcjVXrlV2QWyp1mzLKhudE2Sz69vlTe/dNQRsITMpHUS
m1d2sHahLiMcYGgLpOHE2n6lw2jj8LptoIYeHX7EpVUdqYu7uw8jMbSrjyzi
QxUgkXvDRpuvGqlsZthVUaHJBhvhKrhXnTm0HWh2birUpt+raxOpO8HVF25n
8GjGelneBlfqqkKot84WiKIpbUOa60P+sNBeH1mjArR5B/GjvJLwqjWkNuMU
IbU2LsSFunWq1BBPPqzxBKfWNTbs9J6sLhzSK4VL8lihVaK1uJpkejMfeaWy
eB9OHGrcUgGM5aKXdvmG0luzi1be7bCbEnbfYg/MFlX6o/QW7VFTXfVGycFB
bU2MkInA0v6RjD/SWlPAQopaCFBtSJO92tmqgumN6/wTL1LArecykGyGu4uK
HMxmNQgpXEldSqtjuzAL0VYSD++PcjMl1XNpAba2FBk4K0cjfFyhUo9cpLXR
KCWWx32DozsKKduC1goL9JrzGwqZtnJ7PokqZNRX4B90Sc4R7hNYtrBNF4WV
RFMr0yDD8Gxn42Z4j6UAS9XauULlMMJSbxavcBxSLaGllKXNYdGzZ/QAXlge
Dn/bH06vLUNwudUUtgQUIcs+byg1xwbCL7mrXM4bWaljyvYK/kFV5A5Ajg7f
Lz5XDh7wqpGSOuQIepgJrYFAKiau5/EaUCUYyo9epWHRNF8cqk+VZvekn1Zm
7xBTOSAYqA8n64K6dfIJ8p6iUlqPPGgBEQbu+W5s/yBsAwzlIjkIGrqgCHxD
ZyEQcAuVXmVCUIK2ttm6aovTkjxqH4RMXGg7egmFNnQ0yk3KRQ6aI5ldMzJ/
cBB8mcoAPogE7kkcXvImkESGxsA2fTS120qOjvfqKtBurAnwmJbxWLXOSo62
jlsdIRAqHDU6S3BAZ6FMADmVIszoXaV+6XRloyBgaguWHqCHGQPISXQH6EK5
Vnae06KwIe9CgEtY3Xe2OTSZUc7l5A6Ek5wEOxl5bTC8jbUK3DXLpxJmod6N
IUB6QOgqpAoduzLDcWhXmn66Zto2pi1Dcl6rjV2zBWbtDRcuWkfU8N8eplym
FOsi+25SQDVejOknGXVr4NBCA3fOcAIYRs6VPEZpAuaVDfz71Tz0L8xJJAE2
fNJ7dPDNmIY87ZkZVUYXegwf+CnsTyn7uGFybq5h8pryBcHqW1ZqNANm17TW
dPWKdCopZxqhWUEdo5cGsDHQiIZ/mOczqSKq1KpyO1IJMiDCHzpKCjFOonGD
vvWJKDkHOE7ZmSTB0Ni1eACOIA1wmW+s6XsjIvsh1fJfHSoCKmAcWW8w9VCP
Re6CTuETNKII1voL8mjtEit73NMFhseQRu7r1dlScWCLdytMQ0IUSXo0C7X0
6w4oynlvGT5X7HHKF8ZQtCEp4oJVo772G/g7AYcHfbp1LRMQ7iW5kB4apOQF
S6leE2csLEUSFcIUAxXqkVHU0lkKk4sjJACdJUxsJijqJI2ePmcFVe4nNGGm
is7QEr1F1UQtRudsGO9OzClpTXxtIQQ3sZ8BZRPIbk3l2j4iwmTYURIYV5Ym
kYonUEOviOpiGxM1838iLAvpIVYxVkrXkN5SoEvnzGys0D5UkufDxehxU99t
LM5i/gNDmtgxLvJiOiDJQSeO0vQKnLQCvMKKGEf8nNiKESsoLv3qqB88bNLC
oEH3dMEtfeCJSKeeDFlmP5iaCdEO84iggMwAqNH8wYR14MTCXCvCRQFd1bjd
G6Xz3HeDL5MJs4l2s0dj1RA26L1DoIijT0mYecineYIRzhYSieMQs0p90Hcb
lyAfba+SsWljWykf3t7DHQcKHapKMBQOSv02e3SH3NXciQwXPF7AHIcpZCvj
hYTtnAcL/i6z7D3xY/RCkIarT7d3RzP5ra5v+PPHn/7+6fLjT+f0+fZi+f79
8KHfcXtx8+n9+eHT4c2zm6urn67P5WU8VQ8eXS1/PpIoHN18uLu8uV6+PxKM
GNtJ1UKVnqgOxo8owzISFT1kJVTo7dkH9fJ7wFu6GQF8ffv2B3x5/fJP3+ML
mFEjsjg08pWHA0TUoBHQ2ALn57q1EW17xuP4xu0aRRAizhxfXmXL0VdJ47eV
QxMrbUWFYVHa41FWsp/mrzAMZ6PcgqiuoqqilCqoHQi2fAo9vxwEC3mejnYb
nq62SBzhenJ5NpkED8K41mMapc14r0ECTeDZ9vcIBBfQnTjgG2XlKqB/oI51
SSYL6bSBVXpOPild1wxMVeTM2M2TeZ5g3xfiKRTDcGzKpxV5r4l9e8udB9Nq
wVV6z4hVGP5LVQMXbJuQK90gwoLIXVv80B9P2bCXtelBCnnZB+LNiLP1+oxG
4v5O5NDHPT66umK2Vk4IJ9U3XAL+3cPrjGq46Hj88N4BY4+5d9OFyvUt2It7
oucQo9lReyAKLRC0IoLIGdGEHc3/hKU2zh69TIYdrzpO18bFnvJjrHHPcR7i
sqKbLZwp/E03MmaNxv1xFsm0LVvHEwdsf2/vDWk5SxnPgS0cS03haPbjc1fj
2nkceD04Nrl/okqiGuHAXBbS3IaxmvgGQcphsP7dCuG5qxO8ygF7vG3SlsBy
sb5Gc/YMqSgUbt4rwxck2kPftWGY3NG0+DAUmofJMcNKKoMREdPjzCKL+CBu
hPhGfAbCinTTCqbfuqfPJhhDg+ToHpB7oe4YbrQtiHweiPTkDoQ6LmNp0Z8/
KNJfFn6n7g6dg/FixbegW7OXfkygDop6CA3GC7KLOUIHjYFJTCLfKLNYL2bq
7v1tmoFa0tfTUMHDTxpdVL4x+T0sOEtUiKUami7yAfBErUnK0y4oFmyREHxc
j5pA23CTHgAfmIIctJpCWhhD17Y2PnH3dpRTHs8R/aPJmcdiDzU942vOvoF/
DHInPMTEfIFqRx3lVNYVjVlObp1Cmuge9MB0jgCaVNhQWcLtf6+8Hh1pfzOk
XVsw06esIq5kHVCNBlob+sA5pn6q0PtDbA5MgGdRcLiqP1p4yTMWNgLQdzwk
ogTenqu5qtA+kOdfeKaZKC+oeNFDxPUYcvjtjJH6lrKNKOhZCr1OlOetyTWp
NGkCPB2GBzduDm1f23oYQeX6E37wK4tnfj9GktFFvGoMd1QVAZzKfI1UVoAI
L/f2w/3etPrD6KYSfgd/NS05nqQyF9kZrBDK0yQ4YKVweCJGaz/ckxzKS6gB
3d04CjgNEo5INt9LwJXLsd79DUK0PIUPV+gOfNH5KUamgYWnoRX7k/oZ8p1H
arEOio0GAb5oGYEyMTAqsZ4lLPrY85Cniy1R8qJXR4K3PHADvGYwetEIzBeE
uo2S6PtpGDs4ohrTHHabN6VQdi6TDTU2Cg41TZo3Op5L+ty3jzostVHCApD5
fc/cBE/pBkhuwPeqcoGrv+yaXAZDrnYpczrxyFXF0YPJhhMgRPqZ5rzp/0cc
DptCxzN1ubxePkr36ciAmvD4Xe2ZLzZO3pHLwyCIVsOitXe79B9MiSGOZo41
jAx8Dyj/ZUSMIcv+B+2EQSXiHQAA

-->

</rfc>

