<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-httpbis-optimistic-upgrade-06" number="9931" category="std" consensus="true" submissionType="IETF" updates="9112, 9298" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" prepTime="2026-03-06T11:44:38" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-upgrade-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9931" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Optimistic HTTP Upgrade Security">Security Considerations for Optimistic Protocol Transitions in HTTP/1.1</title>
    <seriesInfo name="RFC" value="9931" stream="IETF"/>
    <author fullname="Benjamin M. Schwartz" initials="B" surname="Schwartz">
      <organization showOnFrontPage="true">Meta Platforms, Inc.</organization>
      <address>
        <email>ietf@bemasc.net</email>
      </address>
    </author>
    <date month="03" year="2026"/>
    <area>WIT</area>
    <workgroup>httpbis</workgroup>
    <keyword>Request Smuggling</keyword>
    <keyword>False Start</keyword>
    <keyword>HTTP CONNECT</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">In HTTP/1.1, the client can request a change to a new protocol on the existing connection.  This document discusses the security considerations that apply to data sent by the client before this request is confirmed and adds new requirements to RFCs 9112 and 9298 to avoid related security issues.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9931" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2026 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview">Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-possible-security-issues">Possible Security Issues</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-request-smuggling">Request Smuggling</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-parser-exploits">Parser Exploits</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operational-issues">Operational Issues</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-impact-on-http-upgrade-with">Impact on HTTP Upgrade with Existing Upgrade Tokens</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-tls">"TLS"</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-websocket-websocket">"WebSocket"/"websocket"</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connect-udp">"connect-udp"</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-connect-ip">"connect-ip"</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-guidance-for-future-upgrade">Guidance for Future Upgrade Tokens</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-selection-of-request-method">Selection of Request Methods</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-http-conne">Requirements for HTTP CONNECT</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="overview" numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-overview">Overview</name>
      <t indent="0" pn="section-1-1">This document discusses certain security considerations that arise when switching from HTTP/1.1 to a different protocol on the same connection.  It provides:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-2">
        <li pn="section-1-2.1">
          <t indent="0" pn="section-1-2.1.1">a review of the relevant standards,</t>
        </li>
        <li pn="section-1-2.2">
          <t indent="0" pn="section-1-2.2.1">a discussion of the security risks that may apply if a client sends data before the transition is confirmed,</t>
        </li>
        <li pn="section-1-2.3">
          <t indent="0" pn="section-1-2.3.1">a security evaluation of existing upgrade tokens, and</t>
        </li>
        <li pn="section-1-2.4">
          <t indent="0" pn="section-1-2.4.1">guidance for implementations and future standards documents.</t>
        </li>
      </ul>
      <t indent="0" pn="section-1-3">Updates to <xref target="RFC9112" format="default" sectionFormat="of" derivedContent="HTTP/1.1"/> and <xref target="RFC9298" format="default" sectionFormat="of" derivedContent="CONNECT-UDP"/>, including new normative requirements, are provided in Sections <xref target="connect" format="counter" sectionFormat="of" derivedContent="8"/> and <xref target="connect-udp" format="counter" sectionFormat="of" derivedContent="6.3"/>, respectively.</t>
    </section>
    <section anchor="conventions-and-definitions" numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here. 
</t>
    </section>
    <section anchor="background" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-background">Background</name>
      <t indent="0" pn="section-3-1">In HTTP/1.1 <xref target="RFC9112" format="default" sectionFormat="of" derivedContent="HTTP/1.1"/> and later, a single connection can be used for many requests.  In HTTP/2 <xref target="RFC9113" format="default" sectionFormat="of" derivedContent="HTTP/2"/> and HTTP/3 <xref target="RFC9114" format="default" sectionFormat="of" derivedContent="HTTP/3"/>, these requests can be multiplexed, as each request is distinguished explicitly by its stream ID.  However, in HTTP/1.1, requests are strictly sequential, and each new request is distinguished implicitly by the closure of the preceding request.</t>
      <t indent="0" pn="section-3-2">HTTP/1.1 is also the only version of HTTP that allows the client to change the protocol used for the remainder of the connection.  There are two mechanisms to request such a protocol transition.  One
