--- 1/draft-ietf-tls-rfc4366-bis-08.txt 2010-06-12 06:13:36.000000000 +0200 +++ 2/draft-ietf-tls-rfc4366-bis-09.txt 2010-06-12 06:13:36.000000000 +0200 @@ -1,19 +1,19 @@ TLS Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Obsoletes: 4366 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 - + Abstract This document provides specifications for existing TLS extensions. It is a companion document for the TLS 1.2 specification [RFC5246]. The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. Status of This Memo @@ -159,21 +159,21 @@ TLS clients and servers may use the extensions described in this document. 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. 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 + Note also that all the extensions defined in this document are relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions 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 client hello while requesting session resumption: - The server name indication extension MAY be used by the server when deciding whether or not to resume a session as described in section 3. @@ -185,22 +185,23 @@ 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. INTERNET-DRAFT TLS Extension Definitions 1.2 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 RFC 2119. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in RFC + 2119. INTERNET-DRAFT TLS Extension Definitions 2. Extensions to the Handshake Protocol This document specifies the use of two new handshake messages, "CertificateURL" and "CertificateStatus". These messages are described in Section 5 and Section 8, respectively. The new handshake message structure therefore becomes: @@ -258,42 +259,54 @@ host_name(0), (255) } NameType; opaque HostName<1..2^16-1>; struct { ServerName server_name_list<1..2^16-1> } ServerNameList; The ServerNameList MUST NOT contain more than one name of the same - name_type. If the server understood the client hello extension but - does not recognize any of the server names, it SHOULD send an - unrecognized_name(112) alert (which MAY be fatal). + name_type. If the server understood the ClientHello extension but + does not recognize the server name, the server SHOULD take one of two + 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 names of the same name_type. In practice, current client implementations only send one name, and the client cannot + +INTERNET-DRAFT TLS Extension Definitions + necessarily find out which name the server selected. Multiple names of the same name_type are therefore now prohibited. 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). However, for backward compatibility, all future NameTypes 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. "HostName" contains the fully qualified DNS hostname of the server, 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. 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 @@ -1083,27 +1096,31 @@ extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The client and server Hello extension mechanisms have been moved into RFC 5246, TLS 1.2, so this document, which is associated with RFC 5246, includes only the handshake extension mechanisms and the specific extensions from RFC 4366. RFC 5246 also specifies the unknown extension error and new extension specification considerations so that material has been removed from this document. The Server Name extension now specifies only ASCII representation, eliminating UTF-8. It is provided that the ServerNameList can contain - more only one name of any particular name_type. Provision was added - for the user using the server_name extension in deciding whether or - not to resume a session. Furthermores, this extensions 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. + more only one name of any particular name_type. If a server name is + provided but not recognized, the server should either continue the + handshake without an error or send a fatal error. Sending a warning + level message is not recommended because client behavior will be + unpredictable. Provision was added for the user using the server_name + extension in deciding whether or not to resume a 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 presence of a hash mandatory. For the case of DTLS, the requirement to report an overflow of the negotiated maximum fragment length is made conditional on passing authentication. The material was also re-organized in minor ways. For example, information as to which errors are fatal is moved from the one "Error