<?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-httpbis-transport-auth-05" 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="HTTP Transport Authentication">HTTP Transport Authentication</title>
    <seriesInfo name="Internet-Draft" value="draft-schinazi-httpbis-transport-auth-05"/>
    <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>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>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <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>
      <t>Traditional HTTP semantics specify that HTTP is a stateless protocol where
each request can be understood in isolation <xref target="RFC7230" format="default"/>. However, the
emergence of QUIC <xref target="QUIC" format="default"/> as a new transport
protocol that can carry HTTP <xref target="HTTP3" format="default"/> and the existence
of QUIC extensions such as the DATAGRAM frame <xref target="DGRAM" format="default"/>
enable new uses of HTTP such as <xref target="WEBTRANS-H" format="default"/> and
<xref target="MASQUE" format="default"/> where some traffic is exchanged that
is disctinct from HTTP requests and responses. In order to authenticate this
traffic, it is necessary to authenticate the underlying transport (e.g., QUIC
or TLS <xref target="RFC8446" format="default"/>) instead of authenticate each request individually. This
mechanism aims to supplement the HTTP Authentication Framework <xref target="RFC7235" format="default"/>,
not replace it.</t>
      <t>Note that there is currently no mechanism for origin servers to request
that user agents authenticate themselves using Transport Authentication,
this is left as future work.</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>
        <t>This document uses the Augmented BNF defined in <xref target="RFC5234" format="default"/> and updated by
<xref target="RFC7405" format="default"/> along with the "#rule" extension defined in Section 7 of
<xref target="RFC7230" format="default"/>. The rules below are defined in <xref target="RFC3061" format="default"/>, <xref target="RFC5234" format="default"/>,
<xref target="RFC7230" format="default"/>, and <xref target="RFC7235" format="default"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  OWS           = <OWS, see {{RFC7230}}, Section 3.2.3>
  quoted-string = <quoted-string, see {{RFC7230}}, Section 3.2.6>
  token         = <token, see {{RFC7230}}, Section 3.2.6>
  token68       = <token, see {{RFC7235}}, Section 2.1>
  oid           = <oid, see {{RFC3061}}, Section 2>
]]></artwork>
      </section>
    </section>
    <section anchor="compute-proof" numbered="true" toc="default">
      <name>Computing the Authentication Proof</name>
      <t>This document only defines Transport Authentication for uses of HTTP with TLS.
This includes any use of HTTP over TLS as typically used for HTTP/2, or
HTTP/3 where the transport protocol uses TLS as its authentication and key
exchange mechanism <xref target="QUIC-TLS" format="default"/>.</t>
      <t>The user agent leverages a TLS keying material exporter <xref target="RFC5705" format="default"/> to
generate a nonce which can be signed using the user-id's key. The keying
material exporter uses a label that starts with the characters
"EXPORTER-HTTP-Transport-Authentication-" (see <xref target="schemes" format="default"/> for the labels
and contexts used by each scheme). The TLS keying material exporter is
used to generate a 32-byte key which is then used as a nonce.</t>
    </section>
    <section anchor="header-definition" numbered="true" toc="default">
      <name>Header Field Definition</name>
      <t>The "Transport-Authentication" header allows a user agent to authenticate
its transport connection with an origin server.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
  Transport-Authentication = tpauth-scheme *( OWS ";" OWS param )
  tpauth-scheme            = token
  param                    = token "=" ( token / quoted-string )
]]></artwork>
      <section anchor="directive-u" numbered="true" toc="default">
        <name>The u Directive</name>
        <t>The OPTIONAL "u" (user-id) directive specifies the user-id that the user
agent wishes to authenticate. It is encoded using
Base64 (Section 4 of <xref target="RFC4648" format="default"/>).</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    u = token68
]]></artwork>
      </section>
      <section anchor="directive-p" numbered="true" toc="default">
        <name>The p Directive</name>
        <t>The OPTIONAL "p" (proof) directive specifies the proof that the user agent
provides to attest to possessing the credential that matches its user-id.
It is encoded using Base64 (Section 4 of <xref target="RFC4648" format="default"/>).</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    p = token68
]]></artwork>
      </section>
      <section anchor="directive-a" numbered="true" toc="default">
        <name>The a Directive</name>
        <t>The OPTIONAL "a" (algorithm) directive specifies the algorithm used to compute
the proof transmitted in the "p" directive.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    a = oid
]]></artwork>
      </section>
    </section>
    <section anchor="schemes" numbered="true" toc="default">
      <name>Transport Authentication Schemes</name>
      <t>The Transport Authentication Framework allows defining Transport
