--- 1/draft-ietf-tls-rfc4366-bis-01.txt 2008-02-25 21:12:30.000000000 +0100 +++ 2/draft-ietf-tls-rfc4366-bis-02.txt 2008-02-25 21:12:30.000000000 +0100 @@ -1,20 +1,20 @@ + TLS Working Group Donald Eastlake 3rd INTERNET-DRAFT Motorola Laboratories Obsoletes: RFC 4366 -Updates: RFC 2246, RFC 4346 Intended status: Proposed Standard -Expires: July 2008 January 14, 2009 +Expires: August 2008 February 20, 2008 Transport Layer Security (TLS) Extensions: Extension Definitions - + Status of This Document By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Distribution of this document is unlimited. Comments should be sent to the TLS working group mailing list . @@ -54,61 +54,64 @@ 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 - 3. Server Name Indication..................................5 - 4. Maximum Fragment Length Negotiation.....................6 - 5. Client Certificate URLs.................................7 - 6. Trusted CA Indication..................................10 - 7. Truncated HMAC.........................................11 - 8. Certificate Status Request.............................12 + 2. Extensions to the Handshake Protocol....................5 - 9. IANA Considerations....................................15 - 10. Security Considerations...............................15 - 10.1 Security Considerations for server_name..............15 - 10.2 Security Considerations for max_fragment_length......15 - 10.3 Security Considerations for client_certificate_url...16 - 10.4 Security Considerations for trusted_ca_keys..........17 - 10.5 Security Considerations for truncated_hmac...........17 - 10.6 Security Considerations for status_request...........18 - 11. Internationalization Considerations...................18 + 3. Server Name Indication..................................6 + 4. Maximum Fragment Length Negotiation.....................7 + 5. Client Certificate URLs.................................8 + 6. Trusted CA Indication..................................11 + 7. Truncated HMAC.........................................12 + 8. Certificate Status Request.............................13 - 12. Normative References..................................19 - 13. Informative References................................19 + 9. Error Alerts...........................................16 - Copyright, Disclaimer, and Additional IPR Provisions......21 + 10. IANA Considerations...................................17 + 11. Security Considerations...............................17 + 11.1 Security Considerations for server_name..............17 + 11.2 Security Considerations for max_fragment_length......17 + 11.3 Security Considerations for client_certificate_url...18 + 11.4 Security Considerations for trusted_ca_keys..........19 + 11.5 Security Considerations for truncated_hmac...........19 + 11.6 Security Considerations for status_request...........20 - Author's Address..........................................22 - Expiration and File Name..................................22 + 12. Normative References..................................21 + 13. Informative References................................21 + + Copyright, Disclaimer, and Additional IPR Provisions......22 + + Author's Address..........................................23 + Expiration and File Name..................................23 INTERNET-DRAFT TLS Extension Definitions 1. Introduction The TLS (Transport Layer Security) Protocol Version 1.2 is specified in [RFCTLS]. That specification includes the framework for extensions to TLS, considerations in designing such extensions (see Section 7.4.1.4 of [RFCTLS]), and IANA Considerations for the allocation of new extension code points; however, it does not specify any - particular extensions other than CertHashTypes (see Section + particular extensions other than Signature Algorithms (see Section 7.4.1.4.1of [RFCTLS]). This document provides the specifications for existing TLS - extensions. It is, for the most part, the mere adaptation and editing - of material from [RFC4366], which covered all aspects of TLS - extensions for TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346]. + extensions. It is, for the most part, the adaptation and editing of + material from [RFC4366], which covered TLS extensions for TLS 1.0 + [RFC2246] and TLS 1.1 [RFC4346]. 1.1 Specific Extensions Covered The extensions described here focus on extending the functionality provided by the TLS protocol message formats. Other issues, such as the addition of new cipher suites, are deferred. Specifically, the extensions described in this document: - Allow TLS clients to provide to the TLS server the name of the @@ -141,31 +144,67 @@ the client certificate status information (e.g., an Online 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. 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 that support the extensions can talk to TLS - servers that do not support the extensions, and vice versa. The - document therefore updates TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346]. + servers that do not support the extensions, and vice versa. 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 + + 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: + + 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_status(22), + (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + case certificate_url: CertificateURL; + case certificate_status: CertificateStatus; + } body; + } Handshake; + +INTERNET-DRAFT TLS Extension Definitions + 3. Server Name Indication 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 servers that host multiple 'virtual' servers at a single underlying network address. In order to provide the server name, clients MAY include an extension of type "server_name" in the (extended) client hello. The @@ -182,53 +221,42 @@ enum { host_name(0), (255) } NameType; opaque HostName<1..2^16-1>; struct { 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. "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 [RFC3629], without a trailing dot. - - 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 - of [RFC3490] notwithstanding). If the server needs to match the - HostName against names that contain non-US-ASCII characters, it MUST - perform the conversion operation described in Section 4 of [RFC3490], - treating the HostName as a "query string" (i.e., the AllowUnassigned - flag MUST be set). Note that IDNA allows labels to be separated by - any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61; - therefore, servers MUST accept any of these characters as a label - -INTERNET-DRAFT TLS Extension Definitions - - separator. If the server only needs to match the HostName against - names containing exclusively ASCII characters, it MUST compare ASCII - names case-insensitively. + 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. +INTERNET-DRAFT TLS Extension Definitions + A server that receives a client hello containing the "server_name" 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 SHALL include an extension of type "server_name" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty. If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" @@ -253,32 +281,33 @@ client hello. The "extension_data" field of this extension SHALL contain: enum{ 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) } MaxFragmentLength; whose value is the desired maximum fragment length. The allowed values for this field are: 2^9, 2^10, 2^11, and 2^12. -INTERNET-DRAFT TLS Extension Definitions - Servers that receive an extended client hello containing a "max_fragment_length" extension MAY accept the requested maximum fragment length by including an extension of type "max_fragment_length" in the (extended) server hello. The "extension_data" field of this extension SHALL contain a "MaxFragmentLength" whose value is the same as the requested maximum fragment length. If a server receives a maximum fragment length negotiation request for a value other than the allowed values, it MUST abort the + +INTERNET-DRAFT TLS Extension Definitions + handshake with an "illegal_parameter" alert. Similarly, if a client receives a maximum fragment length negotiation response that differs from the length it requested, it MUST also abort the handshake with an "illegal_parameter" alert. 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 @@ -287,55 +316,56 @@ The negotiated length applies for the duration of the session including session resumptions. The negotiated length limits the input that the record layer may process without fragmentation (that is, the maximum value of TLSPlaintext.length; see [RFCTLS], Section 6.2.1). Note that the 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 [RFCTLS], [RFC2712], and [RFC3268]), 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 + 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 793 bytes may discard the message and send a "record_overflow" + than 805 bytes may discard the message and send a "record_overflow" alert, without decrypting the message. 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. In order to negotiate sending certificate URLs to a server, clients MAY include an extension of type "client_certificate_url" in the - -INTERNET-DRAFT TLS Extension Definitions - (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 + +INTERNET-DRAFT TLS Extension Definitions + "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: + "CertificateURL" message in place of a "Certificate" message as + follows (see also Section 2): enum { individual_certs(0), pkipath(1), (255) } CertChainType; enum { false(0), true(1) } Boolean; struct { @@ -356,31 +386,31 @@ 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. -INTERNET-DRAFT TLS Extension Definitions - - 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 of [RFCTLS]. 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. +INTERNET-DRAFT TLS Extension Definitions + 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 [RFCTLS], 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 @@ -408,37 +438,40 @@ 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" [RFC2585], and when a chain of X.509v3 certificates is returned, the Content- Type is "application/pkix-pkipath" (see Section 8 of [RFCTLS]). -INTERNET-DRAFT TLS Extension Definitions - 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. + bad_certificate_hash_value(114) alert. This alert is always fatal. - 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. + Clients may choose to send either "Certificate" or "CertificateURL" + after successfully negotiating the option to send certificate URLs. + +INTERNET-DRAFT TLS Extension Definitions + + 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. + a certificate_unobtainable(111) error alert. This alert MAY be fatal; + for example, if client authentication is required by the server for + the handshake to continue. 6. 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) @@ -459,28 +492,29 @@ } 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>; -INTERNET-DRAFT TLS Extension Definitions - 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 + +INTERNET-DRAFT TLS Extension Definitions + 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. @@ -509,47 +543,47 @@ 7. Truncated HMAC Currently defined TLS cipher suites use the MAC construction HMAC with either MD5 or SHA-1 [RFC2104] 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 - -INTERNET-DRAFT TLS Extension Definitions - 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 + +INTERNET-DRAFT TLS Extension Definitions + 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 [RFC2104]. 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 + specified in [RFC2104]. That is, SecurityParameters.mac_length 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. 8. Certificate Status Request Constrained clients may wish to use a certificate-status protocol such as OCSP [RFC2560] to check the validity of server certificates, in order to avoid transmission of CRLs and therefore save bandwidth @@ -560,29 +594,29 @@ 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; - -INTERNET-DRAFT TLS Extension Definitions - } CertificateStatusRequest; enum { ocsp(1), (255) } CertificateStatusType; struct { ResponderID responder_id_list<0..2^16-1>; + +INTERNET-DRAFT TLS Extension Definitions + 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 @@ -606,115 +640,154 @@ 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. + extended server hello. The "CertificateStatus" message is conveyed + using the handshake message type "certificate_status" as follows (see + also Section 2): struct { CertificateStatusType status_type; select (status_type) { case ocsp: OCSPResponse; } response; - -INTERNET-DRAFT TLS Extension Definitions - } 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 [RFC2560]). Note that - only one OCSP response may be sent. +INTERNET-DRAFT TLS Extension Definitions - The "CertificateStatus" message is conveyed using the handshake - message type "certificate_status". + An "ocsp_response" contains a complete, DER-encoded OCSP response + (using the ASN.1 type OCSPResponse defined in [RFC2560]). Only one + OCSP response may be sent. 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. + the handshake if the response is not satisfactory with + bad_certificate_status_response(113) alert. This alert is always + fatal. + +INTERNET-DRAFT TLS Extension Definitions + +9. Error Alerts + This section defines new error alerts for use with the TLS extensions + defined in this document. + + Four 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. 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), certificate_unobtainable(111), /* new */ unrecognized_name(112), /* new */ bad_certificate_status_response(113), /* new */ bad_certificate_hash_value(114), /* new */ (255) } AlertDescription; INTERNET-DRAFT TLS Extension Definitions -9. IANA Considerations +10. IANA Considerations IANA Considerations for TLS Extensions and the creation of a Registry therefore are all covered in Section 12 of [RFCTLS].. -10. Security Considerations +11. Security Considerations General Security Considerations for TLS Extensions are covered in [RFCTLS]. Security Considerations for particular extensions specified in this document are 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 [RFC2246] and the TLS 1.1 RFC [RFC4346]. -10.1 Security Considerations for server_name +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. 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. -10.2 Security Considerations for max_fragment_length +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. Note that as described in Section 4, once a non-null cipher suite has INTERNET-DRAFT TLS Extension Definitions 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. -10.3 Security Considerations for client_certificate_url +11.3 Security Considerations for 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 @@ -774,32 +847,32 @@ 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 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. -10.4 Security Considerations for trusted_ca_keys +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. -10.5 Security Considerations for truncated_hmac +11.5 Security Considerations for truncated_hmac It is possible that truncated MACs are weaker than "un-truncated" MACs. However, no significant weaknesses are currently known or expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. Note that the output length of a MAC need not be as long as the INTERNET-DRAFT TLS Extension Definitions length of a symmetric cipher key, since forging of MAC values cannot @@ -809,39 +882,32 @@ Since the MAC algorithm only takes effect after all handshake messages that affect extension parameters have been authenticated by the hashes in the Finished messages, it is not possible for an active attacker to force negotiation of the truncated HMAC extension where it would not otherwise be used (to the extent that the handshake authentication is secure). Therefore, in the event that any 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. -10.6 Security Considerations for status_request +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. 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. -11. Internationalization Considerations - - None of the extensions defined here directly use strings subject to - localization. Domain Name System (DNS) hostnames are encoded using - UTF-8. If future extensions use text strings, then - internationalization should be considered in their design. - 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. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -854,47 +920,38 @@ 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. - [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, - "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, - March 2003. - - [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", - STD 63, RFC 3629, November 2003. - [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFCTLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-*.txt, March 2007. 13. Informative References [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. -INTERNET-DRAFT TLS Extension Definitions - [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. INTERNET-DRAFT TLS Extension Definitions Copyright, Disclaimer, and Additional IPR Provisions @@ -942,13 +999,13 @@ Donald Eastlake 3rd Motorola Laboratories 111 Locke Drive Marlborough, MA 01752 Tel: +1-508-786-7554 Email: Donald.Eastlake@motorola.com Expiration and File Name - This draft expires in July 2008. + This draft expires in August 2008. - Its file name is draft-ietf-tls-rfc4366-bis-01.txt. + Its file name is draft-ietf-tls-rfc4366-bis-02.txt.