draft-ietf-tls-rfc4366-bis-10.txt   draft-ietf-tls-rfc4366-bis-11.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: January 29, 2011 July 30, 2010 Expires: March 18, 2011 September 19, 2010
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-10.txt> <draft-ietf-tls-rfc4366-bis-11.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 RFC 5246, "The Transport Layer Security
extensions specified are server_name, max_fragment_length, (TLS) Protocol Version 1.2". The extensions specified are
client_certificate_url, trusted_ca_keys, truncated_hmac, and server_name, max_fragment_length, client_certificate_url,
status_request. trusted_ca_keys, truncated_hmac, and status_request.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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 11 skipping to change at page 2, line 11
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Acknowledgements Acknowledgements
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. Other contributors include Joseph Salowey, and Alexey
Melnikov, Peter Saint-Andre, and Adrian Farrel.
Table of Contents Table of Contents
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......................5 1.2 Conventions Used in This Document......................5
2. Extensions to the Handshake Protocol....................6 2. Extensions to the Handshake Protocol....................6
3. Server Name Indication..................................7 3. Server Name Indication..................................7
4. Maximum Fragment Length Negotiation.....................9 4. Maximum Fragment Length Negotiation.....................9
skipping to change at page 3, line 19 skipping to change at page 3, line 19
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
any particular extensions other than Signature Algorithms (see any particular extensions other than Signature Algorithms (see
Section 7.4.1.4.1 of [RFC5246]). Section 7.4.1.4.1 of [RFC5246]).
This document provides the specifications for existing TLS This document provides the specifications for existing TLS
extensions. It is, for the most part, the adaptation and editing of extensions. It is, for the most part, the adaptation and editing of
material from [RFC4366], which covered TLS extensions for TLS 1.0 material from RFC 4366, which covered TLS extensions for TLS 1.0 (RFC
[RFC2246] and TLS 1.1 [RFC4346]. 2246) and TLS 1.1 (RFC 4346).
1.1 Specific Extensions Covered 1.1 Specific Extensions Covered
The extensions described here focus on extending the functionality The extensions described here focus on extending the functionality
provided by the TLS protocol message formats. Other issues, such as provided by the TLS protocol message formats. Other issues, such as
the addition of new cipher suites, are deferred. the addition of new cipher suites, are deferred.
The extension types defined in this document are: The extension types defined in this document are:
enum { enum {
skipping to change at page 5, line 10 skipping to change at page 5, 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in
2119. [RFC2119].
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 13 skipping to change at page 8, line 13
implementations only send one name, and the client cannot implementations only send one name, and the client cannot
INTERNET-DRAFT TLS Extension Definitions 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). The data structure associated with the host_name NameType
MUST begin with a 16-bit length field. TLS MAY treat provided server is a variable-length vector that begins with a 16-bit length. For
names as opaque data and pass the names and types to the application. backward compatibility, all future data structures associated with
new 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, "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. This allows the
support of internationalized domain names through the use of A-labels
defined in [RFC5890].
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
its selection of an appropriate certificate to return to the client, its selection of an appropriate certificate to return to the client,
skipping to change at page 12, line 50 skipping to change at page 12, line 50
Servers that support this extension MUST support the 'http' URI Servers that support this extension MUST support the 'http' URI
scheme for certificate URLs, and MAY support other schemes. Use of scheme for certificate URLs, and MAY support other schemes. Use of
other schemes than 'http', 'https', or 'ftp' may create unexpected other schemes than 'http', 'https', or 'ftp' may create unexpected
problems. problems.
If the protocol used is HTTP, then the HTTP server can be configured If the protocol used is HTTP, then the HTTP server can be configured
to use the Cache-Control and Expires directives described in to use the Cache-Control and Expires directives described in
[RFC2616] to specify whether and for how long certificates or [RFC2616] to specify whether and for how long certificates or
certificate chains should be cached. certificate chains should be cached.
The TLS server is not required to follow HTTP redirects when The TLS server MUST NOT follow HTTP redirects when retrieving the
retrieving the certificates or certificate chain. The URLs used in certificates or certificate chain. The URLs used in this extension
this extension SHOULD therefore be chosen not to depend on such MUST NOT be chosen to depend on such redirects.
redirects.
If the protocol used to retrieve certificates or certificate chains If the protocol used to retrieve certificates or certificate chains
returns a MIME-formatted response (as HTTP does), then the following returns a MIME-formatted response (as HTTP does), then the following
MIME Content-Types SHALL be used: when a single X.509v3 certificate
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [RFC2585], is returned, the Content-Type is "application/pkix-cert" [RFC2585],
and when a chain of X.509v3 certificates is returned, the Content- and when a chain of X.509v3 certificates is returned, the Content-
Type is "application/pkix-pkipath" Section 10.1. Type is "application/pkix-pkipath" Section 10.1.
The server MUST check that the SHA-1 hash of the contents of the The server MUST check that the SHA-1 hash of the contents of the
object retrieved from that URL (after decoding any MIME Content- object retrieved from that URL (after decoding any MIME Content-
Transfer-Encoding) matches the given hash. If any retrieved object Transfer-Encoding) matches the given hash. If any retrieved object
does not have the correct SHA-1 hash, the server MUST abort the does not have the correct SHA-1 hash, the server MUST abort the
handshake with a bad_certificate_hash_value(114) alert. This alert is handshake with a bad_certificate_hash_value(114) alert. This alert is
always fatal. always fatal.
Clients may choose to send either "Certificate" or "CertificateURL" Clients may choose to send either "Certificate" or "CertificateURL"
after successfully negotiating the option to send certificate URLs. after successfully negotiating the option to send certificate URLs.
The option to send a certificate is included to provide flexibility The option to send a certificate is included to provide flexibility
to clients possessing multiple certificates. to clients possessing multiple certificates.
If a server encounters an unreasonable delay in obtaining If a server is unable to obtain certificates in a given
certificates in a given CertificateURL, it SHOULD time out and signal CertificateURL, it MUST send a fatal certificate_unobtainable(111)
a certificate_unobtainable(111) error alert. This alert MAY be fatal; alert if it requires the certificates to complete the handshake. If
for example, if client authentication is required by the server for the server does not require the certificates then the server
the handshake to continue. continues the handshake. The server MAY send a warning level alert in
this case. Clients receiving such an alert SHOULD log the alert and
continue with the handshake if possible
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
6. Trusted CA Indication 6. Trusted CA Indication
Constrained clients that, due to memory limitations, possess only a Constrained clients that, due to memory limitations, possess only a
small number of CA root keys may wish to indicate to servers which small number of CA root keys may wish to indicate to servers which
root keys they possess, in order to avoid repeated handshake root keys they possess, in order to avoid repeated handshake
failures. failures.
skipping to change at page 14, line 56 skipping to change at page 15, line 5
Digital Signature Algorithm (DSA) and Elliptic Curve Digital Digital Signature Algorithm (DSA) and Elliptic Curve Digital
Signature Algorithm (ECDSA) keys, this is the hash of the Signature Algorithm (ECDSA) keys, this is the hash of the
"subjectPublicKey" value. For RSA keys, the hash is of the big- "subjectPublicKey" value. For RSA keys, the hash is of the big-
endian byte string representation of the modulus without any endian byte string representation of the modulus without any
initial 0-valued bytes. (This copies the key hash formats deployed initial 0-valued bytes. (This copies the key hash formats deployed
in other environments.) in other environments.)
- "x509_name": contains the DER-encoded X.509 DistinguishedName of - "x509_name": contains the DER-encoded X.509 DistinguishedName of
the CA. the CA.
- "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
- "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
Certificate containing the CA root key. Certificate containing the CA root key.
Note that clients may include none, some, or all of the CA root keys Note that clients may include none, some, or all of the CA root keys
they possess in this extension. they possess in this extension.
Note also that it is possible that a key hash or a Distinguished Name Note also that it is possible that a key hash or a Distinguished Name
alone may not uniquely identify a certificate issuer (for example, if alone may not uniquely identify a certificate issuer (for example, if
a particular CA has multiple key pairs). However, here we assume this a particular CA has multiple key pairs). However, here we assume this
is the case following the use of Distinguished Names to identify is the case following the use of Distinguished Names to identify
certificate issuers in TLS. certificate issuers in TLS.
skipping to change at page 20, line 15 skipping to change at page 20, line 15
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
10. IANA Considerations 10. IANA Considerations
IANA Considerations for TLS Extensions and the creation of a Registry IANA Considerations for TLS Extensions and the creation of a Registry
therefore are covered in Section 12 of [RFC5246] except for the therefore are covered in Section 12 of [RFC5246] except for the
registration of MIME type application/pkix-pkipath which appears registration of MIME type application/pkix-pkipath which appears
below. below.
The IANA TLS extensions and MIME type application/pkix-pkipath The IANA TLS extensions and MIME type application/pkix-pkipath
registry entries that reference [RFC4366] should be updated to registry entries that reference RFC 4366 should be updated to
reference this document on its publication as an RFC. reference this document on its publication as an RFC.
10.1 pkipath MIME Type Registration 10.1 pkipath MIME Type Registration
MIME media type name: application MIME media type name: application
MIME subtype name: pkix-pkipath MIME subtype name: pkix-pkipath
Required parameters: none Required parameters: none
Optional parameters: version (default value is "1") Optional parameters: version (default value is "1")
skipping to change at page 21, line 17 skipping to change at page 21, line 17
Note that this type only specifies a certificate chain that can be Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party's existing assessed for validity according to the relying party's existing
configuration of trusted CAs; it is not intended to be used to configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration. specify any change to that configuration.
Interoperability considerations: Interoperability considerations:
No specific interoperability problems are known with this type, No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general, but for recommendations relating to X.509 certificates in general,
see [RFC5280]. see [RFC5280].
Published specification: [RFC4366], and [RFC5280]. Published specification: This document and [RFC5280].
Applications which use this media type: TLS. It may also be used by Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate other protocols, or for general interchange of PKIX certificate
chains. chains.
Additional information: Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized. Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish it from other ASN.1 Further parsing is required to distinguish it from other ASN.1
types. types.
File extension(s): .pkipath File extension(s): .pkipath
Macintosh File Type Code(s): not specified Macintosh File Type Code(s): not specified
Person & email address to contact for further information: Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com> Magnus Nystrom <mnystrom@microsoft.com>
Intended usage: COMMON Intended usage: COMMON
Change controller: IESG <iesg@ietf.org> Change controller: IESG <iesg@ietf.org>
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
11. Security Considerations 11. Security Considerations
General Security Considerations for TLS Extensions are covered in General Security Considerations for TLS Extensions are covered in
skipping to change at page 25, line 10 skipping to change at page 25, line 10
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Certificate Adams, "X.509 Internet Public Key Infrastructure Online
Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
1999. May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol
HTTP/1.1", RFC 2616, June 1999. -- HTTP/1.1", RFC 2616, June 1999.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
2005. January 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Housley, R., and W. Polk, "Internet X.509 Public Key
Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, Infrastructure Certificate and Certificate Revocation List
May 2008 (CRL) Profile", RFC 5280, May 2008
13. Informative References [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", RFC
5890, August 2010.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 13. Informative References
RFC 2246, January 1999.
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. Suites to Transport Layer Security (TLS)", RFC 2712, October
1999.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, "Information Systems - Open Systems Interconnection - The
April 2006. Directory: Public key and attribute certificate frameworks."
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
"Information Systems - Open Systems Interconnection - The Directory:
Public key and attribute certificate frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
9594:8:2001. ISO/IEC 9594:8:2001.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Annex A: Changes from RFC 4366 Annex A: Changes from RFC 4366
The significant changes between RFC 4366 and this document are The significant changes between RFC 4366 and this document are
described below. described below.
RFC 4366 described both general extension mechanisms (for the TLS RFC 4366 described both general extension mechanisms (for the TLS
handshake and client and server hellos) as well as specific handshake and client and server hellos) as well as specific
skipping to change at page 27, line 43 skipping to change at page 27, line 43
server_name extension is different but instead a full handshake must server_name extension is different but instead a full handshake must
be done to possibly establish a new session. 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.
TLS servers are now prohibited from following HTTP redirects when
retrieving certificates.
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. 32 change blocks. 
61 lines changed or deleted 65 lines changed or added

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