<?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.3.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-proxied-svcb-headers-00" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.2.1 -->
  <front>
    <title abbrev="Proxied SVCB Headers">HTTP Header Fields for Proxied SVCB Metadata</title>
    <seriesInfo name="Internet-Draft" value="draft-proxied-svcb-headers-00"/>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple, Inc.</organization>
      <address>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <date year="2021" month="February" day="19"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document defines HTTP header fields for the passing Service Binding (SVCB) DNS metadata
in HTTP responses.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/tfpauly/privacy-proxy"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>CONNECT <xref target="RFC7231" format="default"/> and CONNECT-UDP <xref target="I-D.ietf-masque-connect-udp" format="default"/> are HTTP methods that
clients may use to establish TCP or UDP flows to target servers. Once proxy servers establish
these flows, proxy servers treat allocated flows as opaque byte or datagram streams respectively.
Clients specify the target in authority-form (Section 5.3 of <xref target="RFC7230" format="default"/>), including the name or
IP address of the server along with a port number. When using a name instead of an IP address, the
proxy server locally resolves the name to an IPv4 or IPv6 address with A or AAAA queries. The
client does not see these A or AAAA answers, as they are only relevant to the proxy in establishing
a connection to the target.</t>
      <t>In some circumstances, some DNS metadata may be useful to clients. This is especially true for
information contained in Service Binding (SVCB or HTTPS) records <xref target="I-D.ietf-dnsop-svcb-https" format="default"/>.
These records can influence client behavior even when clients are not directly interacting with
target IP addresses. The records can be used to determine which application-level protocols
are supported by an endpoint. These records also can include a TLS Encrypted Client Hello
<xref target="I-D.ietf-tls-esni" format="default"/> configuration, which can be used in protecting the end-to-end TLS handshake.</t>
      <t>This document specifies HTTP header fields that proxy servers may use to relay information retrieved
from SVCB records from proxy servers to clients when using CONNECT or CONNECT-UDP.</t>
      <section anchor="requirements" numbered="true" toc="default">
        <name>Requirements</name>
        <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&nbsp;14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they
appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="svcb-params-request" numbered="true" toc="default">
      <name>SVCB Request Header Field</name>
      <t>Clients can request SVCB parameters with the Structured Header
<xref target="RFC8941" format="default"/> "DNS-SVCB-Keys". Its value MUST
be an sf-list whose members are sf-integer items that MUST NOT contain parameters. Its
ABNF is:</t>
      <artwork type="abnf" name="" align="left" alt=""><![CDATA[
DNS-SVCB-Keys = sf-list
]]></artwork>
      <t>Each list member corresponds to the numeric version of an SvcParamKey.</t>
      <t>For example, a client wanting to receive ALPN and ECH Config parameters would
send a request for 1 (alpn) and 5 (echconfig):</t>
      <artwork type="example" name="" align="left" alt=""><![CDATA[
HEADERS
:method = CONNECT
:authority = svc.example.com:443
dns-svcb-keys = 1, 5
]]></artwork>
    </section>
    <section anchor="svcb-params-response" numbered="true" toc="default">
      <name>SVCB Response Header Fields</name>
      <t>A proxy server that receives a request with "DNS-SVCB-Keys" MAY respond with
the Structured Header "DNS-SVCB-Params" response header fields. The value of
"DNS-SVCB-Params" MUST be an sf-list whose members are sf-string, each of
which MUST contain parameters.</t>
      <artwork type="abnf" name="" align="left" alt=""><![CDATA[
DNS-SVCB-Params = sf-list
]]></artwork>
      <t>Each list member is an sf-string that represents the TargetName of a single received
SVCB or HTTPS record. The Parameters associated with each list member correspond
to the SvcParam key-value pairs for that record, the priority of the record, and the
TTL of the record.</t>
      <t>The priority of the record MUST be a parameter with the key "priority", and a value as an
sf-integer. Alias forms, with priority 0, MUST NOT be included.</t>
      <t>The TTL of the record MUST be a parameter with the key "ttl", and a value as an sf-integer.</t>
      <t>Each SvcParam that matches a key requested by the client is a parameters with a key
that is the character "p" followed by the numeric version of the SvcParamKey. For example,
the ALPN SvcParamKey, with the numeric value 1, would have a parameter key "p1". The value
of each parameter MUST be an sf-binary item that contains the bytes of the SvcParamValue.</t>
      <t>Proxy servers MUST NOT include the "DNS-SVCB-Params" response header field if the
