<?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.37 -->
<!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-schinazi-masque-obfuscation-04" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="MASQUE Obfuscation">MASQUE Obfuscation</title>
    <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-obfuscation-04"/>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <date year="2021" month="March" day="12"/>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>This document describes MASQUE Obfuscation. MASQUE Obfuscation is a mechanism
that allows co-locating and obfuscating networking applications behind an
HTTPS web server. The currently prevalent use-case is to allow running a proxy
or VPN server that is indistinguishable from an HTTPS server to any
unauthenticated observer. We do not expect major providers and CDNs to deploy
this behind their main TLS certificate, as they are not willing to take the
risk of getting blocked, as shown when domain fronting was blocked. An
expected use would be for individuals to enable this behind their personal
websites via easy to configure open-source software.</t>
      <t>This document is a straw-man proposal. It does not contain enough details to
implement the protocol, and is currently intended to spark discussions on
the approach it is taking. Discussion of this work is encouraged to happen on
the MASQUE IETF mailing list <eref target="masque@ietf.org"/> or on the GitHub repository
which contains the draft: <eref target="https://github.com/DavidSchinazi/masque-drafts"/>.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document describes MASQUE Obfuscation. MASQUE Obfuscation is a mechanism
that allows co-locating and obfuscating networking applications behind an
HTTPS web server. The currently prevalent use-case is to allow running a proxy
or VPN server that is indistinguishable from an HTTPS server to any
unauthenticated observer. We do not expect major providers and CDNs to deploy
this behind their main TLS certificate, as they are not willing to take the
risk of getting blocked, as shown when domain fronting was blocked. An
expected use would be for individuals to enable this behind their personal
websites via easy to configure open-source software.</t>
      <t>This document is a straw-man proposal. It does not contain enough details to
implement the protocol, and is currently intended to spark discussions on
the approach it is taking. Discussion of this work is encouraged to happen on
the MASQUE IETF mailing list <eref target="masque@ietf.org"/> or on the GitHub repository
which contains the draft: <eref target="https://github.com/DavidSchinazi/masque-drafts"/>.</t>
      <t>MASQUE Obfuscation is built upon the MASQUE protocol
<xref target="MASQUE" format="default"/>. MASQUE Obfuscation leverages the efficient
head-of-line blocking prevention features of the QUIC transport protocol
<xref target="QUIC" format="default"/> when MASQUE Obfuscation is used in an HTTP/3
<xref target="HTTP3" format="default"/> server. MASQUE Obfuscation can also run in an
HTTP/2 server <xref target="HTTP2" format="default"/> but at a performance cost.</t>
      <section anchor="conventions" numbered="true" toc="default">
        <name>Conventions and Definitions</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 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="usage-scenarios" numbered="true" toc="default">
      <name>Usage Scenarios</name>
      <t>There are currently multiple usage scenarios that can benefit from MASQUE
Obfuscation.</t>
      <section anchor="protection-providers" numbered="true" toc="default">
        <name>Protection from Network Providers</name>
        <t>Some users may wish to obfuscate the destination of their network traffic from
their network provider. This prevents network providers from using data
harvested from this network traffic in ways the user did not intend.</t>
      </section>
      <section anchor="protection-servers" numbered="true" toc="default">
        <name>Protection from Web Servers</name>
        <t>There are many clients who would rather not establish a direct connection to
web servers, for example to avoid location tracking. The clients can do that
by running their traffic through a MASQUE Obfuscation server. The web server
will only see the IP address of the MASQUE Obfuscation server, not that of the
client.</t>
      </section>
      <section anchor="onion" numbered="true" toc="default">
        <name>Onion Routing</name>
        <t>Routing traffic through a MASQUE Obfuscation server only provides partial
protection against tracking, because the MASQUE Obfuscation server knows the
address of the client. Onion routing as it exists today mitigates this issue
for TCP/TLS. A MASQUE Obfuscation server could allow onion routing over QUIC.</t>
        <t>In this scenario, the client establishes a connection to the MASQUE
Obfuscation server, then through that to another MASQUE Obfuscation server,
etc. This creates a tree of MASQUE servers rooted at the client. QUIC
connections are mapped to a specific branch of the tree. The first MASQUE
Obfuscation server knows the actual address of the client, but the other
MASQUE Obfuscation servers only know the address of the previous server.
To assure reasonable privacy, the path should include at least 3 MASQUE
Obfuscation servers.</t>
      </section>
    </section>
    <section anchor="requirements" numbered="true" toc="default">
      <name>Requirements</name>
      <t>This section describes the goals and requirements chosen for MASQUE
Obfuscation.</t>
      <section anchor="invisibility-usage" numbered="true" toc="default">
        <name>Invisibility of Usage</name>
        <t>An authenticated client using MASQUE Obfuscation appears to observers as a
regular HTTPS client. Observers only see that HTTP/3 or HTTP/2 is being used
over an encrypted channel. No part of the exchanges between client and server
may stick out. Note that traffic analysis is discussed in <xref target="traffic-analysis" format="default"/>.</t>
      </section>
      <section anchor="invisibility-server" numbered="true" toc="default">
        <name>Invisibility of the Server</name>
        <t>To anyone without private keys, the server is indistinguishable from a regular
