Skip to main content

1. Introduction

The Transport Layer Security (TLS) Protocol Version 1.2 is specified in [RFC5246]. That specification includes the framework for extensions to TLS, considerations in designing such extensions (see Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the allocation of new extension code points; however, it does not specify any particular extensions other than Signature Algorithms (see Section 7.4.1.4.1 of [RFC5246]).

This document provides the specifications for existing TLS extensions. It is, for the most part, the adaptation and editing of material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC 2246) and TLS 1.1 (RFC 4346).

1.1. Specific Extensions Covered​

The extensions described here focus on extending the functionality provided by the TLS protocol message formats. Other issues, such as the addition of new cipher suites, are deferred.

The extension types defined in this document are:

enum {
    server_name(0), max_fragment_length(1),
    client_certificate_url(2), trusted_ca_keys(3),
    truncated_hmac(4), status_request(5), (65535)
} ExtensionType;

Specifically, the extensions described in this document:

  • Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable in order to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address.

  • Allow TLS clients and servers to negotiate the maximum fragment length to be sent. This functionality is desirable as a result of memory constraints among some clients, and bandwidth constraints among some access networks.

  • Allow TLS clients and servers to negotiate the use of client certificate URLs. This functionality is desirable in order to conserve memory on constrained clients.

  • Allow TLS clients to indicate to TLS servers which certification authority (CA) root keys they possess. This functionality is desirable in order to prevent multiple handshake failures involving TLS clients that are only able to store a small number of CA root keys due to memory limitations.

  • Allow TLS clients and servers to negotiate the use of truncated Message Authentication Codes (MACs). This functionality is desirable in order to conserve bandwidth in constrained access networks.

  • Allow TLS clients and servers to negotiate that the server sends the client certificate status information (e.g., an Online Certificate Status Protocol (OCSP) [RFC2560] response) during a TLS handshake. This functionality is desirable in order to avoid sending a Certificate Revocation List (CRL) over a constrained access network and therefore saving bandwidth.

TLS clients and servers may use the extensions described in this document. The extensions are designed to be backwards compatible, meaning that TLS clients that support the extensions can talk to TLS servers that do not support the extensions, and vice versa.

Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages.

Note also that all extensions defined in this document are relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions as it would send if it were not attempting resumption. When a client includes one or more of the extension types defined here in an extended client hello while requesting session resumption:

  • The server_name extension MAY be used by the server to decide whether to resume a session as described in Section 3.

  • If the resumption request is denied, the extensions' use is negotiated normally.

  • If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation applies to the resumed session.

1.2. Conventions Used in This Document​

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 [RFC2119].

Last updated on