corresponding request did not include a "DNS-SVCB-Keys". Servers MAY include
specific SvcParamKey values that were not requested. Specifically, servers SHOULD include
the "mandatory" parameter if present, which would be presented as "p0", along with any
parameters that are defined as mandatory for that record.</t>
      <t>As an example, assume that the server received the following "svc.example.com" SVCB records:</t>
      <artwork type="diagram" name="" align="left" alt=""><![CDATA[
   svc.example.com. 3600 IN HTTPS 1 svc2.example.com. alpn=h2,h3 echconfig="123..."
   svc.example.com. 3600 IN HTTPS 2 . alpn=h2 echconfig="abc..."
]]></artwork>
      <t>A successful CONNECT response would include the following headers, if the client requested both
"alpn" and "echconfig":</t>
      <artwork type="example" name="" align="left" alt=""><![CDATA[
HEADERS
:method = CONNECT
:status = 200
dns-svcb-params = "svc2.example.com.";priority=1;ttl=3600;p1=:aDIsaDM=:;p5=:MTIzLi4u:,
                  "svc.example.com.";priority=2;ttl=3600;p1=:aDI=:;p5=:YWJjLi4u:
]]></artwork>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-header" numbered="true" toc="default">
        <name>HTTP Headers</name>
        <t>This document registers the "DNS-SVCB-Keys" and "DNS-SVCB-Params",
headers in the "Permanent Message Header Field Names"
&lt;<eref target="https://www.iana.org/assignments/message-headers"/>&gt;.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +----------------------+----------+--------+---------------+
  | Header Field Name    | Protocol | Status |   Reference   |
  +----------------------+----------+--------+---------------+
  | DNS-SVCB-Keys        |   http   |  exp   | This document |
  +----------------------+----------+--------+---------------+
  | DNS-SVCB-Params      |   http   |  exp   | This document |
  +----------------------+----------+--------+---------------+
]]></artwork>
      </section>
    </section>
    <section anchor="sec-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The "DNS-SVCB-Params" header in <xref target="svcb-params-response" format="default"/> does not include any DNSSEC information. Clients that
depend on the contents of the SVCB record being DNSSEC-validated MUST NOT use this metadata without
otherwise fetching the record and its corresponding RRSIG record and locally verifying its contents.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7231">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7231"/>
        <seriesInfo name="DOI" value="10.17487/RFC7231"/>
      </reference>
      <reference anchor="I-D.ietf-masque-connect-udp" target="http://www.ietf.org/internet-drafts/draft-ietf-masque-connect-udp-03.txt">
        <front>
          <title>The CONNECT-UDP HTTP Method</title>
          <author initials="D" surname="Schinazi" fullname="David Schinazi">
            <organization/>
          </author>
          <date month="January" day="5" year="2021"/>
          <abstract>
            <t>This document describes the CONNECT-UDP HTTP method.  CONNECT-UDP is similar to the HTTP CONNECT method, but it uses UDP instead of TCP.  Discussion of this work is encouraged to happen on the MASQUE IETF mailing list masque@ietf.org or on the GitHub repository which contains the draft: https://github.com/ietf-wg-masque/draft-ietf- masque-connect-udp.  Discussion Venues  This note is to be removed before publishing as an RFC.  Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-masque/draft-ietf-masque-connect-udp.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-masque-connect-udp-03"/>
      </reference>
      <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7230">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7230"/>
        <seriesInfo name="DOI" value="10.17487/RFC7230"/>
      </reference>
      <reference anchor="I-D.ietf-dnsop-svcb-https" target="http://www.ietf.org/internet-drafts/draft-ietf-dnsop-svcb-https-02.txt">
        <front>
          <title>Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)</title>
          <author initials="B" surname="Schwartz" fullname="Benjamin Schwartz">
            <organization/>
          </author>
          <author initials="M" surname="Bishop" fullname="Mike Bishop">
            <organization/>
          </author>
          <author initials="E" surname="Nygren" fullname="Erik Nygren">
            <organization/>
          </author>
          <date month="November" day="2" year="2020"/>
          <abstract>
            <t>This document specifies the "SVCB" and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTPS origins.  SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins.  By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.  TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/MikeBishop/dns-alt-svc [1].  The most recent working version of the document, open issues, etc. should all be available there.  The authors (gratefully) accept pull requests.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-02"/>
      </reference>
      <reference anchor="I-D.ietf-tls-esni" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-esni-09.txt">
        <front>
          <title>TLS Encrypted Client Hello</title>
          <author initials="E" surname="Rescorla" fullname="Eric Rescorla">
            <organization/>
          </author>
          <author initials="K" surname="Oku" fullname="Kazuho Oku">
            <organization/>
          </author>
          <author initials="N" surname="Sullivan" fullname="Nick Sullivan">
            <organization/>
          </author>
          <author initials="C" surname="Wood" fullname="Christopher Wood">
            <organization/>
          </author>
          <date month="December" day="16" year="2020"/>
          <abstract>
            <t>This document describes a mechanism in Transport Layer Security (TLS) for encrypting a ClientHello message under a server public key.</t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tls-esni-09"/>
      </reference>
      <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>
      <reference anchor="RFC8941" target="https://www.rfc-editor.org/info/rfc8941">
        <front>
          <title>Structured Field Values for HTTP</title>
          <author initials="M." surname="Nottingham" fullname="M. Nottingham">
            <organization/>
          </author>
          <author initials="P-H." surname="Kamp" fullname="P-H. Kamp">
            <organization/>
          </author>
          <date year="2021" month="February"/>
          <abstract>
            <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8941"/>
        <seriesInfo name="DOI" value="10.17487/RFC8941"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAEHxL2AAA71YXXPbuBV9x69AlZd4IjKW7ew2St2pIju1WltWLWV3dnZ2
