<?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.2.12 --> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8740" consensus="true"
     ipr="trust200902" docName="draft-ietf-httpbis-http2-tls13-03"
     category="std" updates="7540"> updates="7540" obsoletes="" submissionType="IETF"
     xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true"
     version="3">

  <front>
    <title>Using TLS 1.3 with HTTP/2</title>

    <seriesInfo name="RFC" value="8740"/>

    <author initials="D." surname="Benjamin" fullname="David Benjamin">
      <organization>Google LLC</organization>
      <address>
        <email>davidben@google.com</email>
      </address>
    </author>
    <date year="2019" month="October" day="17"/> year="2020" month="February"/>
    <area>Applications and Real-Time</area>
    <workgroup>HTTP</workgroup>

<keyword>HTTP</keyword>
<keyword>renegotiation</keyword>
<keyword>post-handshake client authentication</keyword>

 <abstract>
      <t>This document updates RFC 7540 by forbidding TLS 1.3 post-handshake
authentication, as an analog to the existing TLS 1.2 renegotiation restriction.</t>
    </abstract>

    <note title="Note to Readers">

<t><spanx style="emph">RFC EDITOR: please remove this section before publication</spanx></t>

<t>Discussion of this draft takes place on the HTTP working group mailing list
(ietf-http-wg@w3.org), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/">https://lists.w3.org/Archives/Public/ietf-http-wg/</eref>.</t>

<t>Working Group information can be found at <eref target="https://httpwg.org/">https://httpwg.org/</eref>; source
code and issues list for this draft can be found at
<eref target="https://github.com/httpwg/http-extensions/labels/http2-tls13">https://github.com/httpwg/http-extensions/labels/http2-tls13</eref>.</t>

    </note>

  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>TLS 1.2 <xref target="RFC5246"/> target="RFC5246" format="default"/> and earlier
      versions of TLS support renegotiation, a mechanism for changing
      parameters and keys partway through a connection. This was sometimes
      used to implement reactive client authentication in HTTP/1.1 <xref target="RFC7230"/>,
      target="RFC7230" format="default"/>, where the server decides whether or
      not to request a client certificate based on the HTTP request.</t>
      <t>HTTP/2 <xref target="RFC7540"/> target="RFC7540" format="default"/> multiplexes multiple HTTP requests over a single connection,
which is incompatible with the mechanism above. Clients cannot correlate the
certificate request with the HTTP request which that triggered it. Thus, Section
9.2.1 of <xref target="RFC7540"/>
target="RFC7540" sectionFormat="of" section="9.2.1"/> forbids
      renegotiation.</t>

      <t>TLS 1.3 <xref target="RFC8446"/> updates TLS 1.2 to remove target="RFC8446" format="default"/> removes
      renegotiation in favor of and replaces it with separate post-handshake
      authentication and key update mechanisms. The former shares Post-handshake authentication
      has the same problems with multiplexed protocols, protocols as TLS 1.2
      renegotiation, but the prohibition in <xref target="RFC7540"/> target="RFC7540"
      format="default"/> only applies to TLS 1.2 renegotiation.</t> renegotiation.

</t>

      <t>This document updates HTTP/2 <xref target="RFC7540"
      format="default"/> to similarly forbid TLS 1.3 post-handshake
authentication.</t>
    </section>

    <section anchor="requirements-language" title="Requirements Language">

<t>The numbered="true" toc="default">
      <name>Requirements Language</name>

        <t>
    The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<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 “OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

    </section>

    <section anchor="post-handshake-authentication-in-http2" title="Post-Handshake numbered="true" toc="default">
      <name>Post-Handshake Authentication in HTTP/2"> HTTP/2</name>
      <t>HTTP/2 servers MUST NOT <bcp14>MUST NOT</bcp14> send post-handshake TLS 1.3 CertificateRequest messages.
HTTP/2 clients MUST <bcp14>MUST</bcp14> treat such messages as connection errors (see Section 5.4.1
of <xref target="RFC7540"/>) target="RFC7540" sectionFormat="of" section="5.4.1"/>) of type PROTOCOL_ERROR.</t>
      <t><xref target="RFC7540"/> target="RFC7540" format="default"/> permitted renegotiation before the HTTP/2 connection preface to
