Request for Comments: 4366 BCI
Obsoletes: 3546 M. Nystrom
Updates: 4346 RSA Security
Category: Standards Track D. Hopwood
Independent Consultant
J. Mikkelsen
Transactionware
T. Wright
Vodafone
April 2006
Transport Layer Security (TLS) Extensions
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes extensions that may be used to add
functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The
extensions are backwards compatible: communication is possible
between TLS clients that support the extensions and TLS servers that
do not support the extensions, and vice versa.
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
2. General Extension Mechanisms ....................................5
2.1. Extended Client Hello ......................................5
2.2. Extended Server Hello ......................................6
2.3. Hello Extensions ...........................................6
2.4. Extensions to the Handshake Protocol .......................8
3. Specific Extensions .............................................8
3.1. Server Name Indication ....................................9
3.2. Maximum Fragment Length Negotiation ......................11
3.3. Client Certificate URLs ..................................12
3.4. Trusted CA Indication ....................................15
3.5. Truncated HMAC ............................................16
3.6. Certificate Status Request ................................17
4. Error Alerts ...................................................19
5. Procedure for Defining New Extensions ..........................20
6. Security Considerations ........................................21
6.1. Security of server_name ...................................22
6.2. Security of max_fragment_length ...........................22
6.3. Security of client_certificate_url ........................22
6.4. Security of trusted_ca_keys ...............................24
6.5. Security of truncated_hmac ................................24
6.6. Security of status_request ................................25
7. Internationalization Considerations ............................25
8. IANA Considerations ............................................25
9. Acknowledgements ...............................................27
10. Normative References ..........................................27
11. Informative References ........................................28
1. Introduction
This document describes extensions that may be used to add
functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms.
TLS is now used in an increasing variety of operational environments,
many of which were not envisioned when the original design criteria
for TLS were determined. The extensions introduced in this document
are designed to enable TLS to operate as effectively as possible in
new environments such as wireless networks.
Wireless environments often suffer from a number of constraints not
commonly present in wired environments. These constraints may
include bandwidth limitations, computational power limitations,
memory limitations, and battery life limitations.
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.
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 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
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) [OCSP] 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 save bandwidth.
In order to support the extensions above, general extension
mechanisms for the client hello message and the server hello message
are introduced.
The extensions described in this document may be used by TLS clients
and servers. 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. The
document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis].
Backwards compatibility is primarily achieved via two considerations:
- Clients typically request the use of extensions via the extended
client hello message described in Section 2.1. TLS requires
servers to accept extended client hello messages, even if the
server does not "understand" the extension.
- For the specific extensions described here, no mandatory server
response is required when clients request extended functionality.
Essentially, backwards compatibility is achieved based on the TLS
requirement that servers that are not "extensions-aware" ignore data
added to client hellos that they do not recognize; for example, see
Section 7.4.1.2 of [TLS].
Note, however, that although backwards compatibility is supported,
some constrained clients may be forced to reject communications with
servers that do not support the extensions as a result of the limited
capabilities of such clients.
This document is a revision of the RFC3546 [RFC3546]. The only major
change concerns the definition of new extensions. New extensions can
now be defined via the IETF Consensus Process (rather than requiring
a standards track RFC). In addition, a few minor clarifications and
editorial improvements were made.
The remainder of this document is organized as follows. Section 2
describes general extension mechanisms for the client hello and
server hello handshake messages. Section 3 describes specific
extensions to TLS. Section 4 describes new error alerts for use with
the TLS extensions. The final sections of the document address IPR,
security considerations, registration of the application/pkix-pkipath
MIME type, acknowledgements, and references.
1.1. 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 BCP 14, RFC 2119
[KEYWORDS].
2. General Extension Mechanisms
This section presents general extension mechanisms for the TLS
handshake client hello and server hello messages.
These general extension mechanisms are necessary in order to enable
clients and servers to negotiate whether to use specific extensions,
and how to use specific extensions. The extension formats described
are based on [MAILINGLIST].
Section 2.1 specifies the extended client hello message format,
Section 2.2 specifies the extended server hello message format, and
Section 2.3 describes the actual extension format used with the
extended client and server hellos.
2.1. Extended Client Hello
Clients MAY request extended functionality from servers by sending
the extended client hello message format in place of the client hello
message format. The extended client hello message format is:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
Here the new "client_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3.
In the event that a client requests additional functionality using
the extended client hello, and this functionality is not supplied by
the server, the client MAY abort the handshake.
Note that [TLS], Section 7.4.1.2, allows additional information to be
added to the client hello message. Thus, the use of the extended
client hello defined above should not "break" existing TLS servers.
A server that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello
format and (as for all other messages) MUST check that the amount of
data in the message precisely matches one of these formats. If it
does not, then it MUST send a fatal "decode_error" alert. This
overrides the "Forward compatibility note" in [TLS].
2.2. Extended Server Hello
The extended server hello message format MAY be sent in place of the
server hello message when the client has requested extended
functionality via the extended client hello message specified in
Section 2.1. The extended server hello message format is:
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>;
} ServerHello;
Here the new "server_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3.
Note that the extended server hello message is only sent in response
to an extended client hello message. This prevents the possibility
that the extended server hello message could "break" existing TLS
clients.
2.3. Hello Extensions
The extension format for extended client hellos and extended server
hellos is:
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
Here:
- "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular
extension type.
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;
The list of defined extension types is maintained by the IANA. The
current list can be found at:
http://www.iana.org/assignments/tls-extensiontype-values. See
Sections 5 and 8 for more information on how new values are added.
Note that for all extension types (including those defined in the
future), the extension type MUST NOT appear in the extended server
hello unless the same extension type appeared in the corresponding
client hello. Thus clients MUST abort the handshake if they receive
an extension type in the extended server hello that they did not
request in the associated (extended) client hello.
Nonetheless, "server-oriented" extensions may be provided in the
future within this framework. Such an extension (say, of type x)
would require the client to first send an extension of type x in the
(extended) client hello with empty extension_data to indicate that it
supports the extension type. In this case, the client is offering
the capability to understand the extension type, and the server is
taking the client up on its offer.
Also note that when multiple extensions of different types are
present in the extended client hello or the extended server hello,
the extensions may appear in any order. There MUST NOT be more than
one extension of the same type.
Finally, note that an extended client hello may be sent both when
starting a new session and when requesting session resumption.
Indeed, a client that requests resumption of a session does not in
general know whether the server will accept this request, and
therefore it SHOULD send an extended client hello if it would
normally do so for a new session. In general the specification of
each extension type must include a discussion of the effect of the
extension both during new sessions and during resumed sessions.
2.4. Extensions to the Handshake Protocol
This document suggests the use of two new handshake messages,
"CertificateURL" and "CertificateStatus". These messages are
described in Section 3.3 and Section 3.6, respectively. The new
handshake message structure therefore becomes:
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;
} body;
} Handshake;
3. Specific Extensions
This section describes the specific TLS extensions specified in this
document.
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 the extensions defined in this section are
relevant only when a session is initiated. When a client includes
one or more of the defined extension types in an extended client
hello while requesting session resumption:
- If the resumption request is denied, the use of the extensions is
negotiated as normal.
- 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 is applied to the resumed session.
Section 3.1 describes the extension of TLS to allow a client to
indicate which server it is contacting. Section 3.2 describes the
extension that provides maximum fragment length negotiation. Section
3.3 describes the extension that allows client certificate URLs.
Section 3.4 describes the extension that allows a client to indicate
which CA root keys it possesses. Section 3.5 describes the extension
that allows the use of truncated HMAC. Section 3.6 describes the
extension that supports integration of certificate status information
messages into TLS handshakes.
3.1. Server Name Indication
TLS does not provide a mechanism for a client to tell a server the
name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to
servers that host multiple ’virtual’ servers at a single underlying
network address.
In order to provide the server name, clients MAY include an extension
of type "server_name" in the (extended) client hello. The
"extension_data" field of this extension SHALL contain
"ServerNameList" where:
struct {
NameType name_type;
select (name_type) {
case host_name: HostName;
} name;
} ServerName;
enum {
host_name(0), (255)
} NameType;
opaque HostName<1..2^16-1>;
struct {
ServerName server_name_list<1..2^16-1>
} ServerNameList;
Currently, the only server names supported are DNS hostnames;
however, this does not imply any dependency of TLS on DNS, and other
name types may be added in the future (by an RFC that updates this
document). TLS MAY treat provided server names as opaque data and
pass the names and types to the application.
"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte
string using UTF-8 encoding [UTF8], without a trailing dot.
If the hostname labels contain only US-ASCII characters, then the
client MUST ensure that labels are separated only by the byte 0x2E,
representing the dot character U+002E (requirement 1 in Section 3.1
of [IDNA] notwithstanding). If the server needs to match the
HostName against names that contain non-US-ASCII characters, it MUST
perform the conversion operation described in Section 4 of [IDNA],
treating the HostName as a "query string" (i.e., the AllowUnassigned
flag MUST be set). Note that IDNA allows labels to be separated by
any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
therefore, servers MUST accept any of these characters as a label
separator. If the server only needs to match the HostName against
names containing exclusively ASCII characters, it MUST compare ASCII
names case-insensitively.
Literal IPv4 and IPv6 addresses are not permitted in "HostName".
It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
A server that receives a client hello containing the "server_name"
extension MAY use the information contained in the extension to guide
its selection of an appropriate certificate to return to the client,
and/or other aspects of security policy. In this event, the server
SHALL include an extension of type "server_name" in the (extended)
server hello. The "extension_data" field of this extension SHALL be
empty.
If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name"
alert (which MAY be fatal).
If an application negotiates a server name using an application
protocol and then upgrades to TLS, and if a server_name extension is
sent, then the extension SHOULD contain the same name that was
negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer.
3.2. Maximum Fragment Length Negotiation
Without this extension, TLS specifies a fixed maximum plaintext
fragment length of 2^14 bytes. It may be desirable for constrained
clients to negotiate a smaller maximum fragment length due to memory
limitations or bandwidth limitations.
In order to negotiate smaller maximum fragment lengths, clients MAY
include an extension of type "max_fragment_length" in the (extended)
client hello. The "extension_data" field of this extension SHALL
contain:
enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;
whose value is the desired maximum fragment length. The allowed
values for this field are: 2^9, 2^10, 2^11, and 2^12.
Servers that receive an extended client hello containing a
"max_fragment_length" extension MAY accept the requested maximum
fragment length by including an extension of type
"max_fragment_length" in the (extended) server hello. The
"extension_data" field of this extension SHALL contain a
"MaxFragmentLength" whose value is the same as the requested maximum
fragment length.
If a server receives a maximum fragment length negotiation request
for a value other than the allowed values, it MUST abort the
handshake with an "illegal_parameter" alert. Similarly, if a client
receives a maximum fragment length negotiation response that differs
from the length it requested, it MUST also abort the handshake with
an "illegal_parameter" alert.
Once a maximum fragment length other than 2^14 has been successfully
negotiated, the client and server MUST immediately begin fragmenting
messages (including handshake messages), to ensure that no fragment
larger than the negotiated length is sent. Note that TLS already
requires clients and servers to support fragmentation of handshake
messages.
The negotiated length applies for the duration of the session
including session resumptions.
The negotiated length limits the input that the record layer may
process without fragmentation (that is, the maximum value of
TLSPlaintext.length; see [TLS], Section 6.2.1). Note that the output
of the record layer may be larger. For example, if the negotiated