web server. It is impossible to send an unauthenticated probe that the server
would reply to differently than if it were a normal web server.</t>
      </section>
      <section anchor="fallback-h2" numbered="true" toc="default">
        <name>Fallback to HTTP/2 over TLS over TCP</name>
        <t>When QUIC is blocked, MASQUE Obfuscation can run over TCP and still satisfy
previous requirements. Note that in this scenario performance may be
negatively impacted.</t>
      </section>
    </section>
    <section anchor="overview" numbered="true" toc="default">
      <name>Overview of the Mechanism</name>
      <t>The server runs an HTTPS server on port 443, and has a valid TLS certificate
for its domain. The client has a public/private key pair, and the server
maintains a list of authorized MASQUE Obfuscation clients, and their public
key. (Alternatively, clients can also be authenticated using a shared secret.)
The client starts by establishing a regular HTTPS connection to the server
(HTTP/3 over QUIC or HTTP/2 over TLS 1.3 <xref target="TLS13" format="default"/> over TCP), and
validates the server's TLS certificate as it normally would for HTTPS. If
validation fails, the connection is aborted. At this point the client can send
regular unauthenticated HTTP requests to the server. When it wishes to start
MASQUE Obfuscation, the client uses HTTP Transport Authentication
<xref target="TRANSPORT-AUTH" format="default"/> to prove its possession
of its associated key. The client sends the Transport-Authentication header
alongside its MASQUE Negotiation request.</t>
      <t>When the server receives the MASQUE Negotiation request, it authenticates the
client and if that fails responds with code "404 Not Found", making sure its
response is the same as what it would return for any unexpected POST
request. If authentication succeeds, the server sends its list of supported
MASQUE applications and the client can start using them.</t>
    </section>
    <section anchor="resumption" numbered="true" toc="default">
      <name>Connection Resumption</name>
      <t>Clients MUST NOT attempt to "resume" MASQUE Obfuscation state similarly to how
TLS sessions can be resumed. Every new QUIC or TLS connection requires fully
authenticating the client and server. QUIC 0-RTT and TLS early data MUST
NOT be used with MASQUE Obfuscation as they are not forward secure.</t>
    </section>
    <section anchor="pmtud" numbered="true" toc="default">
      <name>Path MTU Discovery</name>
      <t>In the main deployment of this mechanism, QUIC will be used between client
and server, and that will most likely be the smallest MTU link in the path
due to QUIC header and authentication tag overhead. The client is responsible
for not sending overly large UDP packets and notifying the server of the low
MTU. Therefore PMTUD is currently seen as out of scope of this document.</t>
    </section>
    <section anchor="http2" numbered="true" toc="default">
      <name>Operation over HTTP/2</name>
      <t>We will need to define the details of how to run MASQUE over HTTP/2.
When running over HTTP/2, MASQUE uses the Extended CONNECT method to negotiate
the use of datagrams over an HTTP/2 stream
<xref target="HTTP2-TRANSPORT" format="default"/>.</t>
      <t>MASQUE Obfuscation implementations SHOULD discover that HTTP/3 is available
(as opposed to only HTTP/2) using the same mechanism as regular HTTP traffic.
This current standardized mechanism for this is HTTP Alternative Services
<xref target="ALT-SVC" format="default"/>, but future mechanisms such as
<xref target="HTTPSSVC" format="default"/> can be used if they become
widespread.</t>
      <t>MASQUE Obfuscation implementations using HTTP/3 MUST support the fallback to
HTTP/2 to avoid incentivizing censors to block HTTP/3 or QUIC.</t>
      <t>When the client wishes to use the "UDP Proxying" MASQUE application over
HTTP/2, the client opens a new stream with a CONNECT request to the
"masque-udp-proxy" protocol and then sends datagrams encapsulated inside the
stream with a two-byte length prefix in network byte order. The target IP and
port are sent as part of the URL query. Resetting that stream instructs the
server to release any associated resources.</t>
      <t>When the client wishes to use the "IP Proxying" MASQUE application over
HTTP/2, the client opens a new stream with a CONNECT request to the
"masque-ip-proxy" protocol and then sends IP datagrams with a two byte length
prefix. The server can inspect the IP datagram to look for the destination
address in the IP header.</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Here be dragons. TODO: slay the dragons.</t>
      <section anchor="traffic-analysis" numbered="true" toc="default">
        <name>Traffic Analysis</name>
        <t>While MASQUE Obfuscation ensures that proxied traffic appears similar to
regular HTTP traffic, it doesn't inherently defeat traffic analysis. However,
the fact that MASQUE leverages QUIC allows it to segment STREAM frames over
multiple packets and add PADDING frames to change the observable
characteristics of its encrypted traffic. The exact details of how to change
traffic patterns to defeat traffic analysis is considered an open research
question and is out of scope for this document.</t>
        <t>When multiple MASQUE Obfuscation servers are available, a client can leverage
QUIC connection migration to seamlessly transition its end-to-end QUIC
connections by treating separate MASQUE Obfuscation servers as different paths.
This could afford an additional level of obfuscation in hopes of rendering
traffic analysis less effective.</t>
      </section>
      <section anchor="untrusted-servers" numbered="true" toc="default">
        <name>Untrusted Servers</name>
        <t>As with any proxy or VPN technology, MASQUE Obfuscation hides some of the
