One document matched: draft-agl-tls-nextprotoneg-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
 <!ENTITY RFC0793 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml'>
 <!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
 <!ENTITY RFC2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
 <!ENTITY RFC5077 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5077.xml'>
 <!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
]>

<?rfc toc="yes" symrefs="yes"?>

<rfc category="std" ipr="trust200902" docName="draft-agl-tls-nextprotoneg-00">
  <front>
    <title abbrev="TLS Next Protocol Negotiation">Transport Layer Security (TLS) Next Protocol Negotiation Extension</title>
    <author initials="A." surname="Langley" fullname="Adam Langley">
      <organization>Google Inc</organization>
      <address>
        <email>agl@google.com</email>
      </address>
    </author>
    <date month="January" year="2010" />
    <area>Security</area>
    <abstract>
      <t>
        This document describes a Transport Layer Security (TLS) extension for
        application layer protocol negotiation. This allows the application
        layer to negotiate which protocol should be performed over the secure
        connection in a manner which avoids additional round trips and which is
        independent of the application layer protocols.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
        The use of <xref target="RFC5246">TLS</xref> over <xref target="RFC0793">TCP</xref>
        unavoidably adds at least a round trip to the time taken to establish a connection. By
        allowing the application layer to perform negotiation during that round trip one gains
        several advantages:
      </t>

      <t>
        Firstly, for various reasons, different application layer protocols are increasingly being
        carried over TLS using a small set of TCP port numbers, most often port 443. Rather than
        forcing systems administrators to use different IP addresses for every service, negotiation
        allows multiple services to exist with the same IP address.
      </t>

      <t>
        Secondly, newer versions of the same application layer protocol can perform discovery and
        avoid additional round trips after the TLS handshake.
      </t>

      <t>
        To illustrate the second point, consider <xref target="RFC2616">HTTP</xref> pipelining.
        Although it has seen little adoption because of interference from middleware, there is no
        reason not to use it over TLS where the transport is known to be pristine.
      </t>

      <t>
        However, even over TLS, the client cannot make pipelined requests until the first reply
        indicates that the remote peer supports the feature.  If the client could negotiate HTTP/1.1
        support before the first request, it could start sending pipelined requests immediately.
      </t>
    </section>

    <section title="Requirements Notation">
      <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>
    </section>

    <section title="Next Protocol Negotiation Extension">
      <t>
        A new extension type (<spanx
          style="verb">next_protocol_negotiation(TBD)</spanx>) is defined and
        MAY be included by the client in its <spanx style="verb">ClientHello</spanx> message. If,
        and only if, the server sees this extension in the <spanx style="verb">ClientHello</spanx>,
        it MAY choose to include the extension in its <spanx style="verb">ServerHello</spanx>.
      </t>

      <figure>
        <artwork>
enum {
  next_protocol_negotiation(TBD), (65535)
} ExtensionType;
        </artwork>
      </figure>

      <t>
        A new handshake message type (<spanx style="verb">next_protocol(TBD)</spanx>) is
        defined.  If, and only if, the server included a <spanx
          style="verb">next_protocol_negotiation</spanx> extension in its ServerHello message, the
        client MUST send a <spanx style="verb">NextProtocol</spanx> message after its
        <spanx style="verb">ChangeCipherSpec</spanx> and before its <spanx
          style="verb">Finished</spanx> message.  </t>

      <figure>
        <artwork>
struct {
  opaque selected_protocol<0..255>;
  opaque padding<0..255>;
} NextProtocol;
        </artwork>
      </figure>

      <t>The <spanx style="verb">extension_data</spanx> field of a <spanx style="verb">next_protocol_negotiation</spanx> in a <spanx style="verb">ClientHello</spanx> MUST be empty.</t>

      <t>
        The <spanx style="verb">extension_data</spanx> field in a <spanx
          style="verb">ServerHello</spanx> and the <spanx style="verb">NextProtocol</spanx> message
        contain opaque bytes to be used by the application layer to negotiate the
        application layer protocol. The format of this data is not specified in this draft.
      </t>

      <t>
        Unlike many other TLS extensions, this extension does not establish properties of the
        session, only of the connection. When session resumption or <xref target="RFC5077">session
        tickets</xref> are used, the previous contents of this extension are irrelevant and only the
        values in the new handshake messages are considered.
      </t>

      <t>
        For the same reasons, after a handshake has been performed for a given connection,
        renegotiations on the same connection MUST NOT include the <spanx
          style="verb">next_protocol_negotiation</spanx> extension.
      </t>
    </section>

    <!--<section title="Discussion">
      <t>
        It is expected that the server will include a list of supported protocols in the <spanx
          style="verb">ServerHello</spanx> message and that the client will select one and include
        that in the <spanx style="verb">NextProtocol</spanx> message.
      </t>

      <t>
        As a useful default, the client can choose the first protocol in
        server's list that the client also supports. If no such protocol
        exists, the client chooses the first protocol in its list.
      </t>

      <t>
        If the client were to include a list of supported protocols in the <spanx
          style="verb">ClientHello</spanx> message and the server were to select one, the additional
        handshake message could be avoided. However, as the client would be announcing its
        intentions in the clear, such a design invites interference from the network. By using an
        encrypted handshake message, the network is unable to discriminate between TLS connections
        on the grounds of application layer protocol.
      </t>
    </section> -->

    <section title="Security considerations">
      <t>
        The server's list of supported protocols is still advertised in the clear with this extension.
        This may be undesirable for certain protocols (such as <xref target="tor">Tor</xref>) where
        one could imagine that hostile networks would terminate any TLS connection with a server
        that advertised such a capability. In this case, clients may wish to opportunistically
        select a protocol that wasn't advertised by the server. However, the workings of such a
        scheme are outside the scope of this document.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        This document requires IANA to update its registry of TLS extensions
        to assign an entry, referred herein as <spanx style="verb">next_protocol_negotiation</spanx>.
      </t>
      <t>
        This document also requires IANA to update its registry of TLS handshake types
        to assign an entry, referred herein as <spanx style="verb">next_protocol</spanx>.
      </t>
    </section>
    <section title="Acknowledgements">
      <t>
        This document benefited specifically from discussions with Wan-Teh
        Chang and Nagendra Modadugu.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">

      &RFC2119;
      &RFC5246;

    </references>
    <references title="Informative References">

      &RFC0793;
      &RFC2616;
      &RFC5077;

      <reference anchor="tor">
        <front>
          <title>Tor: The Second-Generation Onion Router</title>
          <author initials="R." surname="Dingledine"> <organization/> </author>
          <author initials="N." surname="Matthewson"> <organization/> </author>
          <author initials="P." surname="Syverson"> <organization/> </author>
          <date month="August" year="2004"/>
        </front>
      </reference>
    </references>

    <section title="Changes">
      <t>To be removed by RFC Editor before publication</t>
    </section>
  </back>
</rfc>