draft-ietf-tls-rfc4366-bis-08.txt   draft-ietf-tls-rfc4366-bis-09.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Stellar Switches INTERNET-DRAFT Stellar Switches
Obsoletes: 4366 Obsoletes: 4366
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: November 29, 2010 May 30, 2010 Expires: December 10, 2010 June 11, 2010
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-08.txt> <draft-ietf-tls-rfc4366-bis-09.txt>
Abstract Abstract
This document provides specifications for existing TLS extensions. It This document provides specifications for existing TLS extensions. It
is a companion document for the TLS 1.2 specification [RFC5246]. The is a companion document for the TLS 1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length, extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request. status_request.
Status of This Memo Status of This Memo
skipping to change at page 5, line 30 skipping to change at page 5, line 30
TLS clients and servers may use the extensions described in this TLS clients and servers may use the extensions described in this
document. The extensions are designed to be backwards compatible, document. The extensions are designed to be backwards compatible,
meaning that TLS clients that support the extensions can talk to TLS meaning that TLS clients that support the extensions can talk to TLS
servers that do not support the extensions, and vice versa. servers that do not support the extensions, and vice versa.
Note that any messages associated with these extensions that are sent Note that any messages associated with these extensions that are sent
during the TLS handshake MUST be included in the hash calculations during the TLS handshake MUST be included in the hash calculations
involved in "Finished" messages. involved in "Finished" messages.
Note also that all the extensions defined in this section are Note also that all the extensions defined in this document are
relevant only when a session is initiated. A client that requests relevant only when a session is initiated. A client that requests
session resumption does not in general know whether the server will session resumption does not in general know whether the server will
accept this request, and therefore it SHOULD send the same extensions accept this request, and therefore it SHOULD send the same extensions
as it would send if it were not attempting resumption. When a client as it would send if it were not attempting resumption. When a client
includes one or more of the defined extension types in an extended includes one or more of the defined extension types in an extended
client hello while requesting session resumption: client hello while requesting session resumption:
- The server name indication extension MAY be used by the server - The server name indication extension MAY be used by the server
when deciding whether or not to resume a session as described when deciding whether or not to resume a session as described
in section 3. in section 3.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
server MUST ignore the extensions and send a server hello server MUST ignore the extensions and send a server hello
containing none of the extension types. In this case, the containing none of the extension types. In this case, the
functionality of these extensions negotiated during the functionality of these extensions negotiated during the
original session initiation is applied to the resumed session. original session initiation is applied to the resumed session.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
1.2 Conventions Used in This Document 1.2 Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119. "OPTIONAL" in this document are to be interpreted as described in RFC
2119.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
2. Extensions to the Handshake Protocol 2. Extensions to the Handshake Protocol
This document specifies the use of two new handshake messages, This document specifies the use of two new handshake messages,
"CertificateURL" and "CertificateStatus". These messages are "CertificateURL" and "CertificateStatus". These messages are
described in Section 5 and Section 8, respectively. The new described in Section 5 and Section 8, respectively. The new
handshake message structure therefore becomes: handshake message structure therefore becomes:
skipping to change at page 8, line 38 skipping to change at page 8, line 38
host_name(0), (255) host_name(0), (255)
} NameType; } NameType;
opaque HostName<1..2^16-1>; opaque HostName<1..2^16-1>;
struct { struct {
ServerName server_name_list<1..2^16-1> ServerName server_name_list<1..2^16-1>
} ServerNameList; } ServerNameList;
The ServerNameList MUST NOT contain more than one name of the same The ServerNameList MUST NOT contain more than one name of the same
name_type. If the server understood the client hello extension but name_type. If the server understood the ClientHello extension but
does not recognize any of the server names, it SHOULD send an does not recognize the server name, the server SHOULD take one of two
unrecognized_name(112) alert (which MAY be fatal). actions: either abort the handshake by sending a fatal-level
unrecognized_name(112) alert, or continue the handshake. It is NOT
RECOMMENDED to send a warning-level unrecognized_name(112) alert,
because the client's behavior in response to warning-level alerts is
unpredictable. If there is a mismatch between the server name used by
the client application and the server name of the credential chosen
by the server, this mismatch will become apparent when the client
application performs the server endpoint identification, at which
point the client application will have to decide whether to proceed
with the communication. TLS implementations are encouraged to make
information available to application callers about warning-level
alerts that were received or sent during a TLS handshake. Such
information can be useful for diagnostic purposes..
Note: Earlier versions of this specification permitted multiple Note: Earlier versions of this specification permitted multiple
names of the same name_type. In practice, current client names of the same name_type. In practice, current client
implementations only send one name, and the client cannot implementations only send one name, and the client cannot
INTERNET-DRAFT TLS Extension Definitions
necessarily find out which name the server selected. Multiple necessarily find out which name the server selected. Multiple
names of the same name_type are therefore now prohibited. names of the same name_type are therefore now prohibited.
Currently, the only server names supported are DNS hostnames; Currently, the only server names supported are DNS hostnames;
however, this does not imply any dependency of TLS on DNS, and other 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 name types may be added in the future (by an RFC that updates this
document). However, for backward compatibility, all future NameTypes document). However, for backward compatibility, all future NameTypes
MUST begin with a 16-bit length field. TLS MAY treat provided server MUST begin with a 16-bit length field. TLS MAY treat provided server
names as opaque data and pass the names and types to the application. names as opaque data and pass the names and types to the application.
"HostName" contains the fully qualified DNS hostname of the server, "HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte as understood by the client. The hostname is represented as a byte
INTERNET-DRAFT TLS Extension Definitions
string using ASCII encoding without a trailing dot. string using ASCII encoding without a trailing dot.
Literal IPv4 and IPv6 addresses are not permitted in "HostName". Literal IPv4 and IPv6 addresses are not permitted in "HostName".
It is RECOMMENDED that clients include an extension of type It is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server by a "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" 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
skipping to change at page 29, line 24 skipping to change at page 29, line 24
extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
client and server Hello extension mechanisms have been moved into RFC client and server Hello extension mechanisms have been moved into RFC
5246, TLS 1.2, so this document, which is associated with RFC 5246, 5246, TLS 1.2, so this document, which is associated with RFC 5246,
includes only the handshake extension mechanisms and the specific includes only the handshake extension mechanisms and the specific
extensions from RFC 4366. RFC 5246 also specifies the unknown extensions from RFC 4366. RFC 5246 also specifies the unknown
extension error and new extension specification considerations so extension error and new extension specification considerations so
that material has been removed from this document. that material has been removed from this document.
The Server Name extension now specifies only ASCII representation, The Server Name extension now specifies only ASCII representation,
eliminating UTF-8. It is provided that the ServerNameList can contain eliminating UTF-8. It is provided that the ServerNameList can contain
more only one name of any particular name_type. Provision was added more only one name of any particular name_type. If a server name is
for the user using the server_name extension in deciding whether or provided but not recognized, the server should either continue the
not to resume a session. Furthermores, this extensions should be the handshake without an error or send a fatal error. Sending a warning
same in a session resumption request as it was in the full handshake level message is not recommended because client behavior will be
that established the session. Such a resumption request must not be unpredictable. Provision was added for the user using the server_name
accepted if the server_name extension is different but instead a full extension in deciding whether or not to resume a session.
handshake must be done to possibly establish a new session. Furthermores, this extension should be the same in a session
resumption request as it was in the full handshake that established
the session. Such a resumption request must not be accepted if the
server_name extension is different but instead a full handshake must
be done to possibly establish a new session.
The Client Certificate URLs extension has been changed to make the The Client Certificate URLs extension has been changed to make the
presence of a hash mandatory. presence of a hash mandatory.
For the case of DTLS, the requirement to report an overflow of the For the case of DTLS, the requirement to report an overflow of the
negotiated maximum fragment length is made conditional on passing negotiated maximum fragment length is made conditional on passing
authentication. authentication.
The material was also re-organized in minor ways. For example, The material was also re-organized in minor ways. For example,
information as to which errors are fatal is moved from the one "Error information as to which errors are fatal is moved from the one "Error
 End of changes. 8 change blocks. 
18 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/