client's private information (such as who they are communicating with) from
their network provider by transferring that information to the MASQUE server.
It is paramount that clients only use MASQUE Obfuscation servers that they
trust, as a malicious actor could easily setup a MASQUE Obfuscation server and
advertise it as a privacy solution in hopes of attracting users to send it
their traffic.</t>
      </section>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>We will need to register the "masque-udp-proxy" and "masque-ip-proxy" extended
HTTP CONNECT protocols.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="MASQUE">
          <front>
            <title>The MASQUE Protocol</title>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="9" month="September" year="2020"/>
            <abstract>
              <t>   This document describes MASQUE (Multiplexed Application Substrate
   over QUIC Encryption).  MASQUE is a framework that allows
   concurrently running multiple networking applications inside an
   HTTP/3 connection.  For example, MASQUE can allow a QUIC client to
   negotiate proxying capability with an HTTP/3 server, and subsequently
   make use of this functionality while concurrently processing HTTP/3
   requests and responses.

   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/DavidSchinazi/masque-drafts.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schinazi-masque-protocol-02"/>
        </reference>
        <reference anchor="QUIC">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="Jana Iyengar">
              <organization>Fastly</organization>
            </author>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <date day="14" month="January" year="2021"/>
            <abstract>
              <t>   This document defines the core of the QUIC transport protocol.  QUIC
   provides applications with flow-controlled streams for structured
   communication, low-latency connection establishment, and network path
   migration.  QUIC includes security measures that ensure
   confidentiality, integrity, and availability in a range of deployment
   circumstances.  Accompanying documents describe the integration of
   TLS for key negotiation, loss detection, and an exemplary congestion
   control algorithm.

DO NOT DEPLOY THIS VERSION OF QUIC

   DO NOT DEPLOY THIS VERSION OF QUIC UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org (mailto:quic@ietf.org)), which is
   archived at https://mailarchive.ietf.org/arch/search/?email_list=quic

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-transport.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-transport-34"/>
        </reference>
        <reference anchor="HTTP3">
          <front>
            <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization>
            </author>
            <date day="2" month="February" year="2021"/>
            <abstract>
              <t>   The QUIC transport protocol has several features that are desirable
   in a transport for HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP semantics over QUIC.  This document also
   identifies HTTP/2 features that are subsumed by QUIC, and describes
   how HTTP/2 extensions can be ported to HTTP/3.