provide confidentiality of the client certificate. TLS 1.3 encrypts the client
certificate in the initial handshake, so this is no longer necessary. HTTP/2
servers MUST NOT <bcp14>MUST NOT</bcp14> send post-handshake TLS 1.3 CertificateRequest messages before
the connection preface.</t>

      <t>The above applies even if the client offered the <spanx style="verb">post_handshake_auth</spanx>
      <tt>post_handshake_auth</tt> TLS extension. This extension is advertised
      independently of the selected ALPN Application-Layer Protocol Negotiation
      (ALPN) protocol <xref target="RFC7301"/>, target="RFC7301" format="default"/>, so it is not
      sufficient to resolve the conflict with HTTP/2. HTTP/2 clients that also
      offer other ALPN protocols, notably HTTP/1.1, in a TLS ClientHello MAY
      <bcp14>MAY</bcp14> include the <spanx style="verb">post_handshake_auth</spanx> <tt>post_handshake_auth</tt> extension to
      support those other protocols. This does not indicate support in
      HTTP/2.</t>
    </section>
    <section anchor="other-post-handshake-tls-messages-in-http2" title="Other numbered="true" toc="default">
      <name>Other Post-Handshake TLS Messages in HTTP/2"> HTTP/2</name>
      <t><xref target="RFC8446"/> target="RFC8446" format="default"/> defines two other messages that are exchanged after the handshake is
complete,
complete: KeyUpdate and NewSessionTicket.</t>
      <t>KeyUpdate messages only affect TLS itself and do not require any interaction
with the application protocol. HTTP/2 implementations MUST <bcp14>MUST</bcp14> support key updates
when TLS 1.3 is negotiated.</t>
      <t>NewSessionTicket messages are also permitted. Though these interact
      with HTTP when early data is enabled, these interactions are defined in
      <xref target="RFC8470"/> target="RFC8470" format="default"/> and are allowed for in the
      design of HTTP/2.</t>
      <t>Unless the use of a new type of TLS message depends on an interaction
      with the application-layer protocol, that TLS message can be sent after
      the handshake completes.</t>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This document resolves a compatibility concern between HTTP/2 and TLS 1.3 when
supporting post-handshake authentication with HTTP/1.1. This lowers the barrier
for deploying TLS 1.3, a major security improvement over TLS 1.2.</t>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>

<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC5246" target='https://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>

<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; 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="RFC7301" target='https://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>

<reference  anchor="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>

<reference  anchor="RFC8446" target='https://www.rfc-editor.org/info/rfc8446'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2018' month='August' />
<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="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8470.xml"/>
      </references>

    <references title='Informative References'>

<reference  anchor="RFC8470" target='https://www.rfc-editor.org/info/rfc8470'>
<front>
<title>Using Early Data in HTTP</title>
<author initials='M.' surname='Thomson' fullname='M. Thomson'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='W.' surname='Tarreau' fullname='W. Tarreau'><organization /></author>
<date year='2018' month='September' />
<abstract><t>Using TLS early data creates an exposure to the possibility of a replay attack.  This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data.  Techniques are described that use these mechanisms to mitigate the risk of replay.</t></abstract>
</front>
<seriesInfo name='RFC' value='8470'/>
<seriesInfo name='DOI' value='10.17487/RFC8470'/>
</reference>
    </references>
  </back>

