--- 1/draft-ietf-tls-rfc4366-bis-05.txt 2009-10-26 19:12:33.000000000 +0100 +++ 2/draft-ietf-tls-rfc4366-bis-06.txt 2009-10-26 19:12:33.000000000 +0100 @@ -1,19 +1,19 @@ TLS Working Group Donald Eastlake 3rd INTERNET-DRAFT Stellar Switches Obsoletes: RFC 4366 Intended status: Proposed Standard -Expires: December 21, 2009 June 22, 2009 +Expires: April 24, 2010 October 25, 2009 Transport Layer Security (TLS) Extensions: Extension Definitions - + Status of This Document This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -56,51 +56,51 @@ This draft is based on material from RFC 4366 for which the authors were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T. Wright. Table of Contents Status of This Document....................................1 Abstract...................................................1 Acknowledgements...........................................2 - Table of Contents..........................................2 1. Introduction............................................3 1.1 Specific Extensions Covered............................3 1.2 Conventions Used in This Document......................4 2. Extensions to the Handshake Protocol....................5 3. Server Name Indication..................................6 4. Maximum Fragment Length Negotiation.....................8 5. Client Certificate URLs................................10 6. Trusted CA Indication..................................13 7. Truncated HMAC.........................................15 8. Certificate Status Request.............................16 9. Error Alerts...........................................18 - 10. IANA Considerations...................................19 + 10. IANA Considerations...................................19 11. Security Considerations...............................19 11.1 Security Considerations for server_name..............19 11.2 Security Considerations for max_fragment_length......19 11.3 Security Considerations for client_certificate_url...20 11.4 Security Considerations for trusted_ca_keys..........21 11.5 Security Considerations for truncated_hmac...........21 11.6 Security Considerations for status_request...........21 - 12. Normative References..................................22 - 13. Informative References................................22 + 12. Normative References..................................23 + 13. Informative References................................23 - Annex A: pkipath MIME Type Registration...................24 - Annex B: Changes from RFC 4366............................26 - Author's Address..........................................27 - Copyright and IPR Provisions..............................28 + Annex A: pkipath MIME Type Registration...................25 + Annex B: Changes from RFC 4366............................27 + + Author's Address..........................................28 + Copyright and IPR Provisions..............................29 INTERNET-DRAFT TLS Extension Definitions 1. Introduction The TLS (Transport Layer Security) Protocol Version 1.2 is specified in [RFC5246]. That specification includes the framework for extensions to TLS, considerations in designing such extensions (see Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the allocation of new extension code points; however, it does not specify @@ -160,20 +160,38 @@ Certificate Status Protocol (OCSP) [RFC2560] response) during a TLS handshake. This functionality is desirable in order to avoid sending a Certificate Revocation List (CRL) over a constrained access network and therefore save bandwidth. 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 + 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 resumption: + + - If the resumption request is denied, the use of the extensions + is negotiated as normal. + + - If, on the other hand, the older session is resumed, then the + 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. + 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 [RFC2119]. INTERNET-DRAFT TLS Extension Definitions 2. Extensions to the Handshake Protocol @@ -242,22 +260,23 @@ ServerName server_name_list<1..2^16-1> } ServerNameList; 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). 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). TLS MAY treat provided server names as opaque data and - pass the names and types to the application. + 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 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. @@ -331,22 +350,24 @@ output of the record layer may be larger. For example, if the negotiated length is 2^9=512, then for currently defined cipher suites (those defined in [RFC5246], [RFC2712], and [RFC3268]), and INTERNET-DRAFT TLS Extension Definitions when null compression is used, the record layer output can be at most 805 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes of padding, and 32 bytes of MAC. This means that in this event a TLS record layer peer receiving a TLS record layer message larger - than 805 bytes may discard the message and send a "record_overflow" - alert, without decrypting the message. + than 805 bytes MUST discard the message and send a "record_overflow" + alert, without decrypting the message. When this extension is used + with DTLS implementations SHOULD NOT generate record_overflow alerts + unless the packet passes message authentication. INTERNET-DRAFT TLS Extension Definitions 5. 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. @@ -375,21 +396,21 @@ individual_certs(0), pkipath(1), (255) } CertChainType; struct { CertChainType type; URLAndHash url_and_hash_list<1..2^16-1>; } CertificateURL; struct { opaque url<1..2^16-1>; - opaque padding<1>; + unint8 padding; opaque SHA1Hash[20]; } URLAndHash; Here "url_and_hash_list" contains a sequence of URLs and hashes. Each "url" MUST be an absolute URI reference according to [RFC3986] that can be immediately used to fetch the certificate(s). When X.509 certificates are used, there are two possibilities: - If CertificateURL.type is "individual_certs", each URL refers to a @@ -762,38 +783,43 @@ In general, implementers should continue to monitor the state of the art and address any weaknesses identified. 11.1 Security Considerations for 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. + Since it is possible for a client to present a different server_name + in the application protocol, application server implementations that + rely upon these names being the same MUST check to make sure the + client did not present a different name in the application protocol. + Implementations MUST ensure that a buffer overflow does not occur, whatever the values of the length fields in server_name. 11.2 Security Considerations for 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. +INTERNET-DRAFT TLS Extension Definitions + Note that as described in Section 4, 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. -INTERNET-DRAFT TLS Extension Definitions - 11.3 Security Considerations for client_certificate_url Support for client_certificate_url involves the server's acting as a client in another URI scheme dependent protocol. The server therefore becomes subject to many of the same security concerns that clients of the URI 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 @@ -822,27 +848,28 @@ It is also RECOMMENDED that URI schemes be enabled by the administrator individually, and only a minimal set of schemes be enabled. Unusual protocols that offer limited security or whose security is not well understood SHOULD be avoided. As discussed in [RFC3986], URLs that specify ports other than the default may cause problems, as may very long URLs (which are more likely to be useful in exploiting buffer overflow bugs). Also note that HTTP caching proxies are common on the Internet, and + +INTERNET-DRAFT TLS Extension Definitions + some proxies do not check for the latest version of an object correctly. If a request using HTTP (or another caching protocol) goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response. -INTERNET-DRAFT TLS Extension Definitions - 11.4 Security Considerations for trusted_ca_keys It is possible that which CA root keys a client possesses could be regarded as confidential information. As a result, the CA root key indication extension should be used with care. The use of the SHA-1 certificate hash alternative ensures that each certificate is specified unambiguously. As for the previous extension, it was not believed necessary to use both MD5 and SHA-1 hashes. @@ -869,20 +896,22 @@ problem into account, it would be able to veto use of this extension. 11.6 Security Considerations for status_request If a client requests an OCSP response, it must take into account that 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 of certificates SHOULD either contact the OCSP server directly or abort the handshake. +INTERNET-DRAFT TLS Extension Definitions + Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that attempt to replay OCSP responses; see Section 4.4.1 of [RFC2560] for further details. INTERNET-DRAFT TLS Extension Definitions 12. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. @@ -1031,20 +1060,24 @@ 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. 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 Alerts" section to the individual extension specifications. INTERNET-DRAFT TLS Extension Definitions Author's Address Donald Eastlake 3rd Stellar Switches, Inc.