DO NOT DEPLOY THIS VERSION OF HTTP

   DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC.  This
   version is still a work in progress.  For trial deployments, please
   use earlier versions.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-http.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-http-34"/>
        </reference>
        <reference anchor="HTTP2">
          <front>
            <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
            <author fullname="M. Belshe" initials="M." surname="Belshe">
              <organization/>
            </author>
            <author fullname="R. Peon" initials="R." surname="Peon">
              <organization/>
            </author>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson">
              <organization/>
            </author>
            <date month="May" year="2015"/>
            <abstract>
              <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t>
              <t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7540"/>
          <seriesInfo name="DOI" value="10.17487/RFC7540"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <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">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <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="TLS13">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="TRANSPORT-AUTH">
          <front>
            <title>HTTP Transport Authentication</title>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="12" month="March" year="2021"/>
            <abstract>
              <t>   The most common existing authentication mechanisms for HTTP are sent
   with each HTTP request, and authenticate that request instead of the
   underlying HTTP connection, or transport.  While these mechanisms
   work well for existing uses of HTTP, they are not suitable for
   emerging applications that multiplex non-HTTP traffic inside an HTTP
   connection.  This document describes the HTTP Transport
   Authentication Framework, a method of authenticating not only an HTTP
   request, but also its underlying transport.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schinazi-httpbis-transport-auth-05"/>
        </reference>
        <reference anchor="HTTP2-TRANSPORT">
          <front>
            <title>Using HTTP/2 as a Transport for Arbitrary Bytestreams</title>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <date day="4" month="November" year="2019"/>
            <abstract>
              <t>   HTTP/2 provides multiplexing of HTTP requests over a single
   underlying transport connection.  HTTP/2 Transport defines the use of
   the bidirectional extended CONNECT handshake to negotiate the use of
   application protocols using streams of an HTTP/2 connection as
   transport.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-kinnear-httpbis-http2-transport-02"/>
        </reference>
        <reference anchor="ALT-SVC">
          <front>
            <title>HTTP Alternative Services</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." surname="Reschke">
              <organization/>
            </author>
            <date month="April" year="2016"/>
            <abstract>
              <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7838"/>
          <seriesInfo name="DOI" value="10.17487/RFC7838"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="HTTPSSVC">
          <front>
            <title>Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)</title>
            <author fullname="Ben Schwartz">
              <organization>Google</organization>
            </author>
            <author fullname="Mike Bishop">
              <organization>Akamai Technologies</organization>
            </author>
            <author fullname="Erik Nygren">
              <organization>Akamai Technologies</organization>
            </author>
            <date day="11" month="June" year="2020"/>
            <abstract>
              <t>   This document specifies the "SVCB" and "HTTPSSVC" DNS resource record
   types to facilitate the lookup of information needed to make
   connections for origin resources, such as for HTTPS URLs.  SVCB
   records allow an origin to be served from multiple network locations,
   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 HTTPSSVC DNS 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 proposal is inspired by and based on recent DNS
   usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long
   standing desires to have SRV or a functional equivalent implemented
   for HTTP).  These proposals each provide an important function but
   are potentially incompatible with each other, such as when an origin
   is load-balanced across multiple hosting providers (multi-CDN).
   Furthermore, these each add potential cases for adding additional
   record lookups in addition to AAAA/A lookups.  This design attempts
   to provide a unified framework that encompasses the key functionality
   of these proposals, as well as providing some extensibility for
   addressing similar future challenges.

   TO BE REMOVED: The specific name for this RR type is an open topic
   for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as
   they are easy to replace.  Other names might include "B", "SRV2",
   "SVCHTTPS", "HTTPS", and "ALTSVC".

   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-httpssvc-03"/>
        </reference>
        <reference anchor="I-D.schwartz-httpbis-helium">
          <front>
            <title>Hybrid Encapsulation Layer for IP and UDP Messages (HELIUM)</title>
            <author fullname="Ben Schwartz">
              <organization>Google</organization>
            </author>
            <date day="25" month="June" year="2018"/>
            <abstract>
              <t>   HELIUM is a protocol that can be used to implement a UDP proxy, a
   VPN, or a hybrid of these.  It is intended to run over a reliable,
   secure substrate transport.  It can serve a variety of use cases, but
   its initial purpose is to enable HTTP proxies to forward non-TCP
   flows.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-schwartz-httpbis-helium-00"/>
        </reference>
        <reference anchor="I-D.pardue-httpbis-http-network-tunnelling">
          <front>
            <title>HTTP-initiated Network Tunnelling (HiNT)</title>
            <author fullname="Lucas Pardue">
	 </author>
            <date day="18" month="October" year="2018"/>
            <abstract>
              <t>   The HTTP CONNECT method allows an HTTP client to initiate, via a
   proxy, a TCP-based tunnel to a single destination origin.  This memo
   explores options for expanding HTTP-initiated Network Tunnelling
   (HiNT) to cater for diverse UDP and IP associations.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-pardue-httpbis-http-network-tunnelling-01"/>
        </reference>
        <reference anchor="RFC8441">
          <front>
            <title>Bootstrapping WebSockets with HTTP/2</title>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <date month="September" year="2018"/>
            <abstract>
              <t>This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8441"/>
          <seriesInfo name="DOI" value="10.17487/RFC8441"/>
        </reference>
        <reference anchor="RFC8471">
          <front>
            <title>The Token Binding Protocol Version 1.0</title>
            <author fullname="A. Popov" initials="A." role="editor" surname="Popov">
              <organization/>
            </author>
            <author fullname="M. Nystroem" initials="M." surname="Nystroem">
              <organization/>
            </author>
            <author fullname="D. Balfanz" initials="D." surname="Balfanz">
              <organization/>
            </author>
            <author fullname="J. Hodges" initials="J." surname="Hodges">
              <organization/>
            </author>
            <date month="October" year="2018"/>
            <abstract>
              <t>This document specifies version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS bindings spanning multiple TLS sessions and connections.  Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks.  To protect privacy, the Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8471"/>
          <seriesInfo name="DOI" value="10.17487/RFC8471"/>
        </reference>
        <reference anchor="I-D.sullivan-tls-post-handshake-auth">
          <front>
            <title>Post-Handshake Authentication in TLS</title>
            <author fullname="Nick Sullivan">
	 </author>
            <author fullname="Martin Thomson">
	 </author>
            <author fullname="Mike Bishop">
	 </author>
            <date day="5" month="August" year="2016"/>
            <abstract>
              <t>   This document describes a mechanism for performing post-handshake
   certificate-based authentication in Transport Layer Security (TLS)
   versions 1.3 and later.  This includes both spontaneous and solicited
   authentication of both client and server.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-sullivan-tls-post-handshake-auth-00"/>
        </reference>
        <reference anchor="I-D.ietf-httpbis-http2-secondary-certs">
          <front>
            <title>Secondary Certificate Authentication in HTTP/2</title>
            <author fullname="Mike Bishop">
              <organization>Akamai</organization>
            </author>
            <author fullname="Nick Sullivan">
              <organization>Cloudflare</organization>
            </author>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <date day="14" month="May" year="2020"/>
            <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-06"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>This proposal was inspired directly or indirectly by prior work from many
people. In particular, this work is related to
<xref target="I-D.schwartz-httpbis-helium" format="default"/> and
<xref target="I-D.pardue-httpbis-http-network-tunnelling" format="default"/>. The mechanism used to
run the MASQUE protocol over HTTP/2 streams was inspired by <xref target="RFC8441" format="default"/>.
Brendan Moran is to thank for the idea of leveraging connection migration
across MASQUE servers. The author would also like to thank
Nick Harper,
Christian Huitema,
Marcus Ihlar,
Eric Kinnear,
Mirja Kuehlewind,
Lucas Pardue,
Tommy Pauly,
Zaheduzzaman Sarker,
Ben Schwartz,
and
Christopher A. Wood
for their input.</t>
      <t>The author would like to express immense gratitude to Christophe A., an
inspiration and true leader of VPNs.</t>
    </section>
    <section numbered="false" anchor="design" toc="default">
      <name>Design Justifications</name>
      <t>Using an exported key as a nonce allows us to prevent replay attacks (since it
depends on randomness from both endpoints of the TLS connection) without
requiring the server to send an explicit nonce before it has authenticated the
client. Adding an explicit nonce mechanism would expose the server as it would
need to send these nonces to clients that have not been authenticated yet.</t>
      <t>The rationale for a separate MASQUE protocol stream is to allow