OhAJSWj4tQQkRXWc39Lf0l/WcwFQJGV1moed6iGhSeDi4txzz71AEATMKJPI
Pr+ZzSb8RopYlvyDkkms+SIv+aTMPysZ8+kPw/f8ThoRCyOYmM9Luem3v7rJ
msV5lIkUJuNSLExQuDGB3kTzYOXGBKenDIZkn0X4d5mXuz7XJmZMFWWfm3Kt
zdnp6dvTM/ZJ7rZ5Gff5KDOyzKQJrsgqY9qILP67SPIMK+2kZoXq859NHnW5
zktTyoXG0y6lh18YE2uzyss+4wHj+KlM9/ks5BOxTnb2jXN5lqfprvE2L5d9
PiiKRHbhQRTalzIVKoGbBQ37k6CvYZSnjAVBwMVcm1JE8HC2UpoDjHUqM8Nj
uVCZ1A5nBwNf1DibleSF0FplSz6V5UZFkr9XWUx/vyR4T/jVeMrTKgIqc5ZK
qYs801KHbvlUxXEiGXtBgJV5vI6MyjPGhvfj8fVwxh8ff/fwYfj92Xnv6YkD
Qe4/BB+vJvRxFFyFSppFkAr961oGUZ5lMjLBOi5oQindsvBjlcN1sxKGRYnC
DjVPxY6vteQm5xLhmSdKr/hsOAGKnMwvknyr6asR5VIarrFPkCHk9xl2SzzZ
Ve9qAwzIwKad2z0YhCgLw0WS5ESj2C8gNM8LAef5fGckLU6ILUuRgmOYkWqL
GnalNjLZhWzo/ad3arGzsfAuAmbHHGV2AeKUIhjSQsrfhOc8X9SAnj49nXQx
IUrWNmpkhUgFB9howkUcY1VNU+iL2wIn/i75VpkVF7wAb3m2TueyDPmPK5kB
TbIknB1w1oA3ZEFkvDbZJYOsiQwnQJJkR/vMk43UtTNA307eXBAw+P+7vWfW
iwG9HuDHAWCpwCs+g3UXYrAZtrKcQie5C0w9QWR6i6h0KQD4trNsyTPrRiI3
AvMp9qsq1MB2H2VskwnuyUbo+pEuDOD2KENaw/9IlUgoSv5IUoLTu2ZiWBLO
JfFwsU7IjGcn7QP5qIhaFGeLD5RGUvohnSi4wi4NL4xArsbk4dFcpC1TGkxP
sLUI8qRbqRNnOi+83hlT6KenEGJAYFWjI8QASyZrScz34M7lSmwUTMsNQr+l
+FeZRUgS7LGCBZMQdlBDqIzy7GGerzUrfORaSzpcYkIlljCQYpdYSEVgH1RM
RRaAAMGSCQUJaponmtHqel0QPTF5viMGySwucnhhF2nsTCQ699ujRJAg7+x2
yq+zqNwVNN0lG4oFspY1UTOJDqTOFGQGEVio5bq07nS9h80NIDDknnQAEFHg
T2DyAP/Z9VaQNr0Sn2R4qMMuydVxJSY5O9CYhqiBxoKgr6lSSoMc2ciYLco8
dWWwQsK+OdCrPRtdeF16V9KMyDfEGI6/eMEf5K9rxJw817QTyVEQ+dYu0Ln7
OJ11uu5/Pr63zw/Xf/s4eri+oufpzeD2dv/A/Ijpzf3H26v6qZ45vL+7ux5f
ucl4y1uvWOdu8BO+UNHo3E9mo/vx4LZDoTAtgIkt2OhcOpIWwAgRE+gLpI5K
NXfhez+c/PtfvQsvn2e93lvE3f3x+973F/iDEHKrWQ1xf5KuMHBVitJqc5KA
F4UyoJ3VHb3KtxmCWlLgUQRtRAhEKE2ru+GPL2yCFgJ1QQelG/LE9sWA6Obf
Oit2JGWNV0pi3RQCEpl1iT0548xv4e0F1dcOlCmgycFf5U53Qj6C4Y1A2nOK
GQNGWEUvAkigwQ5z8CyVpP8u5fGFMFzCaWVk6vlZhbsSqoZndgU2eD/+AKHr
M/b161c0JNmCtRzhl9WaNICxa4H0si64xWG4dH1FrCshRllCOYg48ZiY74rQ
dBNNaHFYBd4fSLs+i9R2S6KStS2E32YpJVAkUXP54HYytpG9Ht7woU32Frz5
OomZplwW+xhQk9TjL0VSZCd27hv+UkYrJxUnfq9+dXZzPbi6fpiyvutTsGGf
Way/L+eEwiYK/RRq4PoXF+cM4u2k+5NDqtflbxxMeza5juugWT7kkxsEQg1a
IuBC6IHQjf1ZTh0QhiPjfIcXe5k/RrrGNBsNTKzWb+ubqwiOgPmCPZ9mqfUN
rEQfhZB2uSTmwJJTaDv7CCmP8dCt+D+ZCGFxvrgVK/QgKtpmKeExs6VvbFst
sJKTqCaywjhmrYrt5dkhMak5h9Y7R1NAUmUjIf97TjCfEhX5SZIDB2ohVFn1
8y7MWKvrex7laOcbwOobUZn6t9nstv0pdHp/fF4dqRroWpaoRnSqiV6yhY+7
IERZrSwhHyRKWKdTaKi1sV/ztFurjRV0W9Mr1565/A1eGZMcc6ghdaGnwR5e
CyUKbrSyCUNmfNK4boRse60hujwTajuFWSvKMSZaCWqeKHOKDnaOVmRb2zoi
dc1wk9bxptTZpLSS1hjSrfe9t2e3Cz2x+oYWZdMGykWt12lkKcPalon1qHaK
zlUmyp2tDg4nn35un3T+0Yf+/0CGAfKk1Zrsw1z1bTTlG3WFK7sCq1OEUrUS
tljFtnetG8JnZXFaOQG588OY79OiJqgOFF8GcdZwTfGeDDDkJ1Fz393vzfc5
lWW7sxQUFCYvd50GttiHV5aq6XShmsvqve1kEKVTInHj7JbtWIN21j+SSnfo
t3P2Cx7KA0IxsClQl06t13RUozGNs2IlaPadIy3h3DmoYp1WG+oLY6zsAZiu
Lw6Gh/z8u9NTPhp7fezRgLP2CCq6l6uz7uqc70vuZad3dh6GYecbbJ7xvY2m
ATGPrAEr/QMcMSKc6TQd26qWeE83F4cmN2sA/J1S19Ow0oKGRuSonB1yoOO6
170PnW/vG3DkNGsqWGd0d1U1CUVVxjrPUOu8q2T0svcOsndJmLwrepd9cTXS
4urusv+ueHPZv5uN/nmrLtb9rr1cav8Og9u0evbMqrf4049/+Ye1WPUto8F4
QH2WVgDKnly0PV007vyogVEiE/6G7unw2FTKJYqhI7d81qdYVA/Fost8ZNwZ
AbMmOHKKjMzdIdBi2e6hOJVw3WF/+PmXl/bc3H/9ervdhuRWmJfL13Q9tszs
Weh16gxUF4onf3RdBiB8FRz9vTryeDj0FaZ/ee4TBeIL3XXa8zAep44LX/D+
QS6gQ3SKx5jfYvV2p+5/tBJB4h7lZ/fQjtBvu7rvz/5/q1cttozWtvVo05Xa
axnRbWTj5ZNrQ55XKV+cQLvHx6Nd+VN9k7UvS9mOdj+9HjZP+CGvzoP2pjOW
hbQHUic0qLX2W1Vha91FySBpcgapOVSx7S33ZdZeKRCC+4srKiT52jCIlSy3
iu48JXqe6oLD26VMU3Q8bdXah4fp6M/NIdUFIOqGWuxoiJvkHA7ZfwCvNslj
+RcAAA==

-->

</rfc>
