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.
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].
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.
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;