draft-ietf-tls-rfc4366-bis-05.txt   draft-ietf-tls-rfc4366-bis-06.txt 
TLS Working Group Donald Eastlake 3rd TLS Working Group Donald Eastlake 3rd
INTERNET-DRAFT Stellar Switches INTERNET-DRAFT Stellar Switches
Obsoletes: RFC 4366 Obsoletes: RFC 4366
Intended status: Proposed Standard 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 Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-05.txt> <draft-ietf-tls-rfc4366-bis-06.txt>
Status of This Document Status of This Document
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 2, line 18 skipping to change at page 2, line 18
This draft is based on material from RFC 4366 for which the authors 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. were S. Blake-Wilson, M. Nystron, D. Hopwood, J. Mikkelsen, and T.
Wright. Wright.
Table of Contents Table of Contents
Status of This Document....................................1 Status of This Document....................................1
Abstract...................................................1 Abstract...................................................1
Acknowledgements...........................................2 Acknowledgements...........................................2
Table of Contents..........................................2
1. Introduction............................................3 1. Introduction............................................3
1.1 Specific Extensions Covered............................3 1.1 Specific Extensions Covered............................3
1.2 Conventions Used in This Document......................4 1.2 Conventions Used in This Document......................4
2. Extensions to the Handshake Protocol....................5 2. Extensions to the Handshake Protocol....................5
3. Server Name Indication..................................6 3. Server Name Indication..................................6
4. Maximum Fragment Length Negotiation.....................8 4. Maximum Fragment Length Negotiation.....................8
5. Client Certificate URLs................................10 5. Client Certificate URLs................................10
6. Trusted CA Indication..................................13 6. Trusted CA Indication..................................13
7. Truncated HMAC.........................................15 7. Truncated HMAC.........................................15
8. Certificate Status Request.............................16 8. Certificate Status Request.............................16
9. Error Alerts...........................................18 9. Error Alerts...........................................18
10. IANA Considerations...................................19
10. IANA Considerations...................................19
11. Security Considerations...............................19 11. Security Considerations...............................19
11.1 Security Considerations for server_name..............19 11.1 Security Considerations for server_name..............19
11.2 Security Considerations for max_fragment_length......19 11.2 Security Considerations for max_fragment_length......19
11.3 Security Considerations for client_certificate_url...20 11.3 Security Considerations for client_certificate_url...20
11.4 Security Considerations for trusted_ca_keys..........21 11.4 Security Considerations for trusted_ca_keys..........21
11.5 Security Considerations for truncated_hmac...........21 11.5 Security Considerations for truncated_hmac...........21
11.6 Security Considerations for status_request...........21 11.6 Security Considerations for status_request...........21
12. Normative References..................................22 12. Normative References..................................23
13. Informative References................................22 13. Informative References................................23
Annex A: pkipath MIME Type Registration...................24 Annex A: pkipath MIME Type Registration...................25
Annex B: Changes from RFC 4366............................26 Annex B: Changes from RFC 4366............................27
Author's Address..........................................27
Copyright and IPR Provisions..............................28 Author's Address..........................................28
Copyright and IPR Provisions..............................29
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
1. Introduction 1. Introduction
The TLS (Transport Layer Security) Protocol Version 1.2 is specified The TLS (Transport Layer Security) Protocol Version 1.2 is specified
in [RFC5246]. That specification includes the framework for in [RFC5246]. That specification includes the framework for
extensions to TLS, considerations in designing such extensions (see extensions to TLS, considerations in designing such extensions (see
Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the Section 7.4.1.4 of [RFC5246]), and IANA Considerations for the
allocation of new extension code points; however, it does not specify allocation of new extension code points; however, it does not specify
skipping to change at page 4, line 26 skipping to change at page 4, line 26
Certificate Status Protocol (OCSP) [RFC2560] response) during a Certificate Status Protocol (OCSP) [RFC2560] response) during a
TLS handshake. This functionality is desirable in order to avoid TLS handshake. This functionality is desirable in order to avoid
sending a Certificate Revocation List (CRL) over a constrained sending a Certificate Revocation List (CRL) over a constrained
access network and therefore save bandwidth. access network and therefore save bandwidth.
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
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 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
2. Extensions to the Handshake Protocol 2. Extensions to the Handshake Protocol
skipping to change at page 6, line 44 skipping to change at page 6, line 44
ServerName server_name_list<1..2^16-1> ServerName server_name_list<1..2^16-1>
} ServerNameList; } ServerNameList;
If the server understood the client hello extension but does not If the server understood the client hello extension but does not
recognize any of the server names, it SHOULD send an recognize any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal). unrecognized_name(112) alert (which MAY be fatal).
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). TLS MAY treat provided server names as opaque data and document). However, for backward compatibility, all future NameTypes
pass the names and types to the application. 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, "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
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.
skipping to change at page 9, line 11 skipping to change at page 9, line 11
output of the record layer may be larger. For example, if the output of the record layer may be larger. For example, if the
negotiated length is 2^9=512, then for currently defined cipher negotiated length is 2^9=512, then for currently defined cipher
suites (those defined in [RFC5246], [RFC2712], and [RFC3268]), and suites (those defined in [RFC5246], [RFC2712], and [RFC3268]), and
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
when null compression is used, the record layer output can be at most 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 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 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 a TLS record layer peer receiving a TLS record layer message larger
than 805 bytes may discard the message and send a "record_overflow" than 805 bytes MUST discard the message and send a "record_overflow"
alert, without decrypting the message. 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 INTERNET-DRAFT TLS Extension Definitions
5. Client Certificate URLs 5. Client Certificate URLs
Without this extension, TLS specifies that when client authentication Without this extension, TLS specifies that when client authentication
is performed, client certificates are sent by clients to servers is performed, client certificates are sent by clients to servers
during the TLS handshake. It may be desirable for constrained clients during the TLS handshake. It may be desirable for constrained clients
to send certificate URLs in place of certificates, so that they do to send certificate URLs in place of certificates, so that they do
not need to store their certificates and can therefore save memory. not need to store their certificates and can therefore save memory.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
individual_certs(0), pkipath(1), (255) individual_certs(0), pkipath(1), (255)
} CertChainType; } CertChainType;
struct { struct {
CertChainType type; CertChainType type;
URLAndHash url_and_hash_list<1..2^16-1>; URLAndHash url_and_hash_list<1..2^16-1>;
} CertificateURL; } CertificateURL;
struct { struct {
opaque url<1..2^16-1>; opaque url<1..2^16-1>;
opaque padding<1>; unint8 padding;
opaque SHA1Hash[20]; opaque SHA1Hash[20];
} URLAndHash; } URLAndHash;
Here "url_and_hash_list" contains a sequence of URLs and hashes. Here "url_and_hash_list" contains a sequence of URLs and hashes.
Each "url" MUST be an absolute URI reference according to [RFC3986] Each "url" MUST be an absolute URI reference according to [RFC3986]
that can be immediately used to fetch the certificate(s). that can be immediately used to fetch the certificate(s).
When X.509 certificates are used, there are two possibilities: When X.509 certificates are used, there are two possibilities:
- If CertificateURL.type is "individual_certs", each URL refers to a - If CertificateURL.type is "individual_certs", each URL refers to a
skipping to change at page 19, line 35 skipping to change at page 19, line 35
In general, implementers should continue to monitor the state of the In general, implementers should continue to monitor the state of the
art and address any weaknesses identified. art and address any weaknesses identified.
11.1 Security Considerations for server_name 11.1 Security Considerations for server_name
If a single server hosts several domains, then clearly it is If a single server hosts several domains, then clearly it is
necessary for the owners of each domain to ensure that this satisfies necessary for the owners of each domain to ensure that this satisfies
their security needs. Apart from this, server_name does not appear to their security needs. Apart from this, server_name does not appear to
introduce significant security issues. 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, Implementations MUST ensure that a buffer overflow does not occur,
whatever the values of the length fields in server_name. whatever the values of the length fields in server_name.
11.2 Security Considerations for max_fragment_length 11.2 Security Considerations for max_fragment_length
The maximum fragment length takes effect immediately, including for The maximum fragment length takes effect immediately, including for
handshake messages. However, that does not introduce any security handshake messages. However, that does not introduce any security
complications that are not already present in TLS, since TLS requires complications that are not already present in TLS, since TLS requires
implementations to be able to handle fragmented handshake messages. 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 Note that as described in Section 4, once a non-null cipher suite has
been activated, the effective maximum fragment length depends on the been activated, the effective maximum fragment length depends on the
cipher suite and compression method, as well as on the negotiated cipher suite and compression method, as well as on the negotiated
max_fragment_length. This must be taken into account when sizing max_fragment_length. This must be taken into account when sizing
buffers, and checking for buffer overflow. buffers, and checking for buffer overflow.
INTERNET-DRAFT TLS Extension Definitions
11.3 Security Considerations for client_certificate_url 11.3 Security Considerations for client_certificate_url
Support for client_certificate_url involves the server's acting as a Support for client_certificate_url involves the server's acting as a
client in another URI scheme dependent protocol. The server client in another URI scheme dependent protocol. The server
therefore becomes subject to many of the same security concerns that therefore becomes subject to many of the same security concerns that
clients of the URI scheme are subject to, with the added concern 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 the client can attempt to prompt the server to connect to some
(possibly weird-looking) URL. (possibly weird-looking) URL.
In general, this issue means that an attacker might use the server to In general, this issue means that an attacker might use the server to
skipping to change at page 20, line 49 skipping to change at page 21, line 4
It is also RECOMMENDED that URI schemes be enabled by the It is also RECOMMENDED that URI schemes be enabled by the
administrator individually, and only a minimal set of schemes be administrator individually, and only a minimal set of schemes be
enabled. Unusual protocols that offer limited security or whose enabled. Unusual protocols that offer limited security or whose
security is not well understood SHOULD be avoided. security is not well understood SHOULD be avoided.
As discussed in [RFC3986], URLs that specify ports other than the As discussed in [RFC3986], URLs that specify ports other than the
default may cause problems, as may very long URLs (which are more default may cause problems, as may very long URLs (which are more
likely to be useful in exploiting buffer overflow bugs). likely to be useful in exploiting buffer overflow bugs).
Also note that HTTP caching proxies are common on the Internet, and 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 some proxies do not check for the latest version of an object
correctly. If a request using HTTP (or another caching protocol) goes correctly. If a request using HTTP (or another caching protocol) goes
through a misconfigured or otherwise broken proxy, the proxy may through a misconfigured or otherwise broken proxy, the proxy may
return an out-of-date response. return an out-of-date response.
INTERNET-DRAFT TLS Extension Definitions
11.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 It is possible that which CA root keys a client possesses could be
regarded as confidential information. As a result, the CA root key regarded as confidential information. As a result, the CA root key
indication extension should be used with care. indication extension should be used with care.
The use of the SHA-1 certificate hash alternative ensures that each The use of the SHA-1 certificate hash alternative ensures that each
certificate is specified unambiguously. As for the previous certificate is specified unambiguously. As for the previous
extension, it was not believed necessary to use both MD5 and SHA-1 extension, it was not believed necessary to use both MD5 and SHA-1
hashes. hashes.
skipping to change at page 21, line 47 skipping to change at page 22, line 5
problem into account, it would be able to veto use of this extension. problem into account, it would be able to veto use of this extension.
11.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 If a client requests an OCSP response, it must take into account that
an attacker's server using a compromised key could (and probably an attacker's server using a compromised key could (and probably
would) pretend not to support the extension. In this case, a client would) pretend not to support the extension. In this case, a client
that requires OCSP validation of certificates SHOULD either contact that requires OCSP validation of certificates SHOULD either contact
the OCSP server directly or abort the handshake. 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 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
improve security against attacks that attempt to replay OCSP improve security against attacks that attempt to replay OCSP
responses; see Section 4.4.1 of [RFC2560] for further details. responses; see Section 4.4.1 of [RFC2560] for further details.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
12. Normative References 12. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February 1997. Hashing for Message Authentication", RFC 2104, February 1997.
skipping to change at page 26, line 28 skipping to change at page 27, line 28
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. eliminating UTF-8.
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
negotiated maximum fragment length is made conditional on passing
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
Alerts" section to the individual extension specifications. Alerts" section to the individual extension specifications.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Author's Address Author's Address
Donald Eastlake 3rd Donald Eastlake 3rd
Stellar Switches, Inc. Stellar Switches, Inc.
 End of changes. 18 change blocks. 
19 lines changed or deleted 52 lines changed or added

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