rfc9540.original.xml		rfc9540.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
	<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2 ) -->		<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.1 (Ruby 3.2.2 ) -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-ohai-svcb-config-07" category="std" consensus="true" submissionType="IETF"		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	tocInclude="true" sortRefs="true" symRefs="true" version="3">		-ietf-ohai-svcb-config-07" number="9540" submissionType="IETF" category="std" co
			nsensus="true" tocInclude="true" sortRefs="true" symRefs="true"
			updates="" obsoletes="" xml:lang="en" version="3">
	<!-- xml2rfc v2v3 conversion 3.18.1 -->		<!-- xml2rfc v2v3 conversion 3.18.1 -->
	<front>		<front>
	<title abbrev="Oblivious Services in SVCB">Discovery of Oblivious Services v ia Service Binding Records</title>		<title abbrev="Oblivious Services in SVCB">Discovery of Oblivious Services v ia Service Binding Records</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-svcb-config-07"/>		<seriesInfo name="RFC" value="9540"/>
	<author initials="T." surname="Pauly" fullname="Tommy Pauly">		<author initials="T." surname="Pauly" fullname="Tommy Pauly">
	<organization>Apple Inc.</organization>		<organization>Apple Inc.</organization>
	<address>		<address>
	<email>tpauly@apple.com</email>		<email>tpauly@apple.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">		<author initials="T." surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
	<organization>Nokia</organization>		<organization>Nokia</organization>
	<address>		<address>
	<email>kondtir@gmail.com</email>		<email>kondtir@gmail.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2023" month="October" day="06"/>		<date year="2024" month="February"/>
	<area>Security</area>		<area>sec</area>
	<workgroup>Oblivious HTTP Application Intermediation</workgroup>		<workgroup>ohai</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	<?line 35?>
	<t>This document defines a parameter that can be included in SVCB and HTTPS		<keyword>DNS</keyword>
			<keyword>Oblivious HTTP</keyword>
			<keyword>SVCB</keyword>
			<abstract>
			<t>This document defines a parameter that can be included in Service Binding (SV
			CB) and HTTPS
	DNS resource records to denote that a service is accessible using Oblivious		DNS resource records to denote that a service is accessible using Oblivious
	HTTP, by offering an Oblivious Gateway Resource through which to access the		HTTP, by offering an Oblivious Gateway Resource through which to access the
	target. This document also defines a mechanism to learn the key configuration		target. This document also defines a mechanism for learning the key configuratio n
	of the discovered Oblivious Gateway Resource.</t>		of the discovered Oblivious Gateway Resource.</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>About This Document</name>
	<t>
	Status information for this document may be found at <eref target="https
	://datatracker.ietf.org/doc/draft-ietf-ohai-svcb-config/"/>.
	</t>
	<t>
	Discussion of this document takes place on the
	Oblivious HTTP Application Intermediation Working Group mailing list (<e
	ref target="mailto:ohai@ietf.org"/>),
	which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
	wse/ohai/"/>.
	Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/ohai/"/
	>.
	</t>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/ietf-wg-ohai/draft-ohai-svcb-config"/>.
	</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<?line 43?>
	<section anchor="introduction">		<section anchor="introduction">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Oblivious HTTP <xref target="OHTTP"/> allows clients to encrypt		<t>Oblivious HTTP <xref target="RFC9458"/> allows clients to encrypt
	messages exchanged with an Oblivious Target Resource (target). The messages		messages exchanged with an Oblivious Target Resource (target). The messages
	are encapsulated in encrypted messages to an Oblivious Gateway Resource		are encapsulated in encrypted messages to an Oblivious Gateway Resource
	(gateway), which offers Oblivious HTTP access to the target. The gateway is		(gateway), which offers Oblivious HTTP access to the target. The gateway is
	accessed via an Oblivious Relay Resource (relay), which proxies the encapsulated		accessed via an Oblivious Relay Resource (relay), which proxies the encapsulated
	messages to hide the identity of the client. Overall, this architecture is		messages to hide the identity of the client. Overall, this architecture is
	designed in such a way that the relay cannot inspect the contents of messages,		designed in such a way that the relay cannot inspect the contents of messages,
	and the gateway and target cannot learn the client's identity from a single		and the gateway and target cannot learn the client's identity from a single
	transaction.</t>		transaction.</t>
	<t>Since Oblivious HTTP deployments typically involve very specific coordi nation		<t>Since Oblivious HTTP deployments typically involve very specific coordi nation
	between clients, relays, and gateways, the key configuration is often shared		between clients, relays, and gateways, the key configuration is often shared
	in a bespoke fashion. However, some deployments involve clients		in a bespoke fashion. However, some deployments involve clients
	discovering targets and their associated gateways more dynamically.		discovering targets and their associated gateways more dynamically.
	For example, a network might operate a DNS resolver that provides more optimized		For example, a network might operate a DNS resolver that provides more optimized
	or more relevant DNS answers and is accessible using Oblivious HTTP, and might		or more relevant DNS answers and is accessible using Oblivious HTTP, and might
	want to advertise support for Oblivious HTTP via mechanisms like Discovery of		want to advertise support for Oblivious HTTP via mechanisms like Discovery of
	Designated Resolvers (<xref target="DDR"/>) and		Designated Resolvers <xref target="RFC9462"/> and
	Discovery of Network-designated Resolvers (<xref target="DNR"/>).		Discovery of Network-designated Resolvers <xref target="RFC9463"/>.
	Clients can access these gateways through trusted relays.</t>		Clients can access these gateways through trusted relays.</t>
	<t>This document defines a way to use DNS resource records (RRs) to advert ise that an HTTP		<t>This document defines a way to use DNS resource records (RRs) to advert ise that an HTTP
	service supports Oblivious HTTP. This advertisement is a parameter that can be i ncluded in		service supports Oblivious HTTP. This advertisement is a parameter that can be i ncluded in
	SVCB and HTTPS DNS RRs <xref target="SVCB"/> (<xref target="svc-param"/>).		Service Binding (SVCB) and HTTPS DNS RRs <xref target="RFC9460"/> (<xref target= "svc-param"/>).
	The presence of this parameter indicates that a service can act as a target and		The presence of this parameter indicates that a service can act as a target and
	has a gateway that can provide access to the target.</t>		has a gateway that can provide access to the target.</t>
	<t>The client learns the URI to use for the gateway using a well-known		<t>The client learns the URI to use for the gateway using a well-known
	URI suffix <xref target="WELLKNOWN"/>, "ohttp-gateway", which is accessed on		URI suffix <xref target="RFC8615"/>, "ohttp-gateway", which is accessed on
	the target (<xref target="gateway-location"/>). This means that for deployments that		the target (<xref target="gateway-location"/>). This means that for deployments that
	support this kind of discovery, the gateway and target resources need to		support this kind of discovery, the Gateway and Target Resources need to
	be located on the same host.</t>		be located on the same host.</t>
	<t>This document also defines a way to fetch a gateway's key		<t>This document also defines a way to fetch a gateway's key
	configuration from the gateway (<xref target="config-fetch"/>).</t>		configuration from the gateway (<xref target="config-fetch"/>).</t>
	<t>This mechanism does not aid in the discovery of relays;		<t>This mechanism does not aid in the discovery of relays;
	relay configuration is out of scope for this document. Models in which		relay configuration is out of scope for this document. Models in which
	this discovery mechanism is applicable are described in <xref target="applicabil ity"/>.</t>		this discovery mechanism is applicable are described in <xref target="applicabil ity"/>.</t>
	</section>		</section>
	<section anchor="conventions-and-definitions">		<section anchor="conventions-and-definitions">
	<name>Conventions and Definitions</name>		<name>Conventions and Definitions</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL		"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO		"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",		"<bcp14>SHOULD NOT</bcp14>",
	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i		"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nterpreted as		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and		are to be interpreted as described in BCP&nbsp;14
	only when, they		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
	appear in all capitals, as shown here.</t>		when, they appear in all capitals, as shown here.</t>
	<?line -18?>
	</section>		</section>
	<section anchor="applicability">		<section anchor="applicability">
	<name>Applicability</name>		<name>Applicability</name>
	<t>There are multiple models in which the discovery mechanism defined		<t>There are multiple models in which the discovery mechanism defined
	in this document can be used.</t>		in this document can be used. These include:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Upgrading regular (non-proxied) HTTP to Oblivious HTTP. In this mod el,		<t>Upgrading regular (non-proxied) HTTP to Oblivious HTTP. In this mod el,
	the client intends to communicate with a specific target service, and		the client intends to communicate with a specific target service and
	prefers to use Oblivious HTTP if it is available. The target service		prefers to use Oblivious HTTP if it is available. The target service
	has a gateway that it offers to allow access using Oblivious		has a gateway that it offers to allow access using Oblivious
	HTTP. Once the client learns about the gateway, it "upgrades"		HTTP. Once the client learns about the gateway, it "upgrades"
	its requests from non-proxied HTTP to Oblivious HTTP to access		its requests from non-proxied HTTP to Oblivious HTTP to access
	the target service.</t>		the target service.</t>
	</li>		</li>
	<li>		<li>
	<t>Discovering alternative Oblivious HTTP services. In this model,		<t>Discovering alternative Oblivious HTTP services. In this model,
	the client has a default target service that it uses. For		the client has a default target service that it uses. For
	example, this may be a public DNS resolver that is accessible over		example, this may be a public DNS resolver that is accessible over
	Oblivious HTTP. The client is willing to use alternative		Oblivious HTTP. The client is willing to use alternative
	target services if they are discovered, which may provide more		target services if they are discovered, which may provide more
	optimized or more relevant responses.</t>		optimized or more relevant responses.</t>
	</li>		</li>
	</ul>		</ul>
	<t>In both deployment models, the client is configured with		<t>In both of these deployment models, the client is configured with
	a relay that it trusts for Oblivious HTTP transactions. This		a relay that it trusts for Oblivious HTTP transactions. This
	relay either needs to provide generic access to gateways, or		relay needs to provide either (1)&nbsp;generic access to gateways or
	provide a service to clients to allow them to check which gateways		(2)&nbsp;a service to clients to allow them to check which gateways
	are accessible.</t>		are accessible.</t>
	</section>		</section>
	<section anchor="svc-param">		<section anchor="svc-param">
	<name>The ohttp SvcParamKey</name>		<name>The &quot;ohttp&quot; SvcParamKey</name>
	<t>The "ohttp" SvcParamKey is used to indicate that a		<t>The "ohttp" SvcParamKey is used to indicate that a
	service described in an SVCB RR can be accessed as a target		service described in a SVCB RR can be accessed as a target
	using an associated gateway. The service that is queried by the client hosts		using an associated gateway. The service that is queried by the client hosts
	one or more target resources.</t>		one or more Target Resources.</t>
	<t>In order to access the service's target resources using Oblivious HTTP,		<t>In order to access the service's Target Resources using Oblivious HTTP,
	the client		the client
	needs to send encapsulated messages to the gateway resource and the gateway's		needs to send encapsulated messages to the Gateway Resource and the gateway's
	key configuration (both of which can be retrieved using the method described in		key configuration (both of which can be retrieved using the method described in
	<xref target="config-fetch"/>).</t>		<xref target="config-fetch"/>).</t>
	<t>Both the presentation and wire format values for the "ohttp" parameter		<t>Both the presentation and wire-format values for the "ohttp" parameter
	<bcp14>MUST</bcp14> be empty.</t>		<bcp14>MUST</bcp14> be empty.</t>
	<t>Services can include the "ohttp" parameter in the mandatory parameter		<t>Services can include the "ohttp" parameter in the mandatory parameter
	list if the service is only accessible using Oblivious HTTP. Marking		list if the service is only accessible using Oblivious HTTP. Marking
	the "ohttp" parameter as mandatory will cause clients that do not		the "ohttp" parameter as mandatory will cause clients that do not
	understand the parameter to ignore that SVCB RR.		understand the parameter to ignore that SVCB RR.
	Including the "ohttp" parameter without marking it mandatory advertises		Including the "ohttp" parameter without marking it mandatory advertises
	a service that is optionally available using Oblivious HTTP. Note also		a service that is optionally available using Oblivious HTTP. Note also
	that multiple SVCB RRs can be provided to indicate separate		that multiple SVCB RRs can be provided to indicate separate
	configurations.</t>		configurations.</t>
	<t>The media type to use for encapsulated requests made to a target servic e		<t>The media type to use for encapsulated requests made to a target servic e
	depends on the scheme of the SVCB RR. This document defines the		depends on the scheme of the SVCB RR. This document defines the
	interpretation for the "https" <xref target="SVCB"/> and "dns" <xref target="DNS		interpretation for the "https" scheme <xref target="RFC9460"/> and the "dns" sch
	-SVCB"/>		eme <xref target="RFC9461"/>. Other schemes that want to use this parameter <bcp
	schemes. Other schemes that want to use this parameter <bcp14>MUST</bcp14> defin		14>MUST</bcp14> define the
	e the
	interpretation and meaning of the configuration.</t>		interpretation and meaning of the configuration.</t>
	<section anchor="use-in-https-service-rrs">		<section anchor="use-in-https-service-rrs">
	<name>Use in HTTPS service RRs</name>		<name>Use in HTTPS Service RRs</name>
	<t>For the "https" scheme, which uses the HTTPS RR type instead of SVCB,		<t>For the "https" scheme, which uses the HTTPS RR type instead of SVCB,
	the presence of the "ohttp" parameter means that the target		the presence of the "ohttp" parameter means that the target
	being described is an Oblivious HTTP service that is accessible using		being described is an Oblivious HTTP service that is accessible using
	the default "message/bhttp" media type <xref target="OHTTP"/>		the default "message/bhttp" media type <xref target="RFC9458"/>
	<xref target="BINARY-HTTP"/>.</t>		<xref target="RFC9292"/>.</t>
	<t>For example, an HTTPS service RR for svc.example.com that supports		<t>For example, an HTTPS service RR for svc.example.com that supports
	Oblivious HTTP could look like this:</t>		Oblivious HTTP could look like this:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	svc.example.com. 7200 IN HTTPS 1 . ( alpn=h2 ohttp )		svc.example.com. 7200 IN HTTPS 1 . ( alpn=h2 ohttp )
	]]></artwork>		]]></artwork>
	<t>A similar RR for a service that only supports Oblivious HTTP		<t>A similar RR for a service that only supports Oblivious HTTP
	could look like this:</t>		could look like this:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	svc.example.com. 7200 IN HTTPS 1 . ( mandatory=ohttp ohttp )		svc.example.com. 7200 IN HTTPS 1 . ( mandatory=ohttp ohttp )
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="use-in-dns-server-svcb-rrs">		<section anchor="use-in-dns-server-svcb-rrs">
	<name>Use in DNS server SVCB RRs</name>		<name>Use in DNS Server SVCB RRs</name>
	<t>For the "dns" scheme, as defined in <xref target="DNS-SVCB"/>, the pr		<t>For the "dns" scheme, as defined in <xref target="RFC9461"/>, the pre
	esence of		sence of
	the "ohttp" parameter means that the DNS server being		the "ohttp" parameter means that the DNS server being
	described has a DNS over HTTP (DoH) <xref target="DOH"/> service that can		described has a DNS-over-HTTPS (DoH) service <xref target="RFC8484"/> that can
	be accessed using Oblivious HTTP. Requests to the resolver are sent to		be accessed using Oblivious HTTP. Requests to the resolver are sent to
	the gateway using binary HTTP with the default "message/bhttp"		the gateway using binary HTTP with the default "message/bhttp"
	media type <xref target="BINARY-HTTP"/>, containing inner requests that use the		media type <xref target="RFC9292"/>, containing inner requests that use the
	"application/dns-message" media type <xref target="DOH"/>.</t>		"application/dns-message" media type <xref target="RFC8484"/>.</t>
	<t>If the "ohttp" parameter is included in an DNS server SVCB RR,		<t>If the "ohttp" parameter is included in a DNS server SVCB RR,
	the "alpn" <bcp14>MUST</bcp14> include at least one HTTP value (such as "h2" or		the "alpn" parameter <bcp14>MUST</bcp14> include at least one HTTP value (such a
			s "h2" or
	"h3").</t>		"h3").</t>
	<t>In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, their		<t>In order for DoH-capable recursive resolvers to function as Oblivious HTTP targets, their
	associated gateways need to be accessible via a client-trusted relay.		associated gateways need to be accessible via a client-trusted relay.
	DoH recursive resolvers used with the discovery mechanisms described		DoH recursive resolvers used with the discovery mechanisms described
	in this section can either be publicly accessible, or specific to a		in this section can be either publicly accessible or specific to a
	network. In general, only publicly accessible DoH recursive resolvers will work		network. In general, only publicly accessible DoH recursive resolvers will work
	as Oblivious HTTP targets, unless there is a coordinated deployment		as Oblivious HTTP targets, unless there is a coordinated deployment
	with a relay to access the network-specific DoH recursive resolvers.</t>		with a relay to access the network-specific DoH recursive resolvers.</t>
	<section anchor="ddr">		<section anchor="ddr">
	<name>Use with DDR</name>		<name>Use with DDR</name>
	<t>Clients can discover that a DoH recursive resolvers support Oblivio		<t>Clients can discover that a DoH recursive resolver supports Oblivio
	us HTTP using		us HTTP using
	DDR, either by querying _dns.resolver.arpa to a locally configured		DDR, by either querying _dns.resolver.arpa to a locally configured
	resolver or by querying using the name of a resolver <xref target="DDR"/>.</t>		resolver or querying using the name of a resolver <xref target="RFC9462"/>.</t>
	<t>For example, a DoH service advertised over DDR can be annotated		<t>For example, a DoH service advertised over DDR can be annotated
	as supporting resolution via Oblivious HTTP using the following RR:</t>		as supporting resolution via Oblivious HTTP using the following RR:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	_dns.resolver.arpa 7200 IN SVCB 1 doh.example.net (		_dns.resolver.arpa 7200 IN SVCB 1 doh.example.net (
	alpn=h2 dohpath=/dns-query{?dns} ohttp )		alpn=h2 dohpath=/dns-query{?dns} ohttp )
	]]></artwork>		]]></artwork>
	<t>Clients still need to perform verification of oblivious DoH servers		<t>Clients still need to perform verification of oblivious DoH servers
	,		--
	specifically the TLS certificate checks described in <xref section="4.2" section		specifically, the TLS certificate checks described in <xref section="4.2" sectio
	Format="of" target="DDR"/>.		nFormat="of" target="RFC9462"/>.
	Since the gateway and target resources for discovered oblivious services		Since the Gateway and Target Resources for discovered oblivious services
	need to be on the same host, this means that the client needs to verify		need to be on the same host, this means that the client needs to verify
	that the certificate presented by the gateway passes the required checks.		that the certificate presented by the gateway passes the required checks.
	These checks can be performed when looking up the configuration on the gateway		These checks can be performed when looking up the configuration on the gateway
	as described in <xref target="config-fetch"/>, which can either be done directly		as described in <xref target="config-fetch"/> and can be done either directly
	or via the relay or another proxy to avoid exposing client IP addresses.</t>		or via the relay or another proxy to avoid exposing client IP addresses.</t>
	<t>Opportunistic discovery <xref target="DDR"/>, where only the IP add ress is validated,		<t>Opportunistic Discovery <xref target="RFC9462"/>, where only the IP address is validated,
	<bcp14>SHOULD NOT</bcp14> be used in general with Oblivious HTTP, since this mod e		<bcp14>SHOULD NOT</bcp14> be used in general with Oblivious HTTP, since this mod e
	primarily exists to support resolvers that use private or local IP		primarily exists to support resolvers that use private or local IP
	addresses, which will usually not be accessible when using a		addresses, which will usually not be accessible when using a
	relay. If a configuration occurs where the resolver is accessible, but		relay. If a configuration occurs where the resolver is accessible but
	cannot use certificate-based validation, the client <bcp14>MUST</bcp14> ensure		cannot use certificate-based validation, the client <bcp14>MUST</bcp14> ensure
	that the relay only accesses the gateway and target using		that the relay only accesses the gateway and target using
	the unencrypted resolver's original IP address.</t>		the unencrypted resolver's original IP address.</t>
	<t>For the case of DoH recursive resolvers, clients also need to ensur e that they are not		<t>For the case of DoH recursive resolvers, clients also need to ensur e that they are not
	being targeted with unique DoH paths that would reveal their identity. See		being targeted with unique DoH paths that would reveal their identity. See
	<xref target="security"/> for more discussion.</t>		<xref target="security"/> for more discussion.</t>
	</section>		</section>
	<section anchor="dnr">		<section anchor="dnr">
	<name>Use with DNR</name>		<name>Use with DNR</name>
	<t>The SvcParamKeys defined in this document also can be used with Dis		<t>The SvcParamKey defined in this document also can be used with Disc
	covery		overy
	of Network-designated Resolvers (DNR) <xref target="DNR"/>. In this		of Network-designated Resolvers <xref target="RFC9463"/>. In this
	case, the oblivious configuration and path parameters can be included		case, the oblivious configuration and path parameters can be included
	in DHCP and Router Advertisement messages.</t>		in DHCP and Router Advertisement messages.</t>
	<t>While DNR does not require the same kind of verification as DDR, cl ients		<t>While DNR does not require the same kind of verification as DDR, cl ients
	that learn about DoH recursive resolvers still need to ensure that they are not being		that learn about DoH recursive resolvers still need to ensure that they are not being
	targeted with unique DoH paths that would reveal their identity. See <xref targe t="security"/>		targeted with unique DoH paths that would reveal their identity. See <xref targe t="security"/>
	for more discussion.</t>		for more discussion.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="gateway-location">		<section anchor="gateway-location">
	<name>Gateway Location</name>		<name>Gateway Location</name>
	<t>Once a client has discovered that a service supports Oblivious HTTP		<t>Once a client has discovered that a service supports Oblivious HTTP
	via the "ohttp" parameter in a SVCB or HTTPS RR, it needs to be		via the "ohttp" parameter in a SVCB or HTTPS RR, it needs to be
	able to send requests via a relay to the correct gateway location.</t>		able to send requests via a relay to the correct gateway location.</t>
	<t>This document defines a well-known resource (<xref target="WELLKNOWN"/> ),		<t>This document defines a well-known resource <xref target="RFC8615"/>,
	"/.well-known/ohttp-gateway", which is an Oblivious Gateway Resource		"/.well-known/ohttp-gateway", which is an Oblivious Gateway Resource
	available on the same host as the target resource.</t>		available on the same host as the Target Resource.</t>
	<t>Some servers might not want to operate the gateway on a well-known URI.		<t>Some servers might not want to operate the gateway on a well-known URI.
	In such cases, these servers can use 3xx redirection responses		In such cases, these servers can use 3xx (Redirection) responses
	(<xref section="15.4" sectionFormat="of" target="HTTP"/>) to direct clients and		(<xref section="15.4" sectionFormat="of" target="RFC9110"/>) to direct clients a
	relays to the correct		nd relays to the correct
	location of the gateway. Such redirects would apply both to requests		location of the gateway. Such redirects would apply to both (1)&nbsp;requests
	made to fetch key configurations (as defined in <xref target="config-fetch"/>) a		made to fetch key configurations (as defined in <xref target="config-fetch"/>) a
	nd to		nd
	encapsulated requests made via a relay.</t>		(2)&nbsp;encapsulated requests made via a relay.</t>
	<t>If a client receives a redirect when fetching the key configuration fro m the		<t>If a client receives a redirect when fetching the key configuration fro m the
	well-known gateway resource, it <bcp14>MUST NOT</bcp14> communicate the redirect ed		well-known Gateway Resource, it <bcp14>MUST NOT</bcp14> communicate the redirect ed
	gateway URI to the relay as the location of the gateway to use.		gateway URI to the relay as the location of the gateway to use.
	Doing so would allow the gateway to target clients by encoding		Doing so would allow the gateway to target clients by encoding
	unique or client-identifying values in the redirected URI. Instead,		unique or client-identifying values in the redirected URI. Instead,
	relays being used with dynamically discovered gateways <bcp14>MUST</bcp14> use t he		relays being used with dynamically discovered gateways <bcp14>MUST</bcp14> use t he
	well-known gateway resource and follow any redirects independently of		well-known Gateway Resource and follow any redirects independently of
	redirects that clients received. The relay can remember such redirects		redirects that clients received. The relay can remember such redirects
	across oblivious requests for all clients in order to avoid added latency.</t>		across oblivious requests for all clients in order to avoid added latency.</t>
	</section>		</section>
	<section anchor="config-fetch">		<section anchor="config-fetch">
	<name>Key Configuration Fetching</name>		<name>Key Configuration Fetching</name>
	<t>Clients also need to know the key configuration of a gateway before enc apsulating		<t>Clients also need to know the key configuration of a gateway before enc apsulating
	and sending requests to the relay.</t>		and sending requests to the relay.</t>
	<t>If a client fetches the key configuration directly from the gateway, it		<t>If a client fetches the key configuration directly from the gateway, it
	will expose identifiers like a client IP address to the gateway. The		will expose identifiers like a client IP address to the gateway. The
	privacy and security implications of fetching the key configuration are		privacy and security implications of fetching the key configuration are
	discussed more in <xref target="security"/>. Clients can use an HTTP proxy to		discussed more in <xref target="security"/>. Clients can use an HTTP proxy to
	hide their IP addresses when fetching key configurations. Clients can		hide their IP addresses when fetching key configurations. Clients can
	also perform consistency checks to validate that they are not receiving		also perform consistency checks to validate that they are not receiving
	unique key configurations, as discussed in <xref target="consistency"/>.</t>		unique key configurations, as discussed in <xref target="consistency"/>.</t>
	<t>In order to fetch the key configuration of a gateway discovered		<t>In order to fetch the key configuration of a gateway discovered
	in the manner described in <xref target="gateway-location"/>, the client issues a GET request		in the manner described in <xref target="gateway-location"/>, the client issues a GET request
	(either through a proxy or directly) to the URI of the gateway specifying		(either through a proxy or directly) to the URI of the gateway specifying
	the "application/ohttp-keys" (<xref target="OHTTP"/>) media type in the Accept h		the "application/ohttp-keys" media type <xref target="RFC9458"/> in the Accept h
	eader.</t>		eader.</t>
	<t>For example, if the client knows an oblivious gateway URI,		<t>For example, if the client knows an Oblivious Gateway URI,
	"https://svc.example.com/.well-known/ohttp-gateway", it could fetch the		https://svc.example.com/.well-known/ohttp-gateway, it could fetch the
	key configuration with the following request:</t>		key configuration with the following request:</t>
	<artwork><![CDATA[		<artwork><![CDATA[
	GET /.well-known/ohttp-gateway HTTP/1.1		GET /.well-known/ohttp-gateway HTTP/1.1
	Host: svc.example.com		Host: svc.example.com
	Accept: application/ohttp-keys		Accept: application/ohttp-keys
	]]></artwork>		]]></artwork>
	<t>Gateways that coordinate with targets that advertise Oblivious HTTP		<t>Gateways that coordinate with targets that advertise Oblivious HTTP
	support <bcp14>SHOULD</bcp14> support GET requests for their key configuration i n this		support <bcp14>SHOULD</bcp14> support GET requests for their key configuration i n this
	manner, unless there is another out-of-band configuration model that is		manner, unless there is another out-of-band configuration model that is
	usable by clients. Gateways respond with their key configuration in the		usable by clients. Gateways respond with their key configuration in the
	response body, with a content type of "application/ohttp-keys".</t>		response body, with a content type of "application/ohttp-keys".</t>
	</section>		</section>
	<section anchor="security">		<section anchor="security">
	<name>Security and Privacy Considerations</name>		<name>Security and Privacy Considerations</name>
	<t>Attackers on a network can remove SVCB information from cleartext DNS		<t>Attackers on a network can remove SVCB information from cleartext DNS
	answers that are not protected by DNSSEC <xref target="DNSSEC"/>. This		answers that are not protected by DNSSEC <xref target="RFC4033"/>. This
	can effectively downgrade clients. However, since SVCB indications		can effectively downgrade clients. However, since SVCB indications
	for Oblivious HTTP support are just hints, a client can mitigate this by		for Oblivious HTTP support are just hints, a client can mitigate this by
	always checking for a gateway configuration (<xref target="config-fetch"/>)		always checking for a gateway configuration (<xref target="config-fetch"/>)
	on the well-known gateway location (<xref target="gateway-location"/>).		on the well-known gateway location (<xref target="gateway-location"/>).
	Use of encrypted DNS along with DNSSEC can also be used as a mitigation.</t>		Using encrypted DNS along with DNSSEC can also provide such a mitigation.</t>
	<t>When clients fetch a gateway's configuration (<xref target="config-fetc h"/>),		<t>When clients fetch a gateway's configuration (<xref target="config-fetc h"/>),
	they can expose their identity in the form of an IP address if they do not		they can expose their identity in the form of an IP address if they do not
	connect via a proxy or some other IP-hiding mechanism. In some circumstances,		connect via a proxy or some other IP-hiding mechanism. In some circumstances,
	this might not be a privacy concern, since revealing that a particular		this might not be a privacy concern, since revealing that a particular
	client IP address is preparing to use an Oblivious HTTP service can be		client IP address is preparing to use an Oblivious HTTP service can be
	expected. However, if a client is otherwise trying to hide its IP		expected. However, if a client is otherwise trying to hide its IP
	address or location (and not merely decouple its specific requests from its		address or location (and not merely decouple its specific requests from its
	IP address), or if revealing its IP address facilitates key targeting attacks		IP address), or if revealing its IP address facilitates key targeting attacks
	(if a gateway service uses IP addresses to associate specific configurations		(if a gateway service uses IP addresses to associate specific configurations
	with specific clients), a proxy or similar mechanism can be used to fetch		with specific clients), a proxy or similar mechanism can be used to fetch
	the gateway's configuration.</t>		the gateway's configuration.</t>
	<t>When discovering designated oblivious DoH recursive resolvers using thi s mechanism,		<t>When discovering designated oblivious DoH recursive resolvers using thi s mechanism,
	clients need to ensure that the designation is trusted in lieu of		clients need to ensure that the designation is trusted in lieu of
	being able to directly check the contents of the gateway server's TLS		being able to directly check the contents of the gateway server's TLS
	certificate. See <xref target="ddr"/> for more discussion, as well as the Securi		certificate. See <xref target="ddr"/> for more discussion, as well as Section&nb
	ty		sp;<xref target="RFC9461" section="8"
	Considerations of <xref target="DNS-SVCB"/>.</t>		sectionFormat="bare">"Security Considerations"</xref> of <xref target="RFC9461"/
			>.</t>
	<section anchor="consistency">		<section anchor="consistency">
	<name>Key Targeting Attacks</name>		<name>Key Targeting Attacks</name>
	<t>As discussed in <xref target="OHTTP"/>, client requests using Oblivio us HTTP		<t>As discussed in <xref target="RFC9458"/>, client requests using Obliv ious HTTP
	can only be linked by recognizing the key configuration. In order to		can only be linked by recognizing the key configuration. In order to
	prevent unwanted linkability and tracking, clients using any key		prevent unwanted linkability and tracking, clients using any key
	configuration discovery mechanism need to be concerned with attacks		configuration discovery mechanism need to be concerned with attacks
	that target a specific user or population with a unique key configuration.</t>		that target a specific user or population with a unique key configuration.</t>
	<t>There are several approaches clients can use to mitigate key targetin g		<t>There are several approaches clients can use to mitigate key targetin g
	attacks. <xref target="CONSISTENCY"/> provides an overview		attacks. <xref target="I-D.ietf-privacypass-key-consistency"/> provides an overv
	of the options for ensuring the key configurations are consistent between		iew
			of the options for ensuring that the key configurations are consistent between
	different clients. Clients <bcp14>SHOULD</bcp14> employ some technique to mitiga te key		different clients. Clients <bcp14>SHOULD</bcp14> employ some technique to mitiga te key
	targeting attacks, such as the option of confirming the key with a shared		targeting attacks, such as the option of confirming the key with a shared
	proxy as described in <xref target="CONSISTENCY"/>. If a client detects that a g ateway		proxy as described in <xref target="I-D.ietf-privacypass-key-consistency"/>. If a client detects that a gateway
	is using per-client targeted key configuration, the client can stop using		is using per-client targeted key configuration, the client can stop using
	the gateway, and potentially report the targeting attack to let other		the gateway and, potentially, report the targeting attack so that other
	clients avoid using this gateway in the future.</t>		clients can avoid using this gateway in the future.</t>
	</section>		</section>
	<section anchor="dohpath-targeting-attacks">		<section anchor="dohpath-targeting-attacks">
	<name>dohpath Targeting Attacks</name>		<name>dohpath Targeting Attacks</name>
	<t>For oblivious DoH servers, an attacker could use unique <tt>dohpath</ tt> values		<t>For oblivious DoH servers, an attacker could use unique <tt>"dohpath" </tt> values
	to target or identify specific clients. This attack is very similar to		to target or identify specific clients. This attack is very similar to
	the generic OHTTP key targeting attack described above.</t>		the generic OHTTP key targeting attack described above.</t>
	<t>A client can avoid these targeting attacks by only allowing a single		<t>A client can avoid these targeting attacks by only allowing a single
	<tt>dohpath</tt> value, such as the commonly used "/dns-query{?dns}" or		<tt>"dohpath"</tt> value, such as the commonly used "/dns-query{?dns}" or
	another pre-known value. If the client allows arbitrary <tt>dohpath</tt>		another pre-known value. If the client allows arbitrary <tt>"dohpath"</tt>
	values, it <bcp14>SHOULD</bcp14> mitigate targeting attacks with a consistency c heck,		values, it <bcp14>SHOULD</bcp14> mitigate targeting attacks with a consistency c heck,
	such as using a mechanism described in <xref target="CONSISTENCY"/> to validate		such as using one of the mechanisms described in <xref target="I-D.ietf-privacyp
	the		ass-key-consistency"/> to validate the
	<tt>dohpath</tt> value with another source. Clients might choose to only		<tt>"dohpath"</tt> value with another source. Clients might choose to only
	employ a consistency check on a percentage of discovery events,		employ a consistency check on a percentage of discovery events,
	depending on the capacity of consistency check options and their		depending on the capacity of consistency check options and their
	deployment threat model.</t>		deployment threat model.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="iana">		<section anchor="iana">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<section anchor="svcb-service-parameter">		<section anchor="svcb-service-parameter">
	<name>SVCB Service Parameter</name>		<name>SVCB Service Parameter</name>
	<t>This document adds the following entry to the SVCB Service Parameters		<t>This document adds the following entry to the "Service Parameter Keys
	registry (<xref target="SVCB"/>). The definition of this parameter is in <xref t		(SvcParamKeys)" registry <xref target="RFC9460"/>. This parameter is defined in
	arget="svc-param"/>.</t>		<xref target="svc-param"/>.</t>
	<table>		<table>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Number</th>		<th align="left">Number</th>
	<th align="left">Name</th>		<th align="left">Name</th>
	<th align="left">Meaning</th>		<th align="left">Meaning</th>
			<th align="left"> Change Controller</th>
	<th align="left">Reference</th>		<th align="left">Reference</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">8 (Early Allocation)</td>		<td align="left">8</td>
	<td align="left">ohttp</td>		<td align="left">ohttp</td>
	<td align="left">Denotes that a service operates an Oblivious HTTP target</td>		<td align="left">Denotes that a service operates an Oblivious HTTP target</td>
	<td align="left">(This document)</td>		<td align="left">IETF</td>
			<td align="left">RFC 9540, <xref target="svc-param"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	<section anchor="well-known-uri">		<section anchor="well-known-uri">
	<name>Well-Known URI</name>		<name>Well-Known URI</name>
	<t>IANA is requested to add one new entry in the "Well-Known URIs" regis		<t>IANA has added one entry in the "Well-Known URIs" registry <xref targ
	try <xref target="WELLKNOWN"/>.</t>		et="RFC8615"/>.</t>
	<t>URI suffix: ohttp-gateway</t>		<dl newline="false">
	<t>Change controller: IETF</t>		<dt>URI Suffix:</dt><dd>ohttp-gateway</dd>
	<t>Specification document: This document</t>		<dt>Change Controller:</dt><dd>IETF</dd>
	<t>Status: permanent</t>		<dt>Reference:</dt><dd>RFC 9540</dd>
	<t>Related information: N/A</t>		<dt>Status:</dt><dd>permanent</dd>
			<dt>Related Information:</dt><dd>N/A</dd>
			</dl>
	</section>		</section>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="RFC9458" to="OHTTP"/>
			<displayreference target="RFC9462" to="DDR"/>
			<displayreference target="RFC9463" to="DNR"/>
			<displayreference target="RFC9460" to="SVCB"/>
			<displayreference target="RFC8615" to="WELLKNOWN"/>
			<displayreference target="RFC9461" to="DNS-SVCB"/>
			<displayreference target="RFC9292" to="BINARY-HTTP"/>
			<displayreference target="RFC8484" to="DOH"/>
			<displayreference target="RFC9110" to="HTTP"/>
			<displayreference target="RFC4033" to="DNSSEC"/>
			<displayreference target="I-D.ietf-privacypass-key-consistency" to="CONSISTENCY"
			/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references anchor="sec-normative-references">		<references anchor="sec-normative-references">
	<name>Normative References</name>		<name>Normative References</name>
	<reference anchor="OHTTP">
	<front>
	<title>Oblivious HTTP</title>
	<author fullname="Martin Thomson" initials="M." surname="Thomson">
	<organization>Mozilla</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="25" month="August" year="2023"/>
	<abstract>
	<t> This document describes Oblivious HTTP, a protocol for forwa
	rding
	encrypted HTTP messages. Oblivious HTTP allows a client to make
	multiple requests to an origin server without that server being able
	to link those requests to the client or to identify the requests as
	having come from the same client, while placing only limited trust in
	the nodes used to forward the messages.
	</t>		<!-- draft-ietf-ohai-ohttp (RFC 9458: published) -->
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9458.xml"
	</front>		/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-ohai-ohttp-10"/>
	</reference>
	<reference anchor="DDR">
	<front>
	<title>Discovery of Designated Resolvers</title>
	<author fullname="Tommy Pauly" initials="T." surname="Pauly">
	<organization>Apple Inc.</organization>
	</author>
	<author fullname="Eric Kinnear" initials="E." surname="Kinnear">
	<organization>Apple Inc.</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<author fullname="Patrick McManus" initials="P." surname="McManus">
	<organization>Fastly</organization>
	</author>
	<author fullname="Tommy Jensen" initials="T." surname="Jensen">
	<organization>Microsoft</organization>
	</author>
	<date day="5" month="August" year="2022"/>
	<abstract>
	<t> This document defines Discovery of Designated Resolvers (DDR
	), a
	mechanism for DNS clients to use DNS records to discover a resolver's
	encrypted DNS configuration. An encrypted DNS resolver discovered in
	this manner is referred to as a "Designated Resolver". This
	mechanism can be used to move from unencrypted DNS to encrypted DNS
	when only the IP address of a resolver is known. This mechanism is
	designed to be limited to cases where unencrypted DNS resolvers and
	their designated resolvers are operated by the same entity or
	cooperating entities. It can also be used to discover support for
	encrypted DNS protocols when the name of an encrypted DNS resolver is
	known.
	</t>		<!-- draft-ietf-add-ddr (RFC 9462; published) -->
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml"
	</front>		/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-add-ddr-10"/>
	</reference>
	<reference anchor="DNR">
	<front>
	<title>DHCP and Router Advertisement Options for the Discovery of Ne
	twork-designated Resolvers (DNR)</title>
	<author fullname="Mohamed Boucadair" initials="M." surname="Boucadai
	r">
	<organization>Orange</organization>
	</author>
	<author fullname="Tirumaleswar Reddy.K" initials="T." surname="Reddy
	.K">
	<organization>Nokia</organization>
	</author>
	<author fullname="Dan Wing" initials="D." surname="Wing">
	<organization>Citrix Systems, Inc.</organization>
	</author>
	<author fullname="Neil Cook" initials="N." surname="Cook">
	<organization>Open-Xchange</organization>
	</author>
	<author fullname="Tommy Jensen" initials="T." surname="Jensen">
	<organization>Microsoft</organization>
	</author>
	<date day="27" month="April" year="2023"/>
	<abstract>
	<t> The document specifies new DHCP and IPv6 Router Advertisemen
	t options
	to discover encrypted DNS resolvers (e.g., DNS-over-HTTPS, DNS-over-
	TLS, DNS-over-QUIC). Particularly, it allows a host to learn an
	authentication domain name together with a list of IP addresses and a
	set of service parameters to reach such encrypted DNS resolvers.
	</t>		<!-- draft-ietf-add-dnr (RFC 9463; published) -->
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"
	</front>		/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-add-dnr-16"/>
	</reference>
	<reference anchor="SVCB">
	<front>
	<title>Service binding and parameter specification via the DNS (DNS
	SVCB and HTTPS RRs)</title>
	<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc
	hwartz">
	<organization>Google</organization>
	</author>
	<author fullname="Mike Bishop" initials="M." surname="Bishop">
	<organization>Akamai Technologies</organization>
	</author>
	<author fullname="Erik Nygren" initials="E." surname="Nygren">
	<organization>Akamai Technologies</organization>
	</author>
	<date day="11" month="March" year="2023"/>
	<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 HTTP origins. SVCB
	records allow a service to be provided from multiple alternative
	endpoints, each with associated parameters (such as transport
	protocol configuration), and are extensible to support future uses
	(such as 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 use with HTTP [HTTP]. 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:		<!-- draft-ietf-dnsop-svcb-https (RFC 9460; published) -->
	https://github.com/MikeBishop/dns-alt-svc		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"
	(https://github.com/MikeBishop/dns-alt-svc). The most recent working		/>
	version of the document, open issues, etc. should all be available
	there. The authors (gratefully) accept pull requests.
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"
	</abstract>		/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-svcb-https-1		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	2"/>		/>
	</reference>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	<reference anchor="WELLKNOWN">		/>
	<front>
	<title>Well-Known Uniform Resource Identifiers (URIs)</title>		<!-- draft-ietf-add-svcb-dns (RFC 9461; published) -->
	<author fullname="M. Nottingham" initials="M." surname="Nottingham"/		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9461.xml"
	>		/>
	<date month="May" year="2019"/>
	<abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9292.xml"
	<t>This memo defines a path prefix for "well-known locations", "/.		/>
	well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
	<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"
	defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI		/>
	schemes that support well-known URIs in their registry.</t>
	</abstract>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"
	</front>		/>
	<seriesInfo name="RFC" value="8615"/>
	<seriesInfo name="DOI" value="10.17487/RFC8615"/>
	</reference>
	<reference anchor="RFC2119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author fullname="S. Bradner" initials="S." surname="Bradner"/>
	<date month="March" year="1997"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized. T
	his document defines these words as they should be interpreted in IETF documents
	. This document specifies an Internet Best Current Practices for the Internet Co
	mmunity, 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">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author fullname="B. Leiba" initials="B." surname="Leiba"/>
	<date month="May" year="2017"/>
	<abstract>
	<t>RFC 2119 specifies common key words that may be used in protoco
	l 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="DNS-SVCB">
	<front>
	<title>Service Binding Mapping for DNS Servers</title>
	<author fullname="Benjamin M. Schwartz" initials="B. M." surname="Sc
	hwartz">
	<organization>Meta Platforms, Inc.</organization>
	</author>
	<date day="26" month="June" year="2023"/>
	<abstract>
	<t> The SVCB DNS resource record type expresses a bound collecti
	on of
	endpoint metadata, for use when establishing a connection to a named
	service. DNS itself can be such a service, when the server is
	identified by a domain name. This document provides the SVCB mapping
	for named DNS servers, allowing them to indicate support for
	encrypted transport protocols.
	</t>
	</abstract>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-add-svcb-dns-09"/>
	</reference>
	<reference anchor="BINARY-HTTP">
	<front>
	<title>Binary Representation of HTTP Messages</title>
	<author fullname="M. Thomson" initials="M." surname="Thomson"/>
	<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
	<date month="August" year="2022"/>
	<abstract>
	<t>This document defines a binary format for representing HTTP mes
	sages.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="9292"/>
	<seriesInfo name="DOI" value="10.17487/RFC9292"/>
	</reference>
	<reference anchor="DOH">
	<front>
	<title>DNS Queries over HTTPS (DoH)</title>
	<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
	<author fullname="P. McManus" initials="P." surname="McManus"/>
	<date month="October" year="2018"/>
	<abstract>
	<t>This document defines a protocol for sending DNS queries and ge
	tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H
	TTP exchange.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="8484"/>
	<seriesInfo name="DOI" value="10.17487/RFC8484"/>
	</reference>
	<reference anchor="HTTP">
	<front>
	<title>HTTP Semantics</title>
	<author fullname="R. Fielding" initials="R." role="editor" surname="
	Fielding"/>
	<author fullname="M. Nottingham" initials="M." role="editor" surname
	="Nottingham"/>
	<author fullname="J. Reschke" initials="J." role="editor" surname="R
	eschke"/>
	<date month="June" year="2022"/>
	<abstract>
	<t>The Hypertext Transfer Protocol (HTTP) is a stateless applicati
	on-level protocol for distributed, collaborative, hypertext information systems.
	This document describes the overall architecture of HTTP, establishes common te
	rminology, and defines aspects of the protocol that are shared by all versions.
	In this definition are core protocol elements, extensibility mechanisms, and the
	"http" and "https" Uniform Resource Identifier (URI) schemes.</t>
	<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7
	232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
	</abstract>
	</front>
	<seriesInfo name="STD" value="97"/>
	<seriesInfo name="RFC" value="9110"/>
	<seriesInfo name="DOI" value="10.17487/RFC9110"/>
	</reference>
	</references>		</references>
	<references anchor="sec-informative-references">		<references anchor="sec-informative-references">
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="DNSSEC">
	<front>
	<title>DNS Security Introduction and Requirements</title>
	<author fullname="R. Arends" initials="R." surname="Arends"/>
	<author fullname="R. Austein" initials="R." surname="Austein"/>
	<author fullname="M. Larson" initials="M." surname="Larson"/>
	<author fullname="D. Massey" initials="D." surname="Massey"/>
	<author fullname="S. Rose" initials="S." surname="Rose"/>
	<date month="March" year="2005"/>
	<abstract>
	<t>The Domain Name System Security Extensions (DNSSEC) add data or
	igin authentication and data integrity to the Domain Name System. This document
	introduces these extensions and describes their capabilities and limitations. Th
	is document also discusses the services that the DNS security extensions do and
	do not provide. Last, this document describes the interrelationships between the
	documents that collectively describe DNSSEC. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="4033"/>
	<seriesInfo name="DOI" value="10.17487/RFC4033"/>
	</reference>
	<reference anchor="CONSISTENCY">
	<front>
	<title>Key Consistency and Discovery</title>
	<author fullname="Alex Davidson" initials="A." surname="Davidson">
	<organization>Brave Software</organization>
	</author>
	<author fullname="Matthew Finkel" initials="M." surname="Finkel">
	<organization>The Tor Project</organization>
	</author>
	<author fullname="Martin Thomson" initials="M." surname="Thomson">
	<organization>Mozilla</organization>
	</author>
	<author fullname="Christopher A. Wood" initials="C. A." surname="Woo
	d">
	<organization>Cloudflare</organization>
	</author>
	<date day="10" month="July" year="2023"/>
	<abstract>
	<t> This document describes the consistency requirements of prot
	ocols
	such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user
	privacy. It presents definitions for consistency and then surveys
	mechanisms for providing consistency in varying threat models. In
	concludes with discussion of open problems in this area.
	</t>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"
	</abstract>		/>
	</front>
	<seriesInfo name="Internet-Draft" value="draft-ietf-privacypass-key-co		<!-- draft-ietf-privacypass-key-consistency (Expired) -->
	nsistency-01"/>		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-pr
	</reference>		ivacypass-key-consistency.xml"/>
	</references>		</references>
	</references>		</references>
	</back>		</back>
	<!-- ##markdown-source:
	H4sIAAAAAAAAA61c3XLjxnK+n6cY0xeWUiRlrffEtnJ8fGRp7VV5V9pI2my5
	UqkcEBiSkyUBBgNQS8vys+RZ8mTpv/kBCMqnkuzNkiAw09PT/fXXPQ1NJhPV
	2GZlzvTo0rq82pp6p6u5vpmt7NZWrdN3pt7a3Di9tZn/on+wZWHLhb41eVUX
	bqSy2aw2Wxhl4EFb6rt/ufhhpPKsMYuq3p1p1xTKNbXJ1mf66tX9j0oVVV5m
	a5CjqLN5M7GmmU+qZWYnbpvPJnlVzu1i8uXXKoOHYJo7k7e1bXYj9VDVHxd1
	1W46k7++v3+nzzeblYVJbVXqq7Ix9doUlr6O1EezgyeLM/6hNM3kEidWW1O2
	5kxp/b8YU+tmt0FVfgCZUD0/4Rh4fZ3ZFVzHBf0Vlzat6gVez+p8CdeXTbNx
	ZycneBteslsz9bed4IWTWV09OHOCA5zggwvbLNvZmSY9PSxIVSesur7WlIJ9
	+UqprG2WVQ1Lm8DzWrO276v1eqffZe1qR1dhwqy0v9KCzmixBpaZT+lHw8to
	Nnj7XzP8cZpX696Itm7X2cq4h6wG+yiKoYGvq482S8f8WJVFY+u/LvArDarK
	ql7D7VvYDWXLefJNTSYTnc3AgLK8Uep+aZ0G+2nXpmx0Yea2BKvL9CarQSLY
	It0ss0bnWalnBqwxX7WFKbxZ6qwsaGvv1OX1na6Nq9oaTLxm09ZNBUOWVWN4
	lEw78QGYNMvBvp2dgZJahxsejEXhiGM9Q2eamxp/g+mjLf0ErvCQ7UBBMl2z
	BFtZLPXD0uZLnJTHhutGNVm9MM1UdxearVyVrHZt8iVo2K3x4ZXJ6hKf1WDn
	mu2grUn5CrwbfyjE3UETh8Wasq7XtihWRqnP0eTrqmhzGkn1fOPx8bMb/PDd
	1eRy2vfjCo386QnEXoEp63xlYRGkXlPm9W7TqDWsN1vAYswnXMoCJHsAM+8q
	7p50EfV2xMo5Ru0Y7YdAmMBxs41rV7Am2m2ZB76EmVDPz22LOlrwleOx7Axt
	p9O9lfvNqki1cb+MlufBWhTfBNMjknamvTWr1BaOavweptzU1SdryBQ6a1Lp
	Mpa2MHQH/F8CpBOK43dW9FTfwF6D7sdwES0XUaYxedPWaMmqMM4uStaTa2HS
	TKPUZPI4CkmELgSeAPe4DTzKw1cAgriRMJ2XZ6zQp5pk9fSdd07GiBbKAn7h
	ouTzulqjo4HXgNWBl5cuI4sDc7wD/zV99Rdms6p2azao3QbwebUClZfbarU1
	mmIaSmznNgeBwa1tyb4wM82DMaW3xjGvE/5HgUV4Nx52JASAag6L124J5lYA
	SIHQM+M21Uej55lbosT6dfVgQIKxdtXadCT18snkynskggUry2lRpK115lyV
	W7JlL5heV7B7xQ6Al5c8VT9WNbhPtgZohkVoiGsYH8GBF8tGVxswAQCyTHuk
	g+kFHcHItrABMma1aeza/gqLgvHoCijGbDOAHXwUNuQBvQClexYGNcMg3kci
	qAccAr2ugJkb6wxY22ZT1Y0GgO9vK/pJgDWnVxb0mrIUdUlWSzq5ldU4fQQw
	dHl52wehrCgmRVE/PR2jOKrDdq5ZTZPi4HjXw+OVON5UXQiYYYiJuO1M3CkP
	703dOhye7Wx6OHiR91WgT6MHw9LR7a077mqS41NJulM+Sol6+4glwSQ8TLPb
	vytqqm7UJPFAGER//KWvp6J01Yb5CNEcCAGgUfg+oZlIfwiUG1iiQd8m3AJR
	oiBINpE7un4IZn3DFRRc8AU3d0kXPPiEdYiND6O1IinYFxmdGHHf3175jUAT
	TVGNjR32yqxWk49l9VAqvNu187n9hPr48OrNm5+vbz5cf3f748U3/3j6p6en
	MbJA0MNEBhl5lA9+BEoGZIqSobrk5smqYuqJWuMdXJusFL2geB0khIvKuxep
	FEhpgfr1SLMbH0Jpb28OIAQEaiqASk2zk3j0mIPt0cvKNXtm3KMmYstz01Bg
	kekA8QFTVRdTCfpTmWDxQv7pcTIXJSv3hKeoUE4IKpmlAJbSG/Jv9rZ/UhLF
	9lC8bfAueGDjNzlZzVS/rQqzojyGtkrxz2GCKAjuIecHiIXIQQBR8trOOLA+
	Pvpf7Qri3NPTFCnVRVVuMfBVJQPqJerN0ne2SYw8D+T0o7fv7+7BYuh/fX1D
	n29f/fP7q9tXl/j57vX5mzfhg5I77l7fvH9zGT/FJy9u3r59dX3JD8NV3bmk
	Rm/PfxkxfI9u3t1f3VyfvxmxhjvbDQuF/SWYAH8FT0YryYhVxNX/cPHuv//r
	9CX6BXjDi9PTbwEK+Ms3p1+/hC8PS1PybFUJ8Zu/wmbuFOgNPBJHgTAHvryx
	DdjYGB3fLcHv9BKILGjzH/4VNfNvZ/rPs3xz+vIvcgEX3Lnodda5SDrbv7L3
	MCtx4NLANEGbnes9TXflPf+l893rPbn45+9X4Fl6cvrN939RaELnqVnpx8+7
	ZkZWVLM9rttVYzGpW3dtuucziW+RFxO56W66BAbAxQKzBP1+s6gzKgrUZgEE
	tdZHZVVOmLwWxxzRwUr6cehKBiaBxioyQjKmkjMwSAjXbUlBQHKCSOgEsSQm
	kP0oMEGi6QLcPV5h59pytNtiwg2+yly9O9JQFLGNTwAw8mIm44PJUP4HpLvM
	TUJyfVzJZgg5CcyNceRRSyo0bqQswHdt/rM1Dj4QJia6PKDKmDSmwUMWQ1t0
	mRDMbIVlD8qo++PII+65vWHdgHFkYFC9uYKqQPUwCFBSFSgpDwfqnCEN3bQw
	cz7ARrukEmVW+/wlGooDo1itiDfzhierU13hHO4+YgrDc0iCfRhG2TxPQOKr
	AhXWe1S4Rq5f4iKVAlXNKjDMGIDFxcbp/oOkPvpIdqsyya280oghuiE6nCRC
	jqO/BDQD44DmMFKTYXr5F6aEzc4TvhNTGtiUQIfixlVpXs72DUNTSSFfmvyj
	KMkPQ2l23CgKZ7gvxHD03TZ/hxzuZ4OYFBkfRzWmQaPOXdYRnuB0nvMJ5Qt8
	thNSMinh3N56OAoUKqGESnhaOZBDsR11DddpcLwaHW22SzcPqY5TFSCvt4Q+
	WWI7gFCNdpyWcPwMwHn2CNZwyhTnVWFfgR8X3apGWgFIWVNIF3qJ+BdO7eex
	R2S4QIB4c0WTEMRBB1uYhAVsqLzSLKuiswdqiJ/9gAM2gdQ3PA/K8mBrolhr
	UPQ2WwHABVbtDSLwfkWhG0Qx602zw9zfuzCKKBnJ8KOeBa5hzqypIKLFUVfW
	NQICaS2PKMcfZLJABTOq7KrhWTOXzIiQBJIiHAWnQvsqKuSqqi3BSlzjNyhJ
	u8D4FyWZF94uBj4Fy8IF+63YnxzRBMPKmkVELInChEQPfHbP3BHiqpJqJiEi
	Hlj/NRZCkd4rejjQCZHSeesRbOm6sjMobWO6nN9J6kWFdKqgp/lWx9xDSFxn
	Bd2V9WM2wC9xBp+iAGqtjS+FeVXq4aQbS62BwEo64m2TUtcR0FUcA6uYSIkh
	tcVLn0H8mgylvlgioMQXbnx6UiwMQPcNwbV85V3wdZGW8vhO9ktewDIOiUi1
	FUgCcbd8yS9VL4Ly5/q9Q3IuGbvff9gvRRWjdIkslg+HGMLpZ34SgJY2yJau
	MRnlkrhwpgbdDH7IRJNkNVIUyCxR9gRUXLc6mpKSIXpAlkoSeD4yElw8mbEE
	iWk9PlKJGrYDNu6Hq+vz218mVLOGNOTbF9++oKSsW0XbVxvZBezsVG7CAwuW
	zJdb+qXxvGpXBSTQ1UcuY+Eenyn1+++/q944U/31iy+/1PrqWqY91VN9BD63
	Kb9bvpDQekxPqnPtgJsg1xaZer5NmHagAqT+zyIFdPmOheqIFm0O2R1KBfvv
	USKxOvIhb3OAn5JvcLrsHQvLJj0LO4DAPQtL5iYrSzJSZrB4AxJA3qWjy+r1
	MXn0zWsq2bz8BvPSjk4B4FRKNIZx8tYjlQTmQG+RMWFIxJLKfi1pZssM0JqE
	oTznGatWHatOTBm1hWX5zBIo2BJYYIROWgTDjFGjLB5nnsBWTGSKnsuAOsgv
	rg45tnWdc7VsaNcZJEZoyCMGNR/CM0qMHNqrkcovUgN9xCcRDrDpxQgZ62j5
	1eg4JVlo87BnE4gRFLRqPBZ2mNPUoX6Llae2zBks905upNA+5iq7GqqySwUs
	0ktCHTrEkcg+6ZR1pwpEGhSFyG3c1/1020UYDBm3Myw7RlZh+hhgKXXqUBYk
	9UlaDNFRSf2fMjnKBrLVmFFh4Hl9SGxiMjiOekZ/bbkSslvz2Wg8aTFFkhYp
	yd8l6+mwZBF3EhZxQCKKaQwwNNrl5S1kGFjdV51avNewrxsfWqAvkvbWxoEF
	Bh8Hxe8oN9ihX/07+MvUjzHN6k3GjASrpEilYqKngvdX3SEis8azc4ybWUQK
	cLvL24FwRKvwkBR4XcEwhprwqRCes9E5YRZWyOUZmKAlk0IbHloziTSvMP+j
	Lo9biQsDS46hgdz8FGjVMsSOEqvXdMwf4hf8vMma5XeENqSIx++RHnWjh99E
	16DpeQfcmBpTBzzQQ+tg/gNKq8ISvGpgU8fKWxHtBq7o/s2dzlFdc+ajlNK6
	fo32Tvzt5fQFDi6bwOeOf1gtpxp8PFmPkvnyg0rQpF9H9+WRbgyT7DNkgbT6
	nYq/JyuSfCumrl7YDQCbMDmMBBaF4+XT6YsLyvD8nVWNcLU0JbEEMtjNPsH0
	y5CpVLan0W6COE7yzIhnBWJ/AXLlzWqHp45om/HkGbkNmDPejFUwBo5tZSEf
	/rSpyGZFT1fvwCmKGoMz4sQN2X0L4NoAnkTIFe9CYRCwCBNxuvg4ghjEIVug
	D41VLPH6sicuTkCVYaifwzuxGamgqU1tITmzMJP5ZIUceOhJ4pUP0HD7FjcV
	1k6YArKpsDSvRcLm1rVk5HgG0o1StHtS/+BqEcSCOYFzZwtzBEXRRYevdKj2
	WM/aRskJPiW20fYms4x6G1hjMGin8EXx3pQO4FD1mgqSxFssdMDDIsdvy9jH
	4aX8AhK+2i4g1qySDZxGmpmDbOTMwwFgHDJ0OrnyLsryBk/kkiHm7pyxsGg+
	ooOJAZzRDAhwPq8jkl2brQHR+CDftzlM9Z0xkIU4aWUDojn3hSW00xZ0Lulb
	GuquKdSVtZTRkvJZhzw3+wdyScVexvLeoP7wDBymPSZCjmDo68IK1crbHIGu
	a1i4haiOyBVd/0gZic7l64t3dO9t1SKfPO+cS/sqF+jiw9IiUQElhEM/wbMI
	pf6UsxMmAJUokPtmC9odbkLhavxBbtAJQYdMQtKL/w+T0KlJqAMmETqV3siJ
	MBjF3iExoB8CUJYW7ZPg1DtMP5QneiAeLLJlHParOhQI6CgjBKuZUUTMffUy
	pCFMnwMJ5KhSI/wH9/freK5LIpy8x5Ln0eNjOHd/ejoeq9HJNN53cvj0/dlG
	sFgY60dtNK3kwMXLgfVK7PgROiItOGgqvtbj23FSyENLTVf1/vYKK3/ck4Xu
	xpmKi+OiNyEUf/XpE8zNERTtIRxOqKPIaU7/NH2JrvFZKHmcnn6JLTHY5UiP
	RiQsfZdKb3+U3xdf5wml9DsU0svgxNAxw9zx2QiM4/df+QoeNwXsFaUBcvrF
	gF6ZmaNDpZ4pECY2xslr8AQQ0ICbO/pZFk6hkkb3DHi/VO7bE1SyRf2aOzmA
	P3XunFxyzOPpAPf8g9JhEiOiGNQBPUuZELNMFBSAXRTtj2vSG33TnWwqsELQ
	V4VVZCXoBK4rSSyj0JwyE6nNSxk9Ck0GCfhP5b+xEgPheBgDS9KSlgJOyKhJ
	O74G8YwqaY85D4GPu8S2AOKp0gsSr6gVLP7EVRpZsGx0wec8oYsRPq3NeoZV
	2I7NqiyvK6B+MZzFU1ikoFjRl5FtetBDTBRoBywSDbHMdwTSeKZ10TGgH719
	PX7eseeY8nQYCKrlgClSsugVNjPzqtPxihuMykPQ5aSvX4/adwqSRCjY/nye
	m++16KC9K6KhRMV9B+rcIjpRZTHb5+a9AyvaHkWEN2fe50OgtutQoaIm0z/w
	UIjHSkIlno+hVgg9Ykid6rREQKfFXOENmYXyzbQQmtN0ogcR+6DVGVrRTvqc
	FW50wPnRNHyqhbmc5BcDhIItN3HU/em4YBoW61HSz8Mlu8RMGWv/DnOKPqvi
	QRpWEXuJ3X5bWu+027WEsT+9uvcWqI4k5/MdkZmonRJnNrFjbx2IjD3w46R+
	F87g0gImh3ZYmxshC5BC/3Fay5TlnEO6sQFCBCBm6n6FxaaN0+SCRA4iJiTA
	DezCv7zRK5o/SzogQnD5PWzJwLlsKBTGSowoUcoxqNbD05BNn5xOT9VrYCln
	/fMKxTo408Ma5DrMT7F/FUE1FPRENmlSZiIZ+lB7/NFnuJJA+6+JTYQzYPC3
	gTZrSTbYBAcKjVIXABI/qeaQhgJ6dEegRgx/cqRaRzQOQqFA+VSHZTJpijXa
	wwIZ5QkWcJsCQFDKmtIPz9YGtnvIQCk++LeYCPHeCfpdoAcXxvOgx88DdCl1
	3jRZ/hGBlYiib++WiAYuy3Q8vC7jKUuOmU5jPlH7tvLt27xvgjfghQ2HeNAM
	3HX36gI8/Hv+hFTx5ZdffYXoec+ZX6nNfI60cmswyoP5UfNSVGpsfKcyiAhW
	eCxXAx0u3jZQpv9ogVoDzmJtOQQQnHZtG7tgzLTIaABnae8IVdFJ+CDMe0Gv
	12GPRyrh8wM0JBCwAx246j1XFWJBgprjVxUIIck6qZHalDEY+Oybjp5kHZzg
	fFjGtxAGGmX/aBF0tsLMRoJwN7H0uEehCKG+7BS6pCNKOhNg7BIJMdPngM70
	/gK72tW7CYRI1HU4uaCiAN2S2xryNOxsyPFVEC5/heSH+77E1GGm3NSlNxHO
	iTm2U2oKqWZjc2wmVPsMAg/Ja+woSPu+Dp4bc9FBgXbIyBPztAkFwmYIXOED
	9dNzkd6/XIM9ebEC56tyvCHov7i6NWASeoMBdMe2CHwmHGZ0G/rgJxVXc0yH
	N3ae6IDnC8udZzm2c1IbPGISgy8V9ggUIM+zaQz3C6cT/A6LQcLqj7nS92JS
	asGnNPFHtszjcccg5Ow5NoumFSbPN9JTzr4le8NP33xJ6k/duv7wgRpbS9oO
	Plbejw4UbcIU0v7tD+/AR+DBFrMJTmh85SJQX+6Ba3qvPXXoCWXlsM77N3cq
	qY76yg69gTJU5yMuhxjksz8fG1QvHsCE6cE4t3dgonEfDIKjhOMcI7BBiB57
	bPEmnBf7vFhMdOhUm0CfqrX4LoAtP3KswDdSFqX99SAnJ2jwJBRbc7HdHcI4
	1kEwYYKRfOsy5fR1Rjgei7K+f2838MLAUM9ycsQiCBNeJRRXYVOQF0aimYPh
	0hndptpQEuVJWKYPcfBp2lztDL1jh4yqrjLKpfJeqgFShfjV8WIlok0x6F7c
	XN9d3d2/ur74hXqKqJtIQBNPcpBCTDpMP76/hXu0Rd83D/5VT+7vctJPBb5w
	cKscrSOMjHBNL8hBSoVtzxSCfXz3qY7wOrPGE14OAUAklqyw3nrVHmqNtT/k
	j5KijZNY9TqV1Dd+89t2DEP7h02J7qhUnaB7YZpYIQhIqay3MMjVJnJrKOTu
	qaiT4eC2uqbaJOcTISum0neFWrRUCIFYxS/imD3s5ld2G449Ab64qpBAXHiX
	VIJ5i29vMgDIseo+CHBuM3xCSi2xwiglH0EbFVv/m4z5NykGqVhOqjyzmO/2
	YoR/s4wXhmdo9PqlxArf9SKdyYQ/g+Es2dZsBgY9xW6nROusHC6F7hkVvXdN
	x0o+cQpvk/ZW1TU/LNbRcxTBRv0zaupBiceQRugiDUSWlliGvOac1TMLgAYa
	CBMrViclgeI7kdLurSSmFd3ywVh5wf1baOk7G4c9old12FOIf+WaFyml7ODr
	zOPyZVUxlqGylHj+gJCcpYBb5dgEvDCdd880xQFgiFzJo/5FeSM42wDZ4VeY
	B8bcxHeluGkn6blvlrXJpPWeUqyr8+vz/ZTKZmX2RI5DaYn/sxbvQpNw/4W2
	onC9VBwu1+HoYngU7M9fgPA1vcbG8VpeVC/CS15D7zs6qVnFlyRhLb/p65ZK
	lho+4eFD/PebfisdoM/8+03fGsLw3D/6G4w54X86fDp0Yejf/k005jf66FVW
	gxudrzxFPhYRuMsjkemS/rbC3pudcjYy1AkqGATPHnU26Rjmxh39gIncz/70
	RCmyABsquUwNYEOp26w0D7KTAqqj7uNupMMeds6VYEPiu55nulN5UeqC/n4B
	scQaLMbU/s+c3PmeFCYvIvpZtyMZbgOe37ozdJ11VtIl/BsBzFJDbn+mr0/O
	+S80zAAs1P8AAeu4e85FAAA=
	</rfc>		</rfc>
End of changes. 71 change blocks.
	595 lines changed or deleted		187 lines changed or added
This html diff was produced by rfcdiff 1.48.