server-initiated messages. If we were to use HTTP semantics, we would only be
able to support the client-initiated request-response model. We could have used
WebSocket for this purpose but that would have added wire overhead and
dependencies without providing useful features.</t>
      <t>There are many other ways to authenticate HTTP, however the authentication
used here needs to work in a single client-initiated message to meet the
requirement of not exposing the server.</t>
      <t>The current proposal would also work with TLS 1.2, but in that case TLS false
start and renegotiation must be disabled, and the extended master secret and
renegotiation indication TLS extensions must be enabled.</t>
      <t>If the server or client want to hide that HTTP/2 is used, the client can set
its ALPN to an older version of HTTP and then use the Upgrade header to
upgrade to HTTP/2 inside the TLS encryption.</t>
      <t>The client authentication used here is similar to how Token
Binding <xref target="RFC8471" format="default"/> operates, but it has very different goals. MASQUE does
not use token binding directly because using token binding requires sending
the token_binding TLS extension in the TLS ClientHello, and that would stick
out compared to a regular TLS connection.</t>
      <t>TLS post-handshake authentication <xref target="I-D.sullivan-tls-post-handshake-auth" format="default"/>
is not used by this proposal because that requires sending the
"post_handshake_auth" extension in the TLS ClientHello, and that would stick
out from a regular HTTPS connection.</t>
      <t>Client authentication could have benefited from Secondary Certificate
