One document matched: draft-bishop-support-reneg-00.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY http2 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-httpbis-http2.xml'>
  <!ENTITY rfc2119 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
  <!ENTITY rfc5746 PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5746.xml'>
  <!ENTITY care PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thomson-tls-care.xml'>
  <!ENTITY catch PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.thomson-httpbis-catch.xml'>
  <!ENTITY overversion PUBLIC '' 'http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.nottingham-http-over-version.xml'>
]>

<rfc ipr="trust200902" docName="draft-bishop-support-reneg-00" category="info">
  <!-- xmlns:x="http://purl.org/net/xml2rfc/ext">
  <x:feedback template="mailto:michbish@microsoft.com?subject={docname},%20%22{section}%22&body=<{ref}>:"/> -->
  <front>
    <title abbrev="Renegotiation Extension to HTTP/2">TLS Renegotiation Support Extension to HTTP/2</title>

    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Microsoft</organization>
      <address>
        <email>michbish@microsoft.com</email>
      </address>
    </author>

    <date month="March" year="2015" />
    <area>Applications</area>
    <workgroup>HTTPbis Working Group</workgroup>
    <keyword>HTTP</keyword>

    <abstract>
      <t>
        The HTTP/2 spec requires that TLS renegotiation not be employed when the negotiated application
        protocol is HTTP/2.  This document defines an extension to HTTP/2 which permits renegotiation
        to be employed by peers which mutually consent to do so, while allowing peers to understand
        whether renegotiation is permitted before attempting it.
      </t>
    </abstract>

  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
        The <xref target="I-D.ietf-httpbis-http2">HTTP/2 spec</xref> restricts TLS renegotiation to before
        the transmission of the HTTP/2 connection preface.
        TLS renegotiation is broadly employed to permit the use of client certificates 
        as an authentication mechanism.  The use of client certificates is required by law in certain 
        jurisdictions and required to support upgrading existing applications to HTTP/2 transparently.  Although 
        other mechanisms have been proposed (<xref target="I-D.thomson-tls-care"/>, <xref target="I-D.thomson-httpbis-catch"/>, 
        <xref target="I-D.nottingham-http-over-version"/>, the HTTP_1_1_REQUIRED error code in <xref target="I-D.ietf-httpbis-http2"/>),
        these uniformly require a separate TCP connection.  
        On this separate TCP connection, the client would employ either a changed TLS semantic that must be 
        understood by both sides, or renegotiation underneath an application protocol which does not prohibit it.
      </t>

      <t>
        This document defines an extension which permits mutually-consenting HTTP/2
        implementations to perform renegotiation on the existing HTTP connection 
        when the security properties of renegotiation are
        acceptable for their scenarios and the TLS version in use supports it.
      </t>
      
      <section title="Conventions and Terminology">
        <t>
          The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
          NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
          described in <xref target="RFC2119">RFC 2119</xref>.
        </t>
        <t>
          All numeric values are in network byte order.  Values are unsigned unless otherwise
          indicated.  Literal values are provided in decimal or hexadecimal as appropriate.
          Hexadecimal literals are prefixed with <spanx style="verb">0x</spanx> to distinguish them
          from decimal literals.
        </t>
      </section>
    </section>

    <section anchor="setting" title="The TLS_RENEG_PERMITTED Setting">
      <t>
        This document defines a new setting value in HTTP/2, TLS_RENEG_PERMITTED, with code TBD and an
        initial value of 0x00.
      </t>
      <figure title="Setting Value Definition">
        <preamble>
          The thirty-two bits of the setting value are interpreted as follows:
        </preamble>
        <artwork type="inline">
          <![CDATA[
   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        Reserved (30)                      |S|C| 
  +---------------------------------------------------------------+
]]>
        </artwork>
      </figure>
      <t>
        The effective state for an HTTP/2 connection is the bitwise AND of the values sent by each peer.
      </t>
      <t>
        Either peer is permitted to initiate TLS renegotiation if this behavior is mutually agreeable.
        The recipient MUST treat a TLS renegotiation as a connection error of type PROTOCOL_ERROR if support
        for renegotiation has not previously been agreed upon.
      </t>
      <t>
        The defined bits are:
        <list style="hanging">
          <t hangText="C (Bit 0)">If set, client-initiated renegotiation is allowed.</t>
          <t hangText="S (Bit 1)">If set, server-initiated renegotiation is allowed.</t>
        </list>
        All other bits are undefined, and MUST be zero when sent and ignored upon receipt.
      </t>
    </section>

    <section title="Security Considerations">
      <t>
        In <xref target="RFC5746"/>, an attack is described in which renegotiation can be exploited by an
        intermediary to inject attacker-controlled content before the content contained in the TLS connection
        the client believes it has established with the server.  The TLS extension described in that document
        cryptographically ties the sessions and prevents the attack described.
      </t>
      <t>
        HTTP/2 includes attributes which would make a similar attack more challenging than in HTTP/1.1.
        Thus, renegotiation in HTTP/2 may be preferable to renegotiation
        under an HTTP/1.1 connection.  Implementers will need to consider the security context of 
        the current connection when deciding when to offer this extension.
      </t>
    </section>

  <section title="IANA Considerations">
      <t>
        A new setting is defined for HTTP/2 in the "HTTP/2 Settings" registry.
        
        <list style="symbols">
          <t>Name:  TLS_RENEG_PERMITTED</t>
          <t>Code:  TBD</t>
          <t>Initial value:  0x00</t>
          <t>Specification:  This document</t>
        </list>
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc2119;
      &http2;
    </references>
    <references title="Informative References">
      &care;
      &catch;
      &overversion;
      &rfc5746;
    </references>


  </back>
</rfc>