mechanism is the Upgrade header field (<xref section="7.8" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.8" derivedContent="HTTP"/>).  When included
in a request, this field indicates that the client would like to use this connection for
a protocol other than HTTP/1.1. The server replies with a 101 (Switching Protocols) status code if it accepts the protocol change (<xref section="15.2.2" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-15.2.2" derivedContent="HTTP"/>).</t>
      <t indent="0" pn="section-3-3">The other mechanism is the HTTP CONNECT method (<xref section="9.3.6" sectionFormat="of" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-9.3.6" derivedContent="HTTP"/>).  This method indicates that the client wishes to establish a TCP connection to the specified host and port.  If accepted, the server replies with a 2xx (Successful) response to indicate that the request was accepted and a TCP connection was established.  After this point, the TCP connection is acting as a TCP tunnel, not an HTTP/1.1 connection.</t>
      <t indent="0" pn="section-3-4">Both of these mechanisms also permit the server to reject the request.  For example, <xref target="RFC9110" section="7.8" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.8" derivedContent="HTTP"/> says:</t>
      <blockquote pn="section-3-5">
        <t indent="0" pn="section-3-5.1">A server <bcp14>MAY</bcp14> ignore a received Upgrade header field if it wishes to continue using the current protocol on that connection.</t>
      </blockquote>
      <t indent="0" pn="section-3-6">and <xref target="RFC9110" section="9.3.6" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-9.3.6" derivedContent="HTTP"/> says:</t>
      <blockquote pn="section-3-7">
        <t indent="0" pn="section-3-7.1">A server <bcp14>MUST</bcp14> reject a CONNECT request that targets an empty or invalid port number, typically by responding with a 400 (Bad Request) status code.</t>
      </blockquote>
      <t indent="0" pn="section-3-8">Rejected upgrades are common and can happen for a variety of reasons, such as:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-9">
        <li pn="section-3-9.1">
          <t indent="0" pn="section-3-9.1.1">The server does not support any of the client's indicated upgrade tokens (i.e., the client's proposed new protocols), so it continues to use HTTP/1.1.</t>
        </li>
        <li pn="section-3-9.2">
          <t indent="0" pn="section-3-9.2.1">The server knows that an upgrade to the offered protocol will not provide any improvement over HTTP/1.1 for this request to this resource, so it chooses to respond in HTTP/1.1.</t>
        </li>
        <li pn="section-3-9.3">
          <t indent="0" pn="section-3-9.3.1">The server requires the client to authenticate before upgrading the protocol, so it replies with the status code 401 (Authentication Required) and provides a challenge in an Authorization response header field (<xref section="11.6.2" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-11.6.2" derivedContent="HTTP"/>).</t>
        </li>
        <li pn="section-3-9.4">
          <t indent="0" pn="section-3-9.4.1">The resource has moved, so the server replies with a 3xx (Redirection) status code (<xref section="3.4" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-3.4" derivedContent="HTTP"/>).</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-10">Similarly, servers frequently reject HTTP CONNECT requests, such as when:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-11">
        <li pn="section-3-11.1">
          <t indent="0" pn="section-3-11.1.1">The server does not support HTTP CONNECT.</t>
        </li>
        <li pn="section-3-11.2">
          <t indent="0" pn="section-3-11.2.1">The specified destination is not allowed under server policy.</t>
        </li>
        <li pn="section-3-11.3">
          <t indent="0" pn="section-3-11.3.1">The destination cannot be resolved, is unreachable, or does not accept the connection.</t>
        </li>
        <li pn="section-3-11.4">
          <t indent="0" pn="section-3-11.4.1">The proxy requires the client to authenticate before proceeding.</t>
        </li>
      </ul>
      <t indent="0" pn="section-3-12">After rejecting a request, the server will continue to interpret bytes received on that connection in accordance with HTTP/1.1.</t>
      <t indent="0" pn="section-3-13"><xref section="7.8" target="RFC9110" format="default" sectionFormat="of" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-7.8" derivedContent="HTTP"/> also states:</t>
      <blockquote pn="section-3-14">
        <t indent="0" pn="section-3-14.1">A client cannot begin using an upgraded protocol on the connection until it has completely sent the request message (i.e., the client can't change the protocol it is sending in the middle of a message).</t>
      </blockquote>
      <t indent="0" pn="section-3-15">In other words, completion of the request message is a <strong>necessary</strong> condition for the client to begin using the new protocol.  However, it is important to clarify that this is not a <strong>sufficient</strong> condition because the server might reject the request.</t>
      <t indent="0" pn="section-3-16">In some cases, the client might predict that the server is likely to accept a requested protocol transition.  For example, if a request using an upgrade token recently succeeded, the client might expect that subsequent requests with the same upgrade token will also succeed.  If this expectation is correct, the client can often reduce delay by immediately sending the first bytes of the new protocol "optimistically", without waiting for the server's response.  This document explores the security implications of this "optimistic" behavior.</t>
    </section>
    <section anchor="possible-security-issues" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-possible-security-issues">Possible Security Issues</name>
      <t indent="0" pn="section-4-1">When there are only two distinct parties involved in an HTTP/1.1 connection (i.e., the client and the server), protocol transitions introduce no new security issues: Each party must already be prepared for the other to send arbitrary data on the connection at any time.  However, HTTP connections often involve more than two parties if the requests or responses include third-party data.  For example, a browser (party 1) might send an HTTP request to an origin (party 2) with the path, headers, or content controlled by a website from a different origin (party 3).  Post-transition protocols, such as WebSocket <xref target="RFC6455" format="default" sectionFormat="of" derivedContent="WEBSOCKET"/>, are also frequently used to convey data chosen by a third party.</t>
      <t indent="0" pn="section-4-2">If the third-party data source is untrusted, then the data it provides is potentially "attacker-controlled".  The combination of attacker-controlled data and optimistic protocol transitions results in two significant security issues.</t>
      <section anchor="request-smuggling" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-request-smuggling">Request Smuggling</name>
        <t indent="0" pn="section-4.1-1">In a Request Smuggling attack (<xref section="11.2" sectionFormat="comma" target="RFC9112" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9112#section-11.2" derivedContent="HTTP/1.1"/>), the attacker-controlled data is chosen in such a way that it is interpreted by the server as an additional HTTP request.  These attacks allow the attacker to speak on behalf of the client while bypassing the client's own rules about what requests it will issue.  Request Smuggling can occur if the client and server have distinct interpretations of the data that flows between them.</t>
        <t indent="0" pn="section-4.1-2">If the server accepts a protocol transition request, it interprets the subsequent bytes in accordance with the new protocol.  If it rejects the request, it interprets those bytes as HTTP/1.1.  However, the client cannot know which interpretation the server will take until it receives the server's response status code.  If it uses the new protocol optimistically, this creates a risk that the server will interpret attacker-controlled data in the new protocol as an additional HTTP request issued by the client.</t>
        <t indent="0" pn="section-4.1-3">As a trivial example, consider an HTTP CONNECT client providing connectivity to an untrusted application.  If the client is authenticated to the proxy server using a connection-level authentication method such as TLS Client Certificates (<xref section="4.4.2" sectionFormat="comma" target="RFC8446" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-4.4.2" derivedContent="TLS"/>), the attacker could send an HTTP/1.1 POST request (<xref section="9.3.3" sectionFormat="comma" target="RFC9110" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9110#section-9.3.3" derivedContent="HTTP"/>) for the proxy server at the beginning of its TCP connection.  If the client delivers this data optimistically, and the CONNECT request fails, the server would misinterpret the application's data as a subsequent authenticated request issued by the client.</t>
        <figure align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-example-request-smuggling-a">Example Request Smuggling Attack Using HTTP CONNECT</name>
          <artwork align="left" pn="section-4.1-4.1">
## REQUESTS ##

# The malicious application requests a TCP connection to a nonexistent
# destination, which will fail.
CONNECT no-such-destination.example:443 HTTP/1.1
Host: no-such-destination.example:443

# Before connection fails, the malicious application sends data on the
# proxied TCP connection that forms a valid POST request to the proxy.
# The vulnerable client optimistically forwards this data to the proxy.
POST /upload HTTP/1.1
Host: proxy.example
Content-Length: 123456

&lt;POST body controlled by the malicious application&gt;

## RESPONSES ##

# When TCP connection establishment fails, the proxy responds by
# rejecting the CONNECT request, but the client has already forwarded
# the malicious TCP payload data to the proxy.
HTTP/1.1 504 Gateway Timeout
Content-Length: 0

# The proxy interprets the smuggled POST request as coming from the
# client.  If connection-based authentication is in use (e.g., using
# TLS client certificate authentication), the proxy treats this
# malicious request as authenticated.
HTTP/1.1 200 OK
Content-Length: 0</artwork>
        </figure>
      </section>
      <section anchor="parser-exploits" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-parser-exploits">Parser Exploits</name>
        <t indent="0" pn="section-4.2-1">A related category of attacks use protocol disagreement to exploit vulnerabilities in the server's request parsing logic.  These attacks apply when the HTTP client is trusted by the server, but the post-transition data source is not.  If the server software was developed under the assumption that some or all of the HTTP request data is not attacker-controlled, optimistic transmission can cause this assumption to be violated, exposing vulnerabilities in the server's HTTP request parser.</t>
      </section>
    </section>
    <section anchor="operational-issues" numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-operational-issues">Operational Issues</name>
      <t indent="0" pn="section-5-1">If the server rejects the transition request, the connection can continue to be used for HTTP/1.1.  There is no general requirement to close the connection in response to a rejected transition, and keeping the connection open has performance advantages if additional HTTP requests to this server are likely.  Thus, it is normally inappropriate to close the connection in response to a rejected transition.</t>
    </section>
    <section anchor="existing" numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-impact-on-http-upgrade-with">Impact on HTTP Upgrade with Existing Upgrade Tokens</name>
      <t indent="0" pn="section-6-1">This section describes the impact of this document's considerations on some registered upgrade tokens <xref target="IANA-UPGR" format="default" sectionFormat="of" derivedContent="IANA-UPGR"/> that are believed to be in use at the time of writing.</t>
      <section anchor="tls" numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-tls">"TLS"</name>
        <t indent="0" pn="section-6.1-1">The "TLS" family of upgrade tokens was defined in <xref target="RFC2817" format="default" sectionFormat="of" derivedContent="RFC2817"/>, which correctly highlights the possibility of the server rejecting the upgrade. If a client ignores this possibility and sends TLS data optimistically, the result cannot be valid HTTP/1.1: The first octet of a TLS connection must be 22 (ContentType.handshake), but this is not an allowed character in an HTTP/1.1 method (see <xref section="5.1" sectionFormat="comma" target="RFC8446" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8446#section-5.1" derivedContent="TLS"/> and <xref section="3" sectionFormat="comma" target="RFC9112" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9112#section-3" derivedContent="HTTP/1.1"/>).  A compliant HTTP/1.1 server will treat this as a parsing error and close the connection without processing further requests.</t>
      </section>
      <section anchor="websocketwebsocket" numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-websocket-websocket">"WebSocket"/"websocket"</name>
        <t indent="0" pn="section-6.2-1"><xref section="4.1" sectionFormat="of" target="RFC6455" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-4.1" derivedContent="WEBSOCKET"/> says:</t>
        <blockquote pn="section-6.2-2">
          <t indent="0" pn="section-6.2-2.1">Once the client's opening handshake has been sent, the client <bcp14>MUST</bcp14> wait for a response from the server before sending any further data.</t>
        </blockquote>
        <t indent="0" pn="section-6.2-3">Thus, optimistic use of HTTP Upgrade is already forbidden in the WebSocket protocol.  Additionally, the WebSocket protocol requires high-entropy masking of client-to-server frames (<xref section="5.1" sectionFormat="of" target="RFC6455" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-5.1" derivedContent="WEBSOCKET"/>).</t>
      </section>
      <section anchor="connect-udp" numbered="true" removeInRFC="false" toc="include" pn="section-6.3">
        <name slugifiedName="name-connect-udp">"connect-udp"</name>
        <t indent="0" pn="section-6.3-1"><xref section="5" sectionFormat="of" target="RFC9298" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9298#section-5" derivedContent="CONNECT-UDP"/> says:</t>
        <blockquote pn="section-6.3-2">
          <t indent="0" pn="section-6.3-2.1">A client <bcp14>MAY</bcp14> optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request.</t>
        </blockquote>
        <t indent="0" pn="section-6.3-3">However, in HTTP/1.1, this "proxying request" is an HTTP Upgrade request.  This upgrade is likely to be rejected in certain circumstances, such as when the UDP destination address (which is attacker-controlled) is invalid.  Additionally, the contents of the "connect-udp" protocol stream can include untrusted material (i.e., the UDP packets, which might come from other applications on the client device).  This creates the possibility of Request Smuggling attacks.  To avoid these concerns, this document replaces that text to exclude HTTP/1.1 from any optimistic sending, as follows:</t>
        <blockquote pn="section-6.3-4">
          <t indent="0" pn="section-6.3-4.1">A client <bcp14>MAY</bcp14> optimistically start sending UDP packets in HTTP Datagrams before receiving the response to its UDP proxying request but only if the HTTP version in use is HTTP/2 or later. Clients <bcp14>MUST NOT</bcp14> send UDP packets optimistically in HTTP/1.x due to the risk of Request Smuggling attacks.</t>
        </blockquote>
      </section>
      <section anchor="connect-ip" numbered="true" removeInRFC="false" toc="include" pn="section-6.4">
        <name slugifiedName="name-connect-ip">"connect-ip"</name>
        <t indent="0" pn="section-6.4-1">The "connect-ip" upgrade token is defined in <xref target="RFC9484" format="default" sectionFormat="of" derivedContent="CONNECT-IP"/>.  <xref section="11" sectionFormat="of" target="RFC9484" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9484#section-11" derivedContent="CONNECT-IP"/> forbids clients from sending packets optimistically in HTTP/1.1, avoiding this issue.</t>
      </section>
    </section>
    <section anchor="guidance-for-future-upgrade-tokens" numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-guidance-for-future-upgrade">Guidance for Future Upgrade Tokens</name>
      <t indent="0" pn="section-7-1">There are now several good examples of designs that reduce or eliminate the security concerns discussed in this document and may be applicable in future specifications:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7-2">
        <li pn="section-7-2.1">
          <t indent="0" pn="section-7-2.1.1">Forbid optimistic use of HTTP Upgrade (<xref section="4.1" sectionFormat="of" target="RFC6455" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-4.1" derivedContent="WEBSOCKET"/> and <xref section="11" sectionFormat="of" target="RFC9484" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9484#section-11" derivedContent="CONNECT-IP"/>).</t>
        </li>
        <li pn="section-7-2.2">
          <t indent="0" pn="section-7-2.2.1">Embed a fixed preamble that deliberately terminates HTTP/1.1 processing (<xref section="3.4" sectionFormat="of" target="RFC9113" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9113#section-3.4" derivedContent="HTTP/2"/>).</t>
        </li>
        <li pn="section-7-2.3">
          <t indent="0" pn="section-7-2.3.1">Apply high-entropy masking of client-to-server data (<xref section="5.1" sectionFormat="of" target="RFC6455" format="default" derivedLink="https://rfc-editor.org/rfc/rfc6455#section-5.1" derivedContent="WEBSOCKET"/>).</t>
        </li>
      </ul>
      <t indent="0" pn="section-7-3">Future specifications for upgrade tokens should account for the security issues discussed here and provide clear guidance on how implementations can avoid them.</t>
      <section anchor="selection-of-request-methods" numbered="true" removeInRFC="false" toc="include" pn="section-7.1">
        <name slugifiedName="name-selection-of-request-method">Selection of Request Methods</name>
        <t indent="0" pn="section-7.1-1">Some upgrade tokens, such as "TLS", are defined for use with any ordinary HTTP method.  The upgraded protocol continues to provide HTTP semantics and will convey the response to this HTTP request.</t>
        <t indent="0" pn="section-7.1-2">The other upgrade tokens mentioned in <xref target="existing" format="default" sectionFormat="of" derivedContent="Section 6"/> do not preserve HTTP semantics, so the method is not relevant.  All of these upgrade tokens are specified only for GET requests with no content.</t>
        <t indent="0" pn="section-7.1-3">Future specifications for upgrade tokens should restrict their use to GET requests with no content if the HTTP method is otherwise irrelevant and the request does not need to carry any message content.  This improves consistency with other upgrade tokens and simplifies server implementation.</t>
      </section>
    </section>
    <section anchor="connect" numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-requirements-for-http-conne">Requirements for HTTP CONNECT</name>
      <t indent="0" pn="section-8-1">This document updates <xref target="RFC9112" format="default" sectionFormat="of" derivedContent="HTTP/1.1"/> to include the remaining text of this section.  The requirements in this section apply only to HTTP/1.1.</t>
      <t indent="0" pn="section-8-2">Proxy clients that send CONNECT requests on behalf of untrusted TCP clients <bcp14>MUST</bcp14> do one or both of the following:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-8-3">
	<li pn="section-8-3.1" derivedCounter="1.">
          <t indent="0" pn="section-8-3.1.1">Wait for a 2xx (Successful) response before forwarding any TCP payload data.</t>
        </li>
        <li pn="section-8-3.2" derivedCounter="2.">
          <t indent="0" pn="section-8-3.2.1">Send a "Connection: close" request header.</t>
        </li>
      </ol>
      <t indent="0" pn="section-8-4">Proxy clients that don't implement at least one of these two behaviors are vulnerable to a trivial Request Smuggling attack (<xref section="11.2" sectionFormat="comma" target="RFC9112" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9112#section-11.2" derivedContent="HTTP/1.1"/>).</t>
      <t indent="0" pn="section-8-5">At the time of writing, some proxy clients are believed to be vulnerable as described.  As a mitigation, proxy servers <bcp14>MUST</bcp14> close the underlying connection when rejecting a CONNECT request without processing any further requests on that connection.  This requirement applies whether or not the request includes a "close" connection option.</t>
      <t indent="0" pn="section-8-6">Note that this mitigation will frequently cause slower connection establishment for correctly implemented clients, especially when returning a 407 (Proxy Authentication Required) response.  This performance loss can be avoided by using HTTP/2 or HTTP/3, which are not vulnerable to this attack.</t>
      <t indent="0" pn="section-8-7">As a performance optimization, proxy servers <bcp14>MAY</bcp14> disable this mitigation if the client is known to wait for a 2xx (Successful) response before forwarding untrusted TCP payload data (i.e., complying with item 1 above).  Proxy servers can identify compliant clients using the request's User-Agent header field and the user agent vendor's documentation regarding its compliance.</t>
    </section>
    <section anchor="security-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">This document describes security considerations related to optimistic use of protocol transitions in HTTP/1.1.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" removeInRFC="false" toc="include" pn="section-10">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-10-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <displayreference target="RFC9112" to="HTTP/1.1"/>
    <displayreference target="RFC9113" to="HTTP/2"/>
    <displayreference target="RFC9114" to="HTTP/3"/>
    <displayreference target="RFC6455" to="WEBSOCKET"/>
    <displayreference target="RFC9110" to="HTTP"/>
    <displayreference target="RFC8446" to="TLS"/>
    <displayreference target="RFC9484" to="CONNECT-IP"/>
    <displayreference target="RFC9298" to="CONNECT-UDP"/>
    <references anchor="sec-combined-references" pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references anchor="sec-normative-references" pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC9298" target="https://www.rfc-editor.org/info/rfc9298" quoteTitle="true" derivedAnchor="CONNECT-UDP">
          <front>
            <title>Proxying UDP in HTTP</title>
            <author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
            <date month="August" year="2022"/>
            <abstract>
              <t indent="0">This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows an HTTP client to create a tunnel for UDP communications through an HTTP server that acts as a proxy.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9298"/>
          <seriesInfo name="DOI" value="10.17487/RFC9298"/>
        </reference>
        <reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9110" quoteTitle="true" derivedAnchor="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="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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 indent="0">This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 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>
        <reference anchor="RFC9112" target="https://www.rfc-editor.org/info/rfc9112" quoteTitle="true" derivedAnchor="HTTP/1.1">
          <front>
            <title>HTTP/1.1</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="Reschke"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.</t>
              <t indent="0">This document obsoletes portions of RFC 7230.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="99"/>
          <seriesInfo name="RFC" value="9112"/>
          <seriesInfo name="DOI" value="10.17487/RFC9112"/>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references anchor="sec-informative-references" pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC9484" target="https://www.rfc-editor.org/info/rfc9484" quoteTitle="true" derivedAnchor="CONNECT-IP">
          <front>
            <title>Proxying IP in HTTP</title>
            <author fullname="T. Pauly" initials="T." role="editor" surname="Pauly"/>
            <author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
            <author fullname="A. Chernyakhovsky" initials="A." surname="Chernyakhovsky"/>
            <author fullname="M. Kühlewind" initials="M." surname="Kühlewind"/>
            <author fullname="M. Westerlund" initials="M." surname="Westerlund"/>
            <date month="October" year="2023"/>
            <abstract>
              <t indent="0">This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9484"/>
          <seriesInfo name="DOI" value="10.17487/RFC9484"/>
        </reference>
        <reference anchor="RFC9113" target="https://www.rfc-editor.org/info/rfc9113" quoteTitle="true" derivedAnchor="HTTP/2">
          <front>
            <title>HTTP/2</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">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 latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t>
              <t indent="0">This document obsoletes RFCs 7540 and 8740.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9113"/>
          <seriesInfo name="DOI" value="10.17487/RFC9113"/>
        </reference>
        <reference anchor="RFC9114" target="https://www.rfc-editor.org/info/rfc9114" quoteTitle="true" derivedAnchor="HTTP/3">
          <front>
            <title>HTTP/3</title>
            <author fullname="M. Bishop" initials="M." role="editor" surname="Bishop"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">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.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9114"/>
          <seriesInfo name="DOI" value="10.17487/RFC9114"/>
        </reference>
        <reference anchor="IANA-UPGR" target="https://www.iana.org/assignments/http-upgrade-tokens/" quoteTitle="true" derivedAnchor="IANA-UPGR">
          <front>
            <title>Hypertext Transfer Protocol (HTTP) Upgrade Token Registry</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <reference anchor="RFC2817" target="https://www.rfc-editor.org/info/rfc2817" quoteTitle="true" derivedAnchor="RFC2817">
          <front>
            <title>Upgrading to TLS Within HTTP/1.1</title>
            <author fullname="R. Khare" initials="R." surname="Khare"/>
            <author fullname="S. Lawrence" initials="S." surname="Lawrence"/>
            <date month="May" year="2000"/>
            <abstract>
              <t indent="0">This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2817"/>
          <seriesInfo name="DOI" value="10.17487/RFC2817"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" quoteTitle="true" derivedAnchor="TLS">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t indent="0">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 indent="0">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="RFC6455" target="https://www.rfc-editor.org/info/rfc6455" quoteTitle="true" derivedAnchor="WEBSOCKET">
          <front>
            <title>The WebSocket Protocol</title>
            <author fullname="I. Fette" initials="I." surname="Fette"/>
            <author fullname="A. Melnikov" initials="A." surname="Melnikov"/>
            <date month="December" year="2011"/>
            <abstract>
              <t indent="0">The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or s and long polling). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6455"/>
          <seriesInfo name="DOI" value="10.17487/RFC6455"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">This document benefited from valuable reviews and suggestions by:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-appendix.a-2">
        <li pn="section-appendix.a-2.1">
          <t indent="0" pn="section-appendix.a-2.1.1"><contact fullname="Mike Bishop"/></t>
        </li>
        <li pn="section-appendix.a-2.2">
          <t indent="0" pn="section-appendix.a-2.2.1"><contact fullname="Mohamed Boucadair"/></t>
        </li>
        <li pn="section-appendix.a-2.3">
          <t indent="0" pn="section-appendix.a-2.3.1"><contact fullname="Gorry Fairhurst"/></t>
        </li>
        <li pn="section-appendix.a-2.4">
          <t indent="0" pn="section-appendix.a-2.4.1"><contact fullname="Mark Nottingham"/></t>
        </li>
        <li pn="section-appendix.a-2.5">
          <t indent="0" pn="section-appendix.a-2.5.1"><contact fullname="Kazuho Oku"/></t>
        </li>
        <li pn="section-appendix.a-2.6">
          <t indent="0" pn="section-appendix.a-2.6.1"><contact fullname="Lucas Pardue"/></t>
        </li>
        <li pn="section-appendix.a-2.7">
          <t indent="0" pn="section-appendix.a-2.7.1"><contact fullname="David Schinazi"/></t>
        </li>
        <li pn="section-appendix.a-2.8">
          <t indent="0" pn="section-appendix.a-2.8.1"><contact fullname="Glenn Strauss"/></t>
        </li>
        <li pn="section-appendix.a-2.9">
          <t indent="0" pn="section-appendix.a-2.9.1"><contact fullname="Michael Sweet"/></t>
        </li>
        <li pn="section-appendix.a-2.10">
          <t indent="0" pn="section-appendix.a-2.10.1"><contact fullname="Willy Tarreau"/></t>
        </li>
        <li pn="section-appendix.a-2.11">
          <t indent="0" pn="section-appendix.a-2.11.1"><contact fullname="Martin Thomson"/></t>
        </li>
      </ul>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Benjamin M. Schwartz" initials="B" surname="Schwartz">
        <organization showOnFrontPage="true">Meta Platforms, Inc.</organization>
        <address>
          <email>ietf@bemasc.net</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