Authentication in HTTP/2 <xref target="I-D.ietf-httpbis-http2-secondary-certs" format="default"/>,
however that has two downsides: it requires the server advertising that
it supports it in its SETTINGS, and it cannot be sent unprompted by the
client, so the server would have to request authentication.
Both of these would make the server stick out from regular HTTP/2 servers.</t>
      <t>MASQUE proposes a new client authentication method (as opposed to reusing
something like HTTP basic authentication) because HTTP authentication methods
are conceptually per-request (they need to be repeated on each request)
whereas the new method is bound to the underlying connection (be it QUIC or
TLS). In particular, this allows sending QUIC DATAGRAM frames without
authenticating every frame individually. Additionally, HMAC and asymmetric
keying are preferred to sending a password for client authentication since
they have a tighter security bound. Going into the design rationale, HMACs
(and signatures) need some data to sign, and to avoid replay attacks that
should be a fresh nonce provided by the remote peer. Having the server
provide an explicit nonce would leak the existence of the server so we use
TLS keying material exporters as they provide us with a nonce that contains
entropy from the server without requiring explicit communication.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAO6aS2AAA+1bXW8bOZZ956/gOg+dAJby5Z3uNtDYUdvp2DOJ7bHlDnYH
gwZVRUkcl4qaYpUVxfB/33PvJetDVjIzWGCful/aqmKRl/fz3ENmNBqp2tWF
PdYfJzd/uX2nL2fzJmSmdr5UZjar7P3eV7nPSrPCZ3ll5vUoZEtXmi9utDLh
H40d+W7o6NWRwl924avtsbaf10q5dXWs66oJ9ZtXr3589Ubd2e3GV/mxPi9r
W5W2Hp3StEqF2pT5b6bwJZba2qDW7lj/tfbZoQ6+qis7D/hru6I//qaUaeql
r46VHimN/1wZjvXB6VjfRPEO+LEIfnBq7l2+88pXC1O6Lyw4hrz3flFY/eHD
ibwOWNHWePH6D69e6clqvXT10ho81VemutuYrYzLXI29Hnz0TVkbV+pfnd0c
6hNTuLmvSmf0j0evjt7GsTSIVHNwW7raQqIa2graz7GArVxmZJxdGVdA30nV
Y2fr+R8X9HSc+ZVSajQaaTODjCaD6qZLFzTM1KxsWevchqxyM8z71JjjPc80
PjZ6ZbMl9BFWql6aWpui8JsAiUeFp2HlQsM8ujU2fsN2sOQdv1qvCyezBT2z
kDrHcHU2nV7d6I2d6WCre1uN9XRpddZUFeQstnoNlzMFydwEO8pMsCRL7WV1
XTVlybNjoP+8Vb7Sv15dxLk0i4nhWMsFEqhxYWlmsOG88issr2X5NByzllvV
lOQ4WJLEtbShJNonCxXq0tfkuDar9cr8HStiafiOrQLv/+T0ggXM7brwW6jK
tfvFrK7CR/CB6YcbndmqdnNe5VCbQK+32sB7aIWNKwraGWaqzZ2ll6py4Y48
YWFrVu8Mir+zOX8cln5T6g3khoy8BPZY8rANXsehYz0plQiPnUGleuObIoeA
Gr7IisJWGlPwFmzJynq6hTU260tTKBguOPLPe7ixNWFLn2W+nLtFg434tS1H
wTdVZhGh83qD3Y13nZF9i/x0g3xRkjbXPphirM/hqB5zkzowJ8eOLX2zWEK5
+MVCKrdaF5Yngmz0NfKBLw7ZFpi6cyWHbFLm2DZEDGsEqIZXZE0I7JLIYvQ9
3LTyJltqx4JB9dDgWJ+2I0n/rBBybBpiS8RsZRYy8RITwARxthhJ5++mv5DZ
2aAFXFH/9W/PJTf+keJ2jETzAtkGn/Em3rv6rJnpykIRrkamVJulg0xRCewp
kmqPaaZlXa/D8cuXC6SfZkbh/5KzWUpmL2Ma5i/Ci3FMDiuX54VV6hnl2crn
Tcah/vDM9X4+/p46fk8dv6eO31NHSh37I3zWuAJxto5SxEFJo+rh4T/k0U/n
o9PxLjxMwx4f9yaQwiKCoCSR3c7h9g5mUYBa+cjPR1CNFSclHVHUUwDiwzmw
GFwpiN6t/svt+QmApinDGmhxIB29YtlIp6N/NC4btQMfHyU29u8cgQBnKVNG
ePmWpqO/3u7MR6rGVCkh7JktwxwIH0+pSabkHPfyTcoyceY3P13/cvL9fx69
wnSzBtm0piRmK4QhogDxkvlQU5Z/9kyf+DKqQ1LMqZ07AEv+/fAs695yorca
2JvcMw/Aq7c304ND+b++uOS/r99BU9fvTunvm7PJhw/tH2nEzdnl7Qe8V/Gv
7suTy48f312cysd4qncefZz894HE3sHl1fT88mLy4YDUQCGj2pCnJIdgQdah
oKxgbkpHSFOpMLE1fj650q+PSGFQ1ZvXr3+EquTHD6+/P3p8VGRRWcyXCHD5
KVkUUWgq1n9RwCZrV8MovUS5tJyJUDdvA9wSPQOSXeU8KbShJ+h/4hNRKiQm
qbt0smqK2iH1aB6u2+FSdcgNZraEoWopNuIqql9oxbhX8GArVZsHXkjNpOex
qjw8W7djRm2xgVg3fkXL05iVwf5R3UitqQJbyROWSp84p8QQEngszBRIFIq8
shq+SgtRRUaIxJAMT94HEbsJFLi5qY1aGjh6IIvyG86WuwvCMmitJBvQDpCL
c070kqW/optPwAk3HEY7WpHYGpoKYbTVWeFY6s3Sx1JXGaxZSRVHLzorSGsG
61dU0RFMZVwRtaXDJfAdKpD2s6Fyw1Dh3kNkgT40Gi2a1AoGMHFZcgNABnIJ
Ndu2cEU0nXRRLysuamZfPunDok4cRfBAvD5YsfP5lTZ5jkzZpsqvznbIu2c/
laFK5I1avyxp6LVvGD08PPOlYMj05N+QW0SMrgInMkA8gA2d5bRZUEWrW/0d
ImwyQ8jkm1vQdyWBT5J9Z9dxK3EXVZQZge8ItqH4EmrIES4rZNAF9+XsoS6E
xioy8vTk6iXwGbDSN9bP2JkEhfrBUp5eUy2COs8l87XZ4bAnYud+lhDQwPN6
m1f77Ef4tNU/G5LBq2fX/rrdla2zGM9ZZXnvRhMBQsqLn0V/x3Y8J+V6oFXa
l+pEDTHSkG4Z/gDIAVsSqNUzlF5glmgVWkSceO4qmPure+sMq01WA4nuerVI
cshFk37znvchmrQRdkGaVSYdzkZpzfkmpDhTU2wCnoBdQUEEcgkBryt3b7Kt
WG+NBEJVhOzvyqxocktaKjC81m+/vrMg9ebaAklUjFgpiVW9n6lPC9EPujaN
1l14guVU7frf6GzpA5yBHPerNea8vHfBzQBA6y3tXGoeNYnd8xHXMYgwQVAO
GqDorpLh9yhaim2Q0pO0joAzqrKLpkAdljarjczZwDSSwKBBgV6EgyNi4raD
FiV8pjiuDLUAWbVds2BoR0uLTuHCc2pJRrWf6Q2BzRnKjoV24hZIeTGBUsFE
YczQUDU1zVBHKVJ2M+hvtoETQ2oUBJY8PMQhozQEmHe/nkmYmwj7hsoWKcjg
3HR6oN8N4DtkEWerGcUF8bgYGd/oZHXUtOp30ufS/K7QRWBdqVpwFeq79W6T
i4w8SwpoV1SxYqKT5cYud/O5jfAHQ4Fv55RVN1xxUVOAXIt+Ly9K+QVJcobk
TjNEw7IpqQWWP4DzHp7N47DR8g3U8okSHGN9F7o+9yt4m6B2OxPbuKbyGDAi
zLeqjfF+3PRN7nay9ACHk6PMrCotaoW7t9RIrtaG+meJ50ssfO/spq26iSWh
yhnfRVwe7QhxwxPyAVvhhubo6K1A2iVFkL43BVDGDlvAVcrVIXb6fcgRP1s3
KCzZy54rIUBcJTP3DEyfS0tppDHFJoRxd1/gFfv0LcimnYnYAF6MGP+xfj4p
iO6PqjocACFui+BlQ8+TtILCAdhoKTxRmerxC9XbE+pkhTkAoNqSKd/s5Jcn
FTTu8nnKLKky93JM64qvx2+pu8Cfr99Sb/bD0dEf0HAkv3rBO1Zsjwga0vzf
hV0DRbghEUGdCcfRPK4KZHE+TzMxtiUuI0KDbg/Ei8zgEsza1OKha+/KfkFm
vVJMt6l2N7BpQXZ8K8inJ/dYc5RRBAsIofxAqt5TTQfABek4yMTTthGfdKvS
YRJp8npycXN1eT0dTW6nZ0PSgPromQtdfz4iqaFuiEBo0bJ7U+KyzLooP+cn
KM0+c7wxdre+k0ALYpVWqNFQKE1kA9yBzp4WAYCUp4x7vbALD2zK46K6xjEN
9VIwegQLzw59cLrny0NSat8OoYeyhZmaS+ph0+MzyEviUw2AD0C0g6NXR5Si
9C++KXP01CumojRDE8it5JvIh5KEZsV+t+GMVqdux9ZNJeiA2qGmbMm/q8ub
qUo7hUP25WXQ0mSZtfmwBImSSW0pW4RmvWYnTU4zIHpTuul7K3lYjHq8WkkW
Pen8/tqGZrWONHbV/kAOPYnJJJEZgF21xVvymgMeaQ/2ol86ftPBrRwiRErZ
0m8UBW30rxAbdi2zIOLeYbtbtK2bNmFwjHdixmKC9rdBiKu+9mRnT0GHwGf9
anQ9nfJjmtKySNQ4874U7WtmhZJid9iHuHbIYph3YypOnk3iNa4Ipn6c3jJ3
6Xk3aJlXdZM/xr7EChUtRDXzMonbbJn+Q5GYu80k1BBTqW57qSYYYa/1ysNF
CndHNXMm/VygfGgJ/0OwwpV3UnsFVKu8YYzCS0qs8ow7jlkb6bFoxCADuBRI
jHa4SJJyyGdTXwZJ4ALAvrenV1gTqKIWJ8VAN98my6WaLBUdLZ6CvLxWZTGt
1Vf4fTqklwPpBIYhCEdxkfm1bRWamK8IGYAvIiFDy8RK9PCMsiKDHysKLK10
VTnxfYnNEeIbEy+poxGeMbpIb7axpK5EOPTetCiKszjN+e5zJMZPLi8u3p1M
YX4gAF65jLnNqkjU0MLkq4vKrIJOkDwxnOjyzCpxp29GbQXg5I/0VcLZ29zP
u+0ztF8hphO/H1NKZCTz6NWD1oFK5j30Q8hYPSdjIDkFUSL3GiLoiy79SNps
/Z0M2AcVqRsYS2MWra35DgMCjkFS9zF5XOQS5OseGOI+wGU2kHomH6ajm19P
mAL+4e0Pj4/Szs4borq7CQMl4SVkwjf/xciBPmoZ6bwMfj0K99mMdRnwFypo
TGRCac8lT8xs5ldWbYiEARo2+b+matFS1C0n3ZjtWXPzDtcnirulxdAXU8Te
uy80A/4OXhpEhvK9Ti/yJG2djaHcAZLEBB1QxF7RIR9mbLN8r9iwM6rk4725
6BCK8C3lcvFQyaum9fdYBSM6UgfxSKPJ1yM+VjxojxlSQStjJexCAV2pWQc4
Ts1dIsMLmmy4Yr3xo9kWxaiw5QJPYIy5+0xJMBGk/NZXeeL8akpXNbN7QHms
fMr6gStLGLS9t9cfNOSugItQQ+MZIYdHFIKItqrJakEj3alnZYm8sIwQeggL
yZSP7sK/ZqDz/2/7uH9qHojUWagzge6ZQIkJRNmJ26PWtgx8xBup1TQNyVB4
fxdjfUCvt0xkrGn4TKqYZP0bKs5EDJx4do/KpBOcEN8g9Z9RLz3j070FXkKs
y9PLYx0Ks02nfvycO+tppComiap4ePaEmiDTuWIvkwq188kauwhp0lGmTPRH
JHUiaqIg35cYGenSKW35HfXRy0QPoGTZPWTKWJ/5jWUqUlJIFnnoKF53TMgg
IF4xcLVQFwsGKTfT63eTj3oOa1gpQao9i+mXdFhDX01OT88v3qfBdDjNzJAw
h8xDca3AU7piZStiVzIurwRyO6op1QF2E/uZ5H5aimVulTa9JnhalfE2wF59
MISI7mCZmKFooMiD8rOlYr9nxCen2QNw0ZabHrrgOG3V8Q1WlJJIWysPiX/u
IHqygmIj9DDvyi0icGF7mBWwXCBATUXcSQ1hteWj2o+IanrCF89otBWQHCzS
F0Hzb8kZOtqJUWJItVgI+Dm0wIqDuVkCU7D8BenJ94sb+j9oje1VEd6pIIJ6
YhDaEZ1Pk7z3NlJYtyVfbaSbfO3pU5Oe9Q6fJinLlFu5kKLjhZQaJb30hV9s
95JYSz4dCXScNziQ+S60bKArmZHi4c8jLOBTrbYRQIlfNWVqQEiOF9861xNL
wG7QbdVWiv4yg2OIltMTVpEMt6JrjvG4M3ZmDLKoInzDoolk3CpWIB/KGrQi
KBTM0iG2fDpfQVlyjK3rZv3NcyYqjia/JwqGWuJaJo28PTRbNE+cANFJMR/5
ZYEnTI+6Wg0O6CR9n08uJk9Tt4Pj7EHsSJXIJFZKxB48wQfkT8qYjUCcq2Rb
/VJxC+nOF4EukmiS0alGYfNFOkwwwyeP6uG4bFYzyi0/HQCvBXuQzhjSNRu+
HUTFzlECklPQgv2WuOb4a0bu7PCMPYgpZzpdVWvrkWbGGu0kH+1lVB8Oh/dj
AC4YTaCAAMVGFgjdav2l6wRs4ZoVsCtZMQ7CfGgHB83CKLrwqG6I9qfbNHTb
hDJyh8EbgfuK2qI9t1gGHZegjTBUAfYKEYQAfE1Nyc+ULZBgPvrKlPH2GbHf
HQaARxjyqJg3GfLuSZrKZJUPYeegTTYgpGskbZgopca5XUpd0EnFmanWVDpP
llynqPFqXG1X5lB9RLlA7JwvyQDqXYWU9mfpt/DOVX83+s+NXRZ2A6seqg9N
hi1fsYoP1RSJY4tfTbE9VP9jljZvvnwxdBfrxlR3tODPKCo30WqH1PFHEfya
zhsnY/3J+1xFdThynXVTj4X0Huwsbcp+XgtSWsFREbCsoZpO0vCymxtTE6mg
xDimrYRIHITfmCGA3pFh4+HaqQ1uUeo/Ia8IFRvDNOfnX4mHW2GgS5KKqSzm
yzmBlJ6OACIMaYLQk3wRgk9FAMqQRRB1ATmZeh7KHbldM/gkjgjC+lVJO+Wg
mXkUB7xkGrc9gxwSSy/SQZAShmmHk+id4UBcypl1lHIm1ISLZwADFrh3xq8n
ed7ttz9BF0RiLFJHBPcpy4aWWVQp1bE0GBOsTCMoK9YDzvVLcy801YwpkoFg
W5v8RMxrCsE15gk4aCM4NTPdNdDYyoz4UhRPC7BHp5mBic2NlSOq2Kxwcg2I
GhIiHPJr3i8Xr5lVJp2V9Zpd2VBvhdiTjFoaduVzOor8ZGPp4l3zweUnO7uh
A6y6Q2zrpmLdyiG2SWwtfwMgw9Qf3Z+MNBcnRvErQFJnQ++wkKp5rGHzpmjv
y42fXIWRywFy68YPzMAqOSQUa+9jzRpyboqzKk9HZucJJL+XZCksX+xRUTQC
DV5Zy3pUvSM4cv94l9aHoZdHl0h0S1eruvTIyzPYksObN0KhcOvF96+CBBZH
uRLSWc7Oyx5fv0Ki4HbLBbJ63h2QpVoM3XEhl3MpNsRwCiqTEYswnUvfCaWc
JpdrtMS5nM8H9GLVdtOm5BZnKaxBIrTepLuJg35ZjnxqRUh78oHApefGoaBs
SBUl3vRiP28b4tSm366Ra7FK5FdRKZv4pDue7egL2ZJ0QXKdoMe37vCynY+4
ftvIzdHU39lS/eyEiU319fvXdMDGZKgN0X6SvZiu7nA/X31or1tSu6nIc3hP
NLOexZk7xBIvEUWibzCoZe4jM8ytKA/5LQ0ZWDL18/RQjiDOgD58n+5mv+Tr
BIqiElB8zaeZfCUm9c3DPE+6xAM4dj1C2s3Dkq557+g0IaYGaOfelKO6CKPh
F/HgTDm5Jy0M/TZmmRQ33ZUqUz/ZvnAqNOtv7ay/0awH/xcVDO8lPDmhHafT
nN0d95JnvD+Z7hHeWHyeGzjGSe8ofOeIz7VkdFQdM6VDyjmkiUZ0ZBseHw9V
l/qMOCCxRLnfcCCEY3LLVm39ehg7jtQ+ISZT1eBK6aQfvnk3nZ5fvL+Jl9I5
hKUeCo/XlLDUinkGNl2q1fQv4vrL9YoE9xjCig0VCLxKIEOgRXu/fxX/CUF7
jpduvohq+1ZqbyqHjiQWR7KJpdsf//HUYId2ryyHoKLmtl7KBfi7WIRn6O6y
nWletM4q+WvfGkFJvwu0saYrYnTFEOU/KeQ5t8QJn/Ch3trKP+UA5qHL/XHk
C7pBTNe8WDW0s7gHunNCx66pBW6ILii2O8D++YzRVjwfpGh+sb8VivgxxRt/
cDqZTt5fdzxWAn0754iWMyGP6f3rjGIrME4QE92zOPs4ORHWK2yBqetKLmQw
0Kv4mhu1+R1ii/9oxoRAF8UZmOy3KsNaxRoVdKJrt1jGiih8JqtqrN97mhTA
1idilKB4C+tExqCe84EhXglOeSGGYu6DD0FJQLyNqSUdKOygbQ62eAePbpRA
QzYsI46NDEcKJny7oqs+a0uc+pm5H2INFYfvAcSxZ7HmLkIC6unphR/UcUIj
DPU4oUetrwyxici9sakQKov1mBZsWk5alhPgEv+Nh7L0D7jW23SHuksCEfl1
3UErdY8B4gz7v9g/ThMLPAAA

-->

</rfc>
