length is 2^9=512, then for currently defined cipher suites (those
defined in [TLS], [KERB], and [AESSUITES]), and when null compression
is used, the record layer output can be at most 793 bytes: 5 bytes of
headers, 512 bytes of application data, 256 bytes of padding, and 20
bytes of MAC. This means that in this event a TLS record layer peer
receiving a TLS record layer message larger than 793 bytes may
discard the message and send a "record_overflow" alert, without
decrypting the message.
3.3. Client Certificate URLs
Without this extension, TLS specifies that when client authentication
is performed, client certificates are sent by clients to servers
during the TLS handshake. It may be desirable for constrained
clients to send certificate URLs in place of certificates, so that
they do not need to store their certificates and can therefore save
memory.
In order to negotiate sending certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the
(extended) client hello. The "extension_data" field of this
extension SHALL be empty.
(Note that it is necessary to negotiate use of client certificate
URLs in order to avoid "breaking" existing TLS servers.)
Servers that receive an extended client hello containing a
"client_certificate_url" extension MAY indicate that they are willing
to accept certificate URLs by including an extension of type
"client_certificate_url" in the (extended) server hello. The
"extension_data" field of this extension SHALL be empty.
After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message:
enum {
individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
false(0), true(1)
} Boolean;
struct {
CertChainType type;
URLAndOptionalHash url_and_hash_list<1..2^16-1>;
} CertificateURL;
struct {
opaque url<1..2^16-1>;
Boolean hash_present;
select (hash_present) {
case false: struct {};
case true: SHA1Hash;
} hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];
Here "url_and_hash_list" contains a sequence of URLs and optional
hashes.
When X.509 certificates are used, there are two possibilities:
- If CertificateURL.type is "individual_certs", each URL refers to a
single DER-encoded X.509v3 certificate, with the URL for the
client’s certificate first.
- If CertificateURL.type is "pkipath", the list contains a single
URL referring to a DER-encoded certificate chain, using the type
PkiPath described in Section 8.
When any other certificate format is used, the specification that
describes use of that format in TLS should define the encoding format
of certificates or certificate chains, and any constraint on their
ordering.
The hash corresponding to each URL at the client’s discretion either
is not present or is the SHA-1 hash of the certificate or certificate
chain (in the case of X.509 certificates, the DER-encoded certificate
or the DER-encoded PkiPath).
Note that when a list of URLs for X.509 certificates is used, the
ordering of URLs is the same as that used in the TLS Certificate
message (see [TLS], Section 7.4.2), but opposite to the order in
which certificates are encoded in PkiPath. In either case, the
self-signed root certificate MAY be omitted from the chain, under the
assumption that the server must already possess it in order to
validate it.
Servers receiving "CertificateURL" SHALL attempt to retrieve the
client’s certificate chain from the URLs and then process the
certificate chain as usual. A cached copy of the content of any URL
in the chain MAY be used, provided that a SHA-1 hash is present for
that URL and it matches the hash of the cached copy.
Servers that support this extension MUST support the http: URL scheme
for certificate URLs, and MAY support other schemes. Use of other
schemes than "http", "https", or "ftp" may create unexpected
problems.
If the protocol used is HTTP, then the HTTP server can be configured
to use the Cache-Control and Expires directives described in [HTTP]
to specify whether and for how long certificates or certificate
chains should be cached.
The TLS server is not required to follow HTTP redirects when
retrieving the certificates or certificate chain. The URLs used in
this extension SHOULD therefore be chosen not to depend on such
redirects.
If the protocol used to retrieve certificates or certificate chains
returns a MIME-formatted response (as HTTP does), then the following
MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
when a chain of X.509v3 certificates is returned, the Content-Type is
"application/pkix-pkipath" (see Section 8).
If a SHA-1 hash is present for an URL, then the server MUST check
that the SHA-1 hash of the contents of the object retrieved from that
URL (after decoding any MIME Content-Transfer-Encoding) matches the
given hash. If any retrieved object does not have the correct SHA-1
hash, the server MUST abort the handshake with a
"bad_certificate_hash_value" 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.
If a server encounters an unreasonable delay in obtaining
certificates in a given CertificateURL, it SHOULD time out and signal
a "certificate_unobtainable" error alert.
3.4. Trusted CA Indication
Constrained clients that, due to memory limitations, possess only a
small number of CA root keys may wish to indicate to servers which
root keys they possess, in order to avoid repeated handshake
failures.
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. The "extension_data" field of this extension SHALL
contain "TrustedAuthorities" where:
struct {
TrustedAuthority trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;
struct {
IdentifierType identifier_type;
select (identifier_type) {
case pre_agreed: struct {};
case key_sha1_hash: SHA1Hash;
case x509_name: DistinguishedName;
case cert_sha1_hash: SHA1Hash;
} identifier;
} TrustedAuthority;
enum {
pre_agreed(0), key_sha1_hash(1), x509_name(2),
cert_sha1_hash(3), (255)
} IdentifierType;
opaque DistinguishedName<1..2^16-1>;
Here "TrustedAuthorities" provides a list of CA root key identifiers
that the client possesses. Each CA root key is identified via
either:
- "pre_agreed": no CA root key identity supplied.
- "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
Digital Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA) keys, this is the hash of the
"subjectPublicKey" value. For RSA keys, the hash is of the big-
endian byte string representation of the modulus without any
initial 0-valued bytes. (This copies the key hash formats
deployed in other environments.)
- "x509_name": contains the DER-encoded X.509 DistinguishedName of
the CA.
- "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
Certificate containing the CA root key.
Note that clients may include none, some, or all of the CA root keys
they possess in this extension.
Note also that it is possible that a key hash or a Distinguished Name
alone may not uniquely identify a certificate issuer (for example, if
a particular CA has multiple key pairs). However, here we assume
this is the case following the use of Distinguished Names to identify
certificate issuers in TLS.
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 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 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
"extension_data" field of this extension SHALL be empty.
3.5. Truncated HMAC
Currently defined TLS cipher suites use the MAC construction HMAC
with either MD5 or SHA-1 [HMAC] to authenticate record layer
communications. In TLS, the entire output of the hash function is
used as the MAC tag. However, it may be desirable in constrained
environments to save bandwidth by truncating the output of the hash
function to 80 bits when forming MAC tags.
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. The "extension_data" field of this extension SHALL be empty.
Servers that receive an extended hello containing a "truncated_hmac"
extension MAY agree to use a truncated HMAC by including an extension
of type "truncated_hmac", with empty "extension_data", in the
extended server hello.
Note that if new cipher suites are added that do not use HMAC, and
the session negotiates one of these cipher suites, this extension
will have no effect. It is strongly recommended that any new cipher
suites using other MACs consider the MAC size an integral part of the
cipher suite definition, taking into account both security and
bandwidth considerations.
If HMAC truncation has been successfully negotiated during a TLS
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
other negotiated security parameters. Subsequently during the
session, clients and servers MUST use truncated HMACs, calculated as
specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and
only the first 10 bytes of the HMAC output are transmitted and
checked. Note that this extension does not affect the calculation of
the pseudo-random function (PRF) as part of handshaking or key
derivation.
The negotiated HMAC truncation size applies for the duration of the
session including session resumptions.
3.6. Certificate Status Request
Constrained clients may wish to use a certificate-status protocol
such as OCSP [OCSP] to check the validity of server certificates, in
order to avoid transmission of CRLs and therefore save bandwidth on
constrained networks. This extension allows for such information to
be sent in the TLS handshake, saving roundtrips and resources.
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. The
"extension_data" field of this extension SHALL contain
"CertificateStatusRequest" where:
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPStatusRequest;
} request;
} CertificateStatusRequest;
enum { ocsp(1), (255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
responders that the client trusts. A zero-length "responder_id_list"
sequence has the special meaning that the responders are implicitly
known to the server, e.g., by prior arrangement. "Extensions" is a
DER encoding of OCSP request extensions.
Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-
length "request_extensions" value means that there are no extensions
(as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
the "Extensions" type).
In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
unclear about its encoding; for clarification, the nonce MUST be a
DER-encoded OCTET STRING, which is encapsulated as another OCTET
STRING (note that implementations based on an existing OCSP client
will need to be checked for conformance to this requirement).
Servers that receive a client hello containing the "status_request"
extension MAY return a suitable certificate status response to the
client along with their certificate. If OCSP is requested, they
SHOULD use the information contained in the extension when selecting
an OCSP responder and SHOULD include request_extensions in the OCSP
request.
Servers return a certificate response along with their certificate by
sending a "CertificateStatus" message immediately after the
"Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). If a server returns a
"CertificateStatus" message, then the server MUST have included an
extension of type "status_request" with empty "extension_data" in the
extended server hello.
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
An "ocsp_response" contains a complete, DER-encoded OCSP response
(using the ASN.1 type OCSPResponse defined in [OCSP]). Note that
only one OCSP response may be sent.
The "CertificateStatus" message is conveyed using the handshake
message type "certificate_status".
Note that a server MAY also choose not to send a "CertificateStatus"
message, even if it receives a "status_request" extension in the
client hello message.
Note in addition that servers MUST NOT send the "CertificateStatus"
message unless it received a "status_request" extension in the client
hello message.
Clients requesting an OCSP response and receiving an OCSP response in
a "CertificateStatus" message MUST check the OCSP response and abort
the handshake if the response is not satisfactory.
4. Error Alerts
This section defines new error alerts for use with the TLS extensions
defined in this document.
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 from the
party they are communicating with.
- "unsupported_extension": this alert is sent by clients that
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.
- "unrecognized_name": this alert is sent by servers that receive a
server_name extension request, but do not recognize the server
name. This message MAY be fatal.
- "certificate_unobtainable": this alert is sent by servers who are
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 for
the handshake to continue and the server is unable to retrieve the
certificate chain, it may send a fatal alert.
- "bad_certificate_status_response": this alert is sent by clients
that receive an invalid certificate status response (see Section
3.6). This message is always fatal.
- "bad_certificate_hash_value": this alert is sent by servers when a
certificate hash does not match a client-provided
certificate_hash. This message is always fatal.
These error alerts are conveyed using the following syntax:
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
/* 41 is not defined, for historical reasons */
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
certificate_unobtainable(111), /* new */
unrecognized_name(112), /* new */
bad_certificate_status_response(113), /* new */
bad_certificate_hash_value(114), /* new */
(255)
} AlertDescription;
5. Procedure for Defining New Extensions
The list of extension types, as defined in Section 2.3, is maintained
by the Internet Assigned Numbers Authority (IANA). Thus, an
application needs to be made to the IANA in order to obtain a new
extension type value. Since there are subtle (and not-so-subtle)
interactions that may occur in this protocol between new features and
existing features that may result in a significant reduction in
overall security, new values SHALL be defined only through the IETF
Consensus process specified in [IANA].
(This means that new assignments can be made only via RFCs approved
by the IESG.)
The following considerations should be taken into account when
designing new extensions:
- 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
the same type.
- Some cases where a server does not agree to an extension are error
conditions, and some simply a refusal to support a particular
feature. In general, error alerts should be used for the former,
and a field in the server extension response for the latter.
- Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be
followed regardless of whether the feature is believed to cause a
security problem.
Often the fact that the extension fields are included in the
inputs to the Finished message hashes will be sufficient, but
extreme care is needed when the extension changes the meaning of
messages sent in the handshake phase. Designers and implementors
should be aware of the fact that until the handshake has been
authenticated, active attackers can modify messages and insert,
remove, or replace extensions.
- It would be technically possible to use extensions to change major
aspects of the design of TLS; for example, the design of cipher
suite negotiation. This is not recommended; it would be more
appropriate to define a new version of TLS, particularly since the
TLS handshake algorithms have specific protection against version
rollback attacks based on the version number. The possibility of
version rollback should be a significant consideration in any
major design change.
6. Security Considerations
Security considerations for the extension mechanism in general and
for the design of new extensions are described in the previous
section. A security analysis of each of the extensions defined in
this document is given below.
In general, implementers should continue to monitor the state of the
art and address any weaknesses identified.
Additional security considerations are described in the TLS 1.0 RFC
[TLS] and the TLS 1.1 RFC [TLSbis].
6.1. Security of server_name
If a single server hosts several domains, then clearly it is
necessary for the owners of each domain to ensure that this satisfies
their security needs. Apart from this, server_name does not appear
to introduce significant security issues.
Implementations MUST ensure that a buffer overflow does not occur,
whatever the values of the length fields in server_name.
Although this document specifies an encoding for internationalized
hostnames in the server_name extension, it does not address any
security issues associated with the use of internationalized
hostnames in TLS (in particular, the consequences of "spoofed" names
that are indistinguishable from another name when displayed or
printed). It is recommended that server certificates not be issued
for internationalized hostnames unless procedures are in place to
mitigate the risk of spoofed hostnames.
6.2. Security of max_fragment_length
The maximum fragment length takes effect immediately, including for
handshake messages. However, that does not introduce any security
complications that are not already present in TLS, since TLS requires
implementations to be able to handle fragmented handshake messages.
Note that as described in Section 3.2, once a non-null cipher suite
has been activated, the effective maximum fragment length depends on
the cipher suite and compression method, as well as on the negotiated
max_fragment_length. This must be taken into account when sizing
buffers, and checking for buffer overflow.
6.3. Security of client_certificate_url
There are two major issues with this extension.
The first major issue is whether or not clients should include
certificate hashes when they send certificate URLs.
When client authentication is used *without* the
client_certificate_url extension, the client certificate chain is
covered by the Finished message hashes. The purpose of including
hashes and checking them against the retrieved certificate chain is
to ensure that the same property holds when this extension is used,
i.e., that all of the information in the certificate chain retrieved
by the server is as the client intended.
On the other hand, omitting 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 and need not
be provided to the client. Clients that choose to omit certificate
hashes should be aware of the possibility of an attack in which the
attacker obtains a valid certificate on the client’s key that is
different from the certificate the client intended to provide.
Although TLS uses both MD5 and SHA-1 hashes in several other places,
this was not believed to be necessary here. The property required of
SHA-1 is second pre-image resistance.
The second major issue is that support for client_certificate_url
involves the server’s acting as a client in another URL protocol.
The server therefore becomes subject to many of the same security
concerns that clients of 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.
In general, this issue means that an attacker might use the server to
indirectly attack another host that is vulnerable to some security
flaw. It also introduces the possibility of denial of service
attacks in which an attacker makes many connections to the server,
each of which results in the server’s attempting a connection to the