<!-- ##markdown-source:
H4sIAHHHqF0AA61Y73PbuBH9jr8CTb/c3UiyJTvNRe1kzme7Z09ly5Xl6XTa
jg8iVxLOFMECoBU1k/+9bwGQopT02g/NZCKQxI/dt2/fLtLv94XXvqCxfHK6
XMn55FEOB2dyq/1a3sznDycjkZusVBtMya1a+r4mv+yvva8W2oXfUd8XbnjW
Pz0TmfK0MnY3ls7noq5yPLuxfPf2/FQIXdmx9LZ2fnR6+v50JJQlNZYXVVVo
LNSmdFKVuZyRKvpzvSGxNfZlZU1djYMtQlR6LP/mTdaTzlhvaekw2m148A/h
PFY/q8KUsHVHTghV+7WxYyH7QsY/uoQ5VwP5I5W/qI0um/fRwSv1qvMvvhm7
UqX+V7BwLH8yZlWQnEwum++0UboAOrx4QeUPqzBjkJmNEKWxGyx8JRghZ3+8
HA2H79Pw7ej8d2n4bnR22gzPTofNEKil4ffnPFfocnm03/fn7zBHiH6/L9XC
easyL8R8rZ1E2OoNlV6mMPD0EAm52Enss9B53g15ZZzvrwGhW6sXCthhdYpM
TyoODv4C35X0RuKrpI/a+f0eI2mpRPy9DmvwBIN0xuNBNLE0np7v+R9vnhHn
nCzC9B1bdn11O5/OxrIqSDnC2o15JZwCTxyFPeSCYDbJql40hPlOiCvtsto5
/m6WcX7gqfTwwmE7lZHER7aXSSSZVGxzIJbk2PFTAU/ENy23+9vVD9uzAUL/
bU9u1zpbS2ysbLYG9rlUXv6Bp7nxyQmvdIM4+eQiznAnD8HIk+6GJx+Awl/S
6T+F09uAwsBMsYeITF0eHsC/21XY/sPvQfzaZiQyk1PIFu1cDT/ZCo5qF4Gj
HUW74wrZXS+YoWnz8NOnj55KRtKdFGpBhTvppPeHFMINaFOQEL+Vt6W3Jq9D
bMC5RIFPnxK3P38O9pGyhSYrXV1VyNlDioBWckMZWKfdJpjP4xUAEpWyyEkP
goRtXmiHYCrrt2oHH4Heao3FmSnLyI6BDKzfgqfOYCH0w8naIVjeCL0BrUIy
QHIyzh+ZwSo8H9IcAYmqNxwMoyecmp8/MwfIMh1JOLKv8CenTOc4Ah/w1nJK
WPonQuHZrLh5RtbrJe9NcqHYlg4RRZoOXKPQpgORoYBuUxdew+iPOKIZR/6m
ZU4aNkNJ1m182yPREy1hdYkYV3BtgRlB0/n0PeJqgU0G8jKY65gwyFBsZS0V
bDT723Wi8bDdqmtRyhOk/GoFsEBNz0GpodGP0TLxfjACsMjTrqtRi9whMwYN
o87iXFZAzG20rGFbQD0oxaH0II5L9Qo+4SxHzCVP4lDhjkOfWJaO2IPk2AnO
IrthGq9RtVwkAvgpK2uA7cZFSPZRy/kLKpUp4P6i9gEtvFrrhW4s7IAgTFns
pOJSyLubryvq4D9JeyIQ1jm90QVSrpH4/03esTESeoY4ahvyxMkJ8rBWK+Ij
KQAD4USU3tw9Pc7f9OKvvJ+G8ez6z0+3s+srHj/eXEwm7aCZ8XgzfZrgu0ij
/crL6d3d9f1VXIy38ujV3cVf8cPReTN9mN9O7y8mbxg9FjrRIqE4Ow3LnS4h
GpWFdORctJCjmdULpmMpf7x8kMPzCDyXYjDq06ffML2G784RBSRzGc8K8YiP
ACqEBkrGe6iiQKJU2isOLcvN2mxLyfoQYXxgpG9aml18XWFGbdpHQXGyARQv
YMARWZswXu6zcZbSDkLnECg3aDbMUjqHDdEloZi4GpnZTGSj93IhyVqD479x
RE2iyreD88FQHCbqt6HA7iqSD7PpfHo5nfz9+Xo2m87gdjefK7Ib7Rn+w5xM
5buRDTZ0bwQCtuRKDbFGlqCTCoq2xC+gU4X2u1je6SvaOmjRoTKzu8q7zsQD
/dJRfnWpeVPZwsv9ZKyc+FsaiR4SEiZhHENmd4MmZv+vWCUwRLDzCxQGMemC
OreiQK8E9hxgYJbLILT86mc24rk14pkT/Gc2RbRlPZXI9jm0NPkrW+lCfuRU
wR3sXLRoOypgG75eTB7uRaNpiRboVbk2AjvtI3LMtCVcDuYFcXameI1B53ii
J4rVI3F1II8469dgKzLLROekCcWVD+8KKg5SCxjZ1Oqe4MQMwMdadkNFYSSk
g0tgUef0Kxjt8WD9jG0KAmPQhcbT24MTgLmh6CsQi7xqmps2uaMSTMPyIz1g
I+8aGnTUoFvmclrqkgvB1iQbWuJEgCw336FXYpVbem5A4OCeg9BGLv0FZLAn
/0S7p1jVWNruaftIoWOe6+yFuAHZT2jPiQUJMUDA2GTtQYVl2CA3wXsbywVe
7aLoqljk2+ZA7W92LYZtwNuWLN38QkY1OO7rsAua3KYUkyxJCuUw/NiXjsax
ZcyjVo44eqFthG2OWpP3d914FIXqibMVn0YliEZ572hRvKziiBipvC3nfCGL
na9AoTBbfOK2NgkPipFehYtKS5OnsoDJ4WvNjAPEcHEbhRZP7HlySsb85Njw
XaxjS9uQiQ7m/ULtOuztRep090sXBBcK6JckahnkIp1RHGrLSnwJ76HMNobu
uClJOe9Cex67Tx0EHAIAMeYj/ZaoYX6gVPv/DoiASCzga9Kvt2z7/6WABqTk
ZMxtxHOhrMXVQ3AAAF1hdp37brh6qF/wyTVugZIoPfGeEJrr1IRF728v7i/+
i+drFapHmJlIkm5NC5W9iH8DTXowSW4RAAA=

-->

</rfc>