Authentication Schemes, which specify how to authenticate user-ids. This
documents defined the "Signature" and "HMAC" schemes.</t>
      <section anchor="signature" numbered="true" toc="default">
        <name>Signature</name>
        <t>The "Signature" Transport Authentication Scheme uses asymmetric cyptography.
User agents possess a user-id and a public/private key pair, and origin
servers maintain a mapping of authorized user-ids to their associated public
keys. When using this scheme, the "u", "p", and "a" directives are REQUIRED.
The TLS keying material export label for this scheme is
"EXPORTER-HTTP-Transport-Authentication-Signature" and the associated
context is empty. The nonce is then signed using the selected asymmetric
signature algorithm and transmitted as the proof directive.</t>
        <t>For example, the user-id "john.doe" authenticating using Ed25519 <xref target="RFC8410" format="default"/>
could produce the following header (lines are folded to fit):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Transport-Authentication: Signature u="am9obi5kb2U=";
a=1.3.101.112;
p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo
aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ=="
]]></artwork>
      </section>
      <section anchor="hmac" numbered="true" toc="default">
        <name>HMAC</name>
        <t>The "HMAC" Transport Authentication Scheme uses symmetric cyptography.
User agents possess a user-id and a secret key, and origin servers maintain a
mapping of authorized user-ids to their associated secret key. When using this
scheme, the "u", "p", and "a" directives are REQUIRED.
The TLS keying material export label for this scheme is
"EXPORTER-HTTP-Transport-Authentication-HMAC" and the associated
context is empty. The nonce is then HMACed using the selected HMAC algorithm
and transmitted as the proof directive.</t>
        <t>For example, the user-id "john.doe" authenticating using
HMAC-SHA-512 <xref target="RFC6234" format="default"/> could produce the following
header (lines are folded to fit):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Transport-Authentication: HMAC u="am9obi5kb2U=";
a=2.16.840.1.101.3.4.2.3;
p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl
cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ=="
]]></artwork>
      </section>
    </section>
    <section anchor="proxy" numbered="true" toc="default">
      <name>Proxy Considerations</name>
      <t>Since Transport Authentication authenticates the underlying transport by
leveraging TLS keying material exporters, it cannot be transparently
forwarded by proxies that terminate TLS. However it can be sent over
proxied connections when TLS is performed end-to-end (e.g., when using
HTTP CONNECT proxies).</t>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Transport Authentication allows a user-agent to authenticate to an origin
server while guaranteeing freshness and without the need for the server
to transmit a nonce to the user agent. This allows the server to accept
authenticated clients without revealing that it supports or expects
authentication for some resources. It also allows authentication without
the user agent leaking the presence of authentication to observers due to
clear-text TLS Client Hello extensions.</t>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="iana-header" numbered="true" toc="default">
        <name>Transport-Authentication Header Field</name>
        <t>This document, if approved, requests IANA to register the
"Transport-Authentication" header in the "Permanent Message Header Field Names"
registry maintained at
<eref target="https://www.iana.org/assignments/message-headers/">https://www.iana.org/assignments/message-headers/</eref>.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +--------------------------+----------+--------+---------------+
  |    Header Field Name     | Protocol | Status |   Reference   |
  +--------------------------+----------+--------+---------------+
  | Transport-Authentication |   http   |  exp   | This document |
  +--------------------------+----------+--------+---------------+
]]></artwork>
      </section>
      <section anchor="iana-schemes" numbered="true" toc="default">
        <name>Transport Authentication Schemes Registry</name>
        <t>This document, if approved, requests IANA to create a new HTTP Transport
Authentication Schemes Registry with the following entries:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +---------------------------------+---------------+
  | Transport Authentication Scheme |   Reference   |
  +---------------------------------+---------------+
  |            Signature            | This document |
  +---------------------------------+---------------+
  |              HMAC               | This document |
  +---------------------------------+---------------+
]]></artwork>
      </section>
      <section anchor="iana-exporter-label" numbered="true" toc="default">
        <name>TLS Keying Material Exporter Labels</name>
        <t>This document, if approved, requests IANA to register the following entries in
