client
Click on the red underlined text to get to the source
... generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms.
...
...
- Allow TLS clients to provide to the TLS server the name of the
server they are contacting. This functionality is desirable in
...
...
- Allow TLS clients and servers to negotiate the maximum fragment
length to be sent. This functionality is desirable as a result of
...
... 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 and servers to negotiate the use of client
certificate URLs. This functionality is desirable in order to
conserve memory on constrained clients.
...
... 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 ...
... multiple handshake failures involving TLS clients that are only
able to store a small number of CA root ...
...
- Allow TLS clients and servers to negotiate the use of truncated
MACs. This functionality is desirable in order to conserve
...
...
- Allow TLS clients and servers to negotiate that the server sends
the client certificate status information (e.g., an Online
...
... TLS clients and servers to negotiate that the server sends
the client certificate status information (e.g., an Online
Certificate Status Protocol (OCSP ...
...
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 ...
... 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
...
... 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 ...
... - 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 ...
... 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 ...
... 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 ...
... 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 RFC3546prop(-> 4366prop) ...
...
The remainder of this document is organized as follows. Section 2
describes general extension mechanisms for the client hello and
server hello handshake ...
...
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 ...
... MAILINGLIST].
Section 2.1 specifies the extended client hello message format,
Section 2.2 specifies the extended server hello ...
... Section 2.3 describes the actual extension format used with the
extended client and server hellos.
...
... Extended Client Hello ...
...
Clients MAY request extended functionality from servers by sending
the extended client hello message format ...
... Clients MAY request extended functionality from servers by sending
the extended client hello message format in place of the client hello
...
... the extended client hello message format in place of the client hello
message format. The extended client hello ...
... compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
...
... } ClientHello;
Here the new "client_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3.
...
... 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 ...
... 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 ...
... 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 ...
... 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
...
... 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
...
... 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 ...
... 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 ...
...
The extension format for extended client hellos and extended server
hellos is:
...
... server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac ...
... 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
...
... 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 ...
... 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
...
... 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
...
... (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 ...
... 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
...
...
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 ...
... 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
...
... 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
...
...
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 ...
... select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate ...
... case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate ...
... 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 ...
... session is initiated. When a client includes
one or more of the defined extension types in an extended client
hello while requesting session resumption:
...
...
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 ...
... 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
...
... 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 ...
...
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
...
... 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
...
...
In order to provide the server name, clients MAY include an extension
of type "server_name" in the (extended) client hello ...
... 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:
...
... "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 ...
... 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
...
... addresses are not permitted in "HostName".
It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello ...
... clients include an extension of type
"server_name" in the client hello whenever they locate a server by a
supported name type.
...
... 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
...
... 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
...
... empty.
If the server understood the client hello extension but does not
recognize the server name, it SHOULD send an "unrecognized_name"
...
... established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer ...
... 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 ...
...
In order to negotiate smaller maximum fragment lengths, clients MAY
include an extension of type "max_fragment_length" in the (extended)
...
... include an extension of type "max_fragment_length" in the (extended)
client hello. The "extension_data" field of this extension SHALL
contain:
...
... 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
...
... handshake with an "illegal_parameter" alert. Similarly, if a client
receives a maximum fragment length negotiation response that differs
...
... 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
...
... Client Certificate URLs ...
...
Without this extension, TLS specifies that when client authentication
is performed, client certificates ...
... TLS specifies that when client authentication
is performed, client certificates are sent by clients to servers
...
... TLS handshake. It may be desirable for constrained
clients to send certificate URLs in place of certificates, so that
...
...
In order to negotiate sending certificate URLs to a server, clients
MAY include an extension of type "client_certificate ...
... certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the
(extended) client hello ...
... client_certificate_url" in the
(extended) client hello. The "extension_data" field of this
extension SHALL be empty.
...
... extension SHALL be empty.
(Note that it is necessary to negotiate use of client certificate
URLs in order to avoid "breaking" existing TLS servers.)
...
... TLS servers.)
Servers that receive an extended client hello containing a
"client_certificate ...
... Servers that receive an extended client hello containing a
"client_certificate_url" extension MAY indicate that they are willing
to accept certificate URLs ...
... to accept certificate URLs by including an extension of type
"client_certificate_url" in the (extended) server hello. The
...
...
After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client ...
... client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
...
... "client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message:
...
... The hash corresponding to each URL at the client's discretion either
is not present or is the SHA-1 hash of the certificate ...
... Servers receiving "CertificateURL" SHALL attempt to retrieve the
client's certificate chain from the URLs and then process the
...
... alert.
Note that clients may choose to send either "Certificate" or
"CertificateURL" after successfully negotiating the option to send
...
... certificate URLs. The option to send a certificate is included to
provide flexibility to clients possessing multiple certificates.
...
... In order to indicate which CA root keys they possess, clients MAY
include an extension of type "trusted_ca_keys" in the (extended)
client hello ...
... clients MAY
include an extension of type "trusted_ca_keys" in the (extended)
client hello. The "extension_data" field of this extension SHALL
contain "TrustedAuthorities" where:
...
... CA root key identifiers
that the client possesses. Each CA root key is identified via
either:
...
... The option to include no CA root keys is included to allow the client
to indicate possession of some pre-defined set of CA root ...
... root keys.
Servers that receive a client hello containing the "trusted_ca_keys"
extension MAY use the information contained in the extension to guide
their selection of an appropriate certificate chain ...
... their selection of an appropriate certificate chain to return to the
client. In this event, the server SHALL include an extension of type
"trusted_ca_keys" in the (extended) server hello. The
...
... In order to negotiate the use of 80-bit truncated HMAC, clients MAY
include an extension of type "truncated_hmac" in the extended client
hello ...
... clients MAY
include an extension of type "truncated_hmac" in the extended client
hello. The "extension_data" field of this extension SHALL be empty.
Servers that receive an extended hello containing a "truncated_hmac ...
... handshake, and the negotiated cipher suite uses HMAC, both the client
and the server pass this fact to the TLS record layer along with the
...
... security parameters. Subsequently during the
session, clients and servers MUST use truncated HMACs, calculated as
specified in [HMAC ...
... In order to indicate their desire to receive certificate status
information, clients MAY include an extension of type
"status_request" in the (extended) client hello ...
... clients MAY include an extension of type
"status_request" in the (extended) client hello. The
"extension_data" field of this extension SHALL contain
"CertificateStatusRequest" where:
...
... OCSP
responders that the client trusts. A zero-length "responder_id_list"
sequence has the special meaning that the responders ...
... encapsulated as another OCTET
STRING (note that implementations based on an existing OCSP client
will need to be checked for conformance to this requirement).
...
... requirement).
Servers that receive a client hello containing the "status_request"
extension MAY return a suitable certificate status ...
... extension MAY return a suitable certificate status response to the
client along with their certificate. If OCSP is requested, they
...
... message, even if it receives a "status_request" extension in the
client hello message.
Note in addition that servers MUST NOT send the "CertificateStatus"
...
... Note in addition that servers MUST NOT send the "CertificateStatus"
message unless it received a "status_request" extension in the client
hello message.
Clients ...
... The following new error alerts are defined. To avoid "breaking"
existing clients and servers, these alerts MUST NOT be sent unless
the sending party has received an extended hello message ...
...
- "unsupported_extension": this alert is sent by clients that
receive an extended server hello containing an extension that they
...
... receive an extended server hello containing an extension that they
did not put in the corresponding client hello (see Section 2.3).
This message is always fatal.
...
... unable to retrieve a certificate chain from the URL supplied by
the client (see Section 3.3). This message MAY be fatal; for
example, if client authentication is required by the server ...
... URL supplied by
the client (see Section 3.3). This message MAY be fatal; for
example, if client authentication is required by the server for
the handshake ...
... - "bad_certificate_status_response": this alert is sent by clients
that receive an invalid certificate status response (see Section
...
...
- All of the extensions defined in this document follow the
convention that for each extension that a client requests and that
the server understands, the server replies with an extension of
...
... There are two major issues with this extension.
The first major issue is whether or not clients should include
certificate hashes ...
... When client authentication is used *without* the
client_certificate_url extension, the client certificate chain is
...
... client_certificate_url extension, the client certificate chain is
covered by the Finished message hashes ...
... certificate chain retrieved
by the server is as the client intended.
On the other hand, omitting certificate ...
... certificate hashes enables functionality
that is desirable in some circumstances; for example, clients can be
issued daily certificates that are stored at a fixed URL ...
... certificates that are stored at a fixed URL and need not
be provided to the client. Clients that choose to omit certificate
...
... attacker obtains a valid certificate on the client's key that is
different from the certificate the client ...
... client's key that is
different from the certificate the client intended to provide.
Although TLS uses both MD5 ...
... image resistance.
The second major issue is that support for client_certificate_url
involves the server's acting as a client ...
... client_certificate_url
involves the server's acting as a client in another URL protocol.
The server therefore becomes subject ...
... The server therefore becomes subject to many of the same security
concerns that clients of the URL scheme are subject to, with the
...
... URL scheme are subject to, with the
added concern that the client can attempt to prompt the server to
connect to some (possibly weird-looking) URL.
...
...
As a result of this issue, it is RECOMMENDED that the
client_certificate_url extension should have to be specifically
enabled by a server administrator ...
... It is possible that which CA root keys a client possesses could be
regarded as confidential information. As a result, the CA root key
...
... security
problem were found with truncated HMAC in the future, if either the
client or the server for a given session were updated to take the
problem into account, it would be able to veto use of this extension.
...
... an attacker's server using a compromised key could (and probably
would) pretend not to support the extension. In this case, a client
that requires OCSP validation ...