the "TLS Exporter Labels" registry maintained at
<eref target="https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels">https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels</eref></t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +--------------------------------------------------+
  |                       Value                      |
  +--------------------------------------------------+
  | EXPORTER-HTTP-Transport-Authentication-Signature |
  +--------------------------------------------------+
  | EXPORTER-HTTP-Transport-Authentication-HMAC      |
  +--------------------------------------------------+
]]></artwork>
        <t>Both of these entries are listed with the following qualifiers:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  +---------+-------------+---------------+
  | DTLS-OK | Recommended |   Reference   |
  +---------+-------------+---------------+
  |    N    |      Y      | This document |
  +---------+-------------+---------------+
]]></artwork>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC7230">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7230"/>
          <seriesInfo name="DOI" value="10.17487/RFC7230"/>
        </reference>
        <reference anchor="RFC8446">
          <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="RFC7235">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding">
              <organization/>
            </author>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke">
              <organization/>
            </author>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems.  This document defines the HTTP Authentication framework.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7235"/>
          <seriesInfo name="DOI" value="10.17487/RFC7235"/>
        </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="RFC5234">
          <front>
            <title>Augmented BNF for Syntax Specifications: ABNF</title>
            <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker">
              <organization/>
            </author>
            <author fullname="P. Overell" initials="P." surname="Overell">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="68"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
        </reference>
        <reference anchor="RFC7405">
          <front>
            <title>Case-Sensitive String Support in ABNF</title>
            <author fullname="P. Kyzivat" initials="P." surname="Kyzivat">
              <organization/>
            </author>
            <date month="December" year="2014"/>
            <abstract>
              <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7405"/>
          <seriesInfo name="DOI" value="10.17487/RFC7405"/>
        </reference>
        <reference anchor="RFC3061">
          <front>
            <title>A URN Namespace of Object Identifiers</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling">
              <organization/>
            </author>
            <date month="February" year="2001"/>
            <abstract>
              <t>This document describes a Uniform Resource Name (URN) namespace that contains Object Identifiers (OIDs).  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3061"/>
          <seriesInfo name="DOI" value="10.17487/RFC3061"/>
        </reference>
        <reference anchor="RFC5705">
          <front>
            <title>Keying Material Exporters for Transport Layer Security (TLS)</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <date month="March" year="2010"/>
            <abstract>
              <t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes.  This document describes a general mechanism for allowing that.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5705"/>
          <seriesInfo name="DOI" value="10.17487/RFC5705"/>
        </reference>
        <reference anchor="RFC4648">
          <front>
            <title>The Base16, Base32, and Base64 Data Encodings</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <date month="October" year="2006"/>
            <abstract>
              <t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes.  It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4648"/>
          <seriesInfo name="DOI" value="10.17487/RFC4648"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <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="DGRAM">
          <front>
            <title>An Unreliable Datagram Extension to QUIC</title>
            <author fullname="Tommy Pauly">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="Eric Kinnear">
              <organization>Apple Inc.</organization>
            </author>
            <author fullname="David Schinazi">
              <organization>Google LLC</organization>
            </author>
            <date day="16" month="February" year="2021"/>
            <abstract>
              <t>   This document defines an extension to the QUIC transport protocol to
   add support for sending and receiving unreliable datagrams over a
   QUIC connection.

   Discussion of this work is encouraged to happen on the QUIC IETF
   mailing list quic@ietf.org (mailto:quic@ietf.org) or on the GitHub
   repository which contains the draft: https://github.com/quicwg/
   datagram (https://github.com/quicwg/datagram).

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-datagram-02"/>
        </reference>
        <reference anchor="WEBTRANS-H">
          <front>
            <title>WebTransport over HTTP/3</title>
            <author fullname="Victor Vasiliev">
              <organization>Google</organization>
            </author>
            <date day="27" month="January" year="2021"/>
            <abstract>
              <t>   WebTransport [OVERVIEW] is a protocol framework that enables clients
   constrained by the Web security model to communicate with a remote
   server using a secure multiplexed transport.  This document describes
   a WebTransport protocol that is based on HTTP/3 [HTTP3] and provides
   support for unidirectional streams, bidirectional streams and
   datagrams, all multiplexed within the same HTTP/3 connection.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-vvv-webtransport-http3-03"/>
        </reference>
        <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-TLS">
          <front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="Martin Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Sean Turner">
              <organization>sn3rd</organization>
            </author>
            <date day="14" month="January" year="2021"/>
            <abstract>
              <t>   This document describes how Transport Layer Security (TLS) is used to
   secure QUIC.

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/-tls.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-quic-tls-34"/>
        </reference>
        <reference anchor="RFC8410">
          <front>
            <title>Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure</title>
            <author fullname="S. Josefsson" initials="S." surname="Josefsson">
              <organization/>
            </author>
            <author fullname="J. Schaad" initials="J." surname="Schaad">
              <organization/>
            </author>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies algorithm identifiers and ASN.1 encoding formats for elliptic curve constructs using the curve25519 and curve448 curves.  The signature algorithms covered are Ed25519 and Ed448.  The key agreement algorithms covered are X25519 and X448. The encoding for public key, private key, and Edwards-curve Digital Signature Algorithm (EdDSA) structures is provided.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8410"/>
          <seriesInfo name="DOI" value="10.17487/RFC8410"/>
        </reference>
        <reference anchor="RFC6234">
          <front>
            <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
            <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
              <organization/>
            </author>
            <author fullname="T. Hansen" initials="T." surname="Hansen">
              <organization/>
            </author>
            <date month="May" year="2011"/>
            <abstract>
              <t>Federal Information Processing Standard, FIPS</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6234"/>
          <seriesInfo name="DOI" value="10.17487/RFC6234"/>
        </reference>
        <reference anchor="RFC7427">
          <front>
            <title>Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)</title>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen">
              <organization/>
            </author>
            <author fullname="J. Snyder" initials="J." surname="Snyder">
              <organization/>
            </author>
            <date month="January" year="2015"/>
            <abstract>
              <t>The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is a fixed hash algorithm tied to each group.  This document generalizes IKEv2 signature support to allow any signature method supported by PKIX and also adds signature hash algorithm negotiation.  This is a generic mechanism and is not limited to ECDSA; it can also be used with other signature algorithms.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7427"/>
          <seriesInfo name="DOI" value="10.17487/RFC7427"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank many members of the IETF community, as this
document is the fruit of many hallway conversations. Using the OID for the
signature and HMAC algorithms was inspired by Signature Authentication in
IKEv2 <xref target="RFC7427" format="default"/>.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAE2aS2AAA+1aa3PbuBX9jl+Byh+adEXZkh9JvPW28iOxun4klp1s0ul0
IBKSsOYrBGlFyXp/e88FQIqUrcTJbjudaTXjMUUC933PvReU53ksV3kod/nx
5eVLfpmJWKdJlvN+kU9lnCtf5CqJmRiNMnnzpVVB4sciArEgE+Pc0/5UxeKj
8qZ5no6U9vJyoyew0dvYZtgoJ0k23+XyQ8qYSrNdnmeFznsbG882euxazmdJ
FuzyQZzLLJa5d0ikGdO5iIN/ijCJwW4uNUvVLv97nvhtrsEgk2ONq3lEF/9g
jPgl2S7jHuP4qFjv8tZhhw+diC1z2wrfOhQ3Klh6lGQTEauPRk8seZEkk1Dy
k5MD+1iDo8zxoLuzscH7UTpVsIzAXf5SZNczMbfrfJVD19ZpUsS5UDF/reSs
zQ9EqMZJFivBn21tbG26tbSITNO6ilUuIVEOa2mejMFAZjC6XScjoULYvDR3
R8l8/NcJ3e34ScQY8zyPixFkFD5MdzmVPEp0DgZRlMSwvNK5iidcNLzJI+lP
obOONIdw1vUCCmms4TPox6Xwp8zcz+T7Quq8zeGVOh3J86nIy8dk91yKgFTA
El7EgczCOfEmKsxP4lj6xLwNg/MqXDr8zVSFREtqWZcLsXHNZzIMjYSVIoVG
QIAHEW3TrrkRPE5yrguVixFomQ0w48RonqahU1tbiaMizFUayg8sTmLP6Ahx
xmPlkxIqkNDUmmQhdIdfTpXmyIIiIhsFUvuZGkltlDUarkod/jxD7JE6MCE0
RLQaK9VdAjlJgyQOoU68ZPdRkXMR6oSrXNfturChi4NIBUEoGVujlMqSoDCi
809rqvb19v9R8j8bJWAeKOImQiu6BsAQcc11Kn01nlvdzTMoIgB+cGEoteZp
lgCCk5DPpjKTjDxfedWHKUbOmzpPIDnwT+kktKp9+vSHi+cHT3qbG7e3HX6c
zOSNzIxbmHGAjH1Jur66Ghxg8V/o/97AOzRo570vlL8oL7e3XJBgsZwtVGOV
cEZ8EscXWTa3ioAi/d9cIkmVi6ghXsk7JnZIElZKIj/guzYRoQtoK6wbD/uX
/RcX/VM+Jo8R9UP6ukQ9ELmYYMHtLZOxiTeSmOKSu7isiILCm6P9y4v+2dA7
NmRubm68mRwtairJummFZVh+2h++ujoyS6tCHAkNZ3ilJbDYOAolE0JWkauh
FSXPRAbGVozCVWlEb+zn0CiJeD2stDFPJiFFDNE7ABbkJbzM82Q5y5Vmjk0b
MUiskBWIHAE/3F0t741R/kh2Jp22sT9Dfl6eDF30PN3a2rm9fVwHkAbFRjyq
OFCo84UIw7nNSVZhBhcKuAGBdIGclyZPy+xcmZPkIxvC27e3bUZZmMk0FIhb
RYl1lpRAlxujQ3m/yDKQQqrGyQKxDOokmQLoIPky5IGRxQnODAkEScYFsoLM
v2S1SMvwBjFUaLLbKjBpM3IHSRHKcU4xNi7yAnKRLlQt1tb4QRLf0A4Kb3Ly
oRyrWNnvn9b8xVNXMNCu0fZAo8W5Gl622vY/Pzs31xdH8NnF0SFdD4/7JyfV
RblieHx+dYLnzF0tdh6cn54enR3azbjLl26d9t+2bGFpnb+8HJyf9U9ahDAm
5iqwJYCHKYFDihrKNJPUWEH3EoUNKu0fvOTdLRdUvW73GRLFRVj3yRayFVkT
W2YGZ+1XW0HSVIqMiCCuADApCkmIVhQs9DSZxZxcTyjbqAEm5SnA+sWEbkCM
/bPnEArmtiJZ9tu9zS0HR0UK9MCz0Zw56Nza2KZnaIkntvASwdZaVoSytcCp
OtGhrUj8CTKFNQGYvEk7NWwVJjNjuDvibG7sdBHqDeHaDULWSNUdCLjL2K+/
/orG9fzNkC8+e/zPuIGWXUreJFAKudnpdTZ/wMb3BRIp8NDOUnhjY+PGl0js
EIk8uZZxnbe58fCtO08/v3W7vrXX6dLGBDNFQ1/cqG8rjVlt+8EYijq1gyRK
C1PabYw08OdllgDnKBtpkQH3ZHy7HGEmTq0D9UpIMMDTKD8mjgCwHUsOBSAs
kCrw6pwWVusSgJQBYqp/8xT0gKq0Iqi6wvUetWumIVnfdHWH1FngelWgjQiO
mmoCHElJIQWkYWWVqiGnaww8bF5uDkKNuLYwtQBPYB8kxyW1C8QRdMnOEXIr
U+iAMJZCNCx3Mf7EJFmeMOzGRgAu2oyEepPZVKG6uC5HqwllikXg3LH0VPBH
TRxsellW7C4ro77goUDq2YKBDiuDHaqshro0y6EwsNbRTy/PLy6PLkz76VWu
9Zqu9Vr8kY01NAMoaDCG8QxRM4w0I7MC0nNAhbauG81tybRbHluxP2slYK3Z
CYytGWiz543muSsPxkzKwF1s2dhejYxoyg4/Ru0GredKhvWSgxifmideUN1z
dae1Su0Wt1sIjZMZ8an5fqnhYBRqi2hcdOzW7iJu1uROCWSreCPH89QcdFj7
8T89MqDX+r5l/qfwYcQfE6Y0ljVQwqALltjF93zcEt7ag4fd9foSRj4ukWTN
eLDghyoj1W4QD2tBee0Vzppl/eStAjRd5D7m1UI3ByhXs9yCqrUxN5g18Uzp
qdTLlkaLaHo/dNJJUKYJ2xda7mzxRyUAbhG62LTb2tl6isauMjmHDnslFDeV
S1col95RLoVyBixXq2YeNxWzsUPDBJpHp1qeU0OJqzTRyN0q6f1MBqSzcGmM
fPHJHMomGFmtw+4xBf8qU6SrTCFWmELcMYWAKUQ4QXzn02i1OaolvExyV3RY
zViUDZHKc9somB4Elq5I1gQXEBxFsCpzK8vS0EIWlCjByyrw5Tm5zHuLGPVu
mN3Po+0Aqhx10bPdGUyc67SbGsoaq6sGySg9RAkQ1FC3bFd6fNo/aDko1a6/
rtaQauV1iWk1Al+wjKsYeh5FEhnvc3+e5gkmy3Q677Cr2qjgAtThIGWtOYrh
aTEKlb+eZupGOKBOhcpcj2tgj5WjSCSUPbwUuExTsqobtLDwo4lhax8yHKRV
4K514ivTr1pOdLCr6cDG1ACbL8gCa522NWBBbX1aNvWiFkPatKPlNNFhny9L
rpDaalcxoVL10Nq55EqTCpVGzNVMk8VRmrvqbpuCss7d6QcwokEXU/xKr7Eq
AmqJZvjVUkrUgameVM/N0ZaIMK62G7Dc+jmZxp0gIeGb50RWmqOgt73dfeam
16dbXfS90KlA7U3NgaBt08YJZRJtcBX1UWh6SfIEngUWD8Yqf+w6/FXW3K1F
fbHXEtGzZKS2r0e9q73W90zsdTubne5Gt9Pt9r5n6V5r+Gb747uf/rYxOD5L
3/W2p8Hx6/m74f7NO7VfjHrbP+M6wfNwcBwkTLw5SwbHF1PRe/1xcHj14VTt
K/HTxcfBi3c3vtp//u5w0D27PNoevNrbay3QknKT2otI+GX22XR9UOL9hrzT
EjUip8Ctpxq/m2rsG1JtQfxOprH/0kyzVv/GJKPN9yeZ8W+VVOzfnlSMGHrD
47633e25zNqxs/tnMov95swyet6XVJhBdzpPtzY6XZNbm50tmqab+XU0PXt1
dToZ9d5ORtGz4m3vaiJemFzbFC/Cn8XB/sbbN3nI/Hm/e3o5mLyNwg1/vh+N
NgeTq43p/skl5dvRdDDEXz2/aET9MKfDJDoSz0R5fpTSbeTbUJEXV6Zavfbq
1aeCozlzw5yp85+ZUrQ5e8SkRkd0o3ICFfYkjiF6ZyIL7PhDItruh1pAmUUq
pvpIE3F5Ru1omanPTNq4x+y+oDZEaHNKZORCvKYyA58IK2QceHni4V95rjmr
UtWe3h+cn50dHVyWsjy2QxJawwLRfI9ZtXtyy1a/SGiMQ96945D5HjeLPzVH
oeSTAtMI8lGSeceZ1NPYgBt0oFEpKWy7HEs3/ttcJAKMcMplXjU5W+yqddfu
FYkTcrHbiOT7Ms1ZXVKYOVQGZkvuGRwjQgsDcJzKzUFuQjO0yWg0d7lm4u7h
hzkIh0JJkfnmKNu9Lynt1dzh2LGm9DyU4rqEoBTEylcXS7uhTDIqkT4oyA7M
x97MM0hHkXJg9MJADPa1Vw02Agb9s/5d7ysRU39vZoBVg2ljwLZbPIs9y+dG
yJQxnWli2pFBe3Hib3ibM+kJvRExLmZfnsLLgeAlMknEpNopHf5PZFOkM3Tv
usUs8WxelUGC6pz9mV506N319dls1iHZO0k2WUetQFth+vD1yBJ1Oun1H6qh
4ztv5ee7ey6Xl38HEr/Q6HJHXDOL/0JIZ4+wfjFv6wttll/IscxMFGDN7yXF
Su8SRzKREYiC3Vw0jwN/FykWw+aXBreL0pMu2Opj3FdEG9oZd+ImZ0s/RVkx
zi04V2dni0YWyzMA6u4DguNhnljRJH5lCHyWV+2zaKNrn6909EN5cdtaND+/
F69FHAHyfrRF+7Qs2kfl0eKJOaUsI6is5Z5pOX8LbN0NCMCUgfQWybPEv8W/
GZXyUHvmGE9SD7L0tfNhmkfhWlMt/cPDQ/Oune/6sPq8FmEh73/0MCeu4Pa1
8/R/hNsicr+Zm4nQ/QQIYn+TomUVK9SlhxRMwX0Q876gn3YpOPgelGmKcn8O
HiIGvfMfcXUh6Zc46BPB6fOI8hC6+JzZHDaftw/J6C/RtXmMSz4S/jW1KH3/
Ok5moQwm9oDs05po3rlln3bjIhpBk2CvNUavJVtuArdTLv16hwamUF27RlHE
10i9GPknaZ8ufyY0OLp8bn6sVMRoftt2qKu/+7VjIvrVAv0gNhkiU3R2MzHn
5l12pm0b1eFX1Qx5Pjgse9j6AU28PFRCUHpbhRDE/Ghmh0WUL5UFwMvgx6Ob
cjB8stV7Yl5NsX8Bz2b5948pAAA=

-->

</rfc>
