draft-ietf-tls-rfc4366-bis-06.txt   draft-ietf-tls-rfc4366-bis-07.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: 4366
Intended status: Proposed Standard Intended status: Proposed Standard
Expires: April 24, 2010 October 25, 2009 Expires: November 13, 2010 May 14, 2010
Transport Layer Security (TLS) Extensions: Extension Definitions Transport Layer Security (TLS) Extensions: Extension Definitions
<draft-ietf-tls-rfc4366-bis-06.txt> <draft-ietf-tls-rfc4366-bis-07.txt>
Status of This Document Abstract
This Internet-Draft is submitted to IETF in full conformance with the This document provides specifications for existing TLS extensions. It
is a companion document for the TLS 1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request.
Status of This Memo
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
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to Process, except to format it for publication as an RFC or to
skipping to change at page 1, line 43 skipping to change at page 2, line 5
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
INTERNET-DRAFT TLS Extension Definitions
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
Abstract
This document provides specifications for existing TLS extensions. It
is a companion document for the TLS 1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request.
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.
Table of Contents Table of Contents
Status of This Document....................................1 1. Introduction............................................4
Abstract...................................................1 1.1 Specific Extensions Covered............................4
Acknowledgements...........................................2 1.2 Conventions Used in This Document......................5
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 2. Extensions to the Handshake Protocol....................6
11. Security Considerations...............................19 3. Server Name Indication..................................7
11.1 Security Considerations for server_name..............19 4. Maximum Fragment Length Negotiation.....................9
11.2 Security Considerations for max_fragment_length......19 5. Client Certificate URLs................................11
11.3 Security Considerations for client_certificate_url...20 6. Trusted CA Indication..................................14
11.4 Security Considerations for trusted_ca_keys..........21 7. Truncated HMAC.........................................16
11.5 Security Considerations for truncated_hmac...........21 8. Certificate Status Request.............................17
11.6 Security Considerations for status_request...........21 9. Error Alerts...........................................19
10. IANA Considerations...................................20
12. Normative References..................................23 11. Security Considerations...............................20
13. Informative References................................23 11.1 Security Considerations for server_name..............20
11.2 Security Considerations for max_fragment_length......20
11.3 Security Considerations for client_certificate_url...21
11.4 Security Considerations for trusted_ca_keys..........22
11.5 Security Considerations for truncated_hmac...........22
11.6 Security Considerations for status_request...........23
Annex A: pkipath MIME Type Registration...................25 12. Normative References..................................24
Annex B: Changes from RFC 4366............................27 13. Informative References................................24
Author's Address..........................................28 Annex A: pkipath MIME Type Registration...................26
Copyright and IPR Provisions..............................29 Annex B: Changes from RFC 4366............................28
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 6, line 37 skipping to change at page 7, line 37
enum { enum {
host_name(0), (255) host_name(0), (255)
} NameType; } NameType;
opaque HostName<1..2^16-1>; opaque HostName<1..2^16-1>;
struct { struct {
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 The ServerNameList MUST NOT contain more than one name of the same
recognize any of the server names, it SHOULD send an name_type. If the server understood the client hello extension but
does not recognize any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal). unrecognized_name(112) alert (which MAY be fatal).
Note: Earlier versions of this specification permitted multiple
names of the same name_type. In practice, current client
implementations only send one name, and the client cannot
necessarily find out which name the server selected. Multiple
names of the same name_type are therefore now prohibited.
Currently, the only server names supported are DNS hostnames; 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). However, for backward compatibility, all future NameTypes
MUST begin with a 16-bit length field. TLS MAY treat provided server 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. 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
INTERNET-DRAFT TLS Extension Definitions
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.
INTERNET-DRAFT TLS Extension Definitions
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,
and/or other aspects of security policy. In this event, the server and/or other aspects of security policy. In this event, the server
SHALL include an extension of type "server_name" in the (extended) SHALL include an extension of type "server_name" in the (extended)
server hello. The "extension_data" field of this extension SHALL be server hello. The "extension_data" field of this extension SHALL be
empty. empty.
When the server resumes a session, the server_name extension is
ignored.
If an application negotiates a server name using an application If an application negotiates a server name using an application
protocol and then upgrades to TLS, and if a server_name extension is protocol and then upgrades to TLS, and if a server_name extension is
sent, then the extension SHOULD contain the same name that was sent, then the extension SHOULD contain the same name that was
negotiated in the application protocol. If the server_name is negotiated in the application protocol. If the server_name is
established in the TLS session handshake, the client SHOULD NOT established in the TLS session handshake, the client SHOULD NOT
attempt to request a different server name at the application layer. attempt to request a different server name at the application layer.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
4. Maximum Fragment Length Negotiation 4. Maximum Fragment Length Negotiation
skipping to change at page 8, line 56 skipping to change at page 9, line 56
messages. messages.
The negotiated length applies for the duration of the session The negotiated length applies for the duration of the session
including session resumptions. including session resumptions.
The negotiated length limits the input that the record layer may The negotiated length limits the input that the record layer may
process without fragmentation (that is, the maximum value of process without fragmentation (that is, the maximum value of
TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the TLSPlaintext.length; see [RFC5246], Section 6.2.1). Note that the
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] and [RFC2712]), and when null
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
when null compression is used, the record layer output can be at most compression is used, the record layer output can be at most 805
805 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
bytes of padding, and 32 bytes of MAC. This means that in this event of padding, and 32 bytes of MAC. This means that in this event a TLS
a TLS record layer peer receiving a TLS record layer message larger record layer peer receiving a TLS record layer message larger than
than 805 bytes MUST discard the message and send a "record_overflow" 805 bytes MUST discard the message and send a "record_overflow"
alert, without decrypting the message. When this extension is used alert, without decrypting the message. When this extension is used
with DTLS implementations SHOULD NOT generate record_overflow alerts with DTLS implementations SHOULD NOT generate record_overflow alerts
unless the packet passes message authentication. 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
skipping to change at page 20, line 54 skipping to change at page 21, line 54
enabled by a server administrator, rather than be enabled by default. enabled by a server administrator, rather than be enabled by default.
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 This extension continues to use SHA-1 (as in RFC 4366) and does not
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
provide algorithm agility. The property required of SHA-1 in this
case is second pre-image resistance, not collision resistance.
Furthermore, even if second pre-image attacks against SHA-1 are found
in the future, an attack against client_certificate_url would require
a second pre-image that is accepted as a valid certificate by the
server, and contains the same public key.
Also note that HTTP caching proxies are common on the Internet, and
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.
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. This context does not require
extension, it was not believed necessary to use both MD5 and SHA-1 a cryptographic hash function, so the use of SHA-1 is considered
hashes. acceptable, and no algorithm agility is provided.
11.5 Security Considerations for truncated_hmac 11.5 Security Considerations for truncated_hmac
It is possible that truncated MACs are weaker than "un-truncated" It is possible that truncated MACs are weaker than "un-truncated"
MACs. However, no significant weaknesses are currently known or MACs. However, no significant weaknesses are currently known or
expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 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 Note that the output length of a MAC need not be as long as the
length of a symmetric cipher key, since forging of MAC values cannot length of a symmetric cipher key, since forging of MAC values cannot
be done off-line: in TLS, a single failed MAC guess will cause the be done off-line: in TLS, a single failed MAC guess will cause the
skipping to change at page 21, line 44 skipping to change at page 23, line 5
Since the MAC algorithm only takes effect after all handshake Since the MAC algorithm only takes effect after all handshake
messages that affect extension parameters have been authenticated by messages that affect extension parameters have been authenticated by
the hashes in the Finished messages, it is not possible for an active the hashes in the Finished messages, it is not possible for an active
attacker to force negotiation of the truncated HMAC extension where attacker to force negotiation of the truncated HMAC extension where
it would not otherwise be used (to the extent that the handshake it would not otherwise be used (to the extent that the handshake
authentication is secure). Therefore, in the event that any security authentication is secure). Therefore, in the event that any security
problem were found with truncated HMAC in the future, if either the 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 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. problem into account, it would be able to veto use of this extension.
INTERNET-DRAFT TLS Extension Definitions
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 23, line 47 skipping to change at page 24, line 47
May 2008 May 2008
13. Informative References 13. Informative References
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. 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.
[RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366,
INTERNET-DRAFT TLS Extension Definitions
April 2006. April 2006.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
INTERNET-DRAFT TLS Extension Definitions
"Information Systems - Open Systems Interconnection - The Directory: "Information Systems - Open Systems Interconnection - The Directory:
Public key and attribute certificate frameworks." 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 ISO/IEC
9594:8:2001. 9594:8:2001.
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Annex A: pkipath MIME Type Registration Annex A: pkipath MIME Type Registration
skipping to change at page 27, line 23 skipping to change at page 28, line 23
handshake and client and server hellos) as well as specific handshake and client and server hellos) as well as specific
extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The extensions. RFC 4366 was associated with RFC 4346, TLS 1.1. The
client and server Hello extension mechanisms have been moved into RFC client and server Hello extension mechanisms have been moved into RFC
5246, TLS 1.2, so this document, which is associated with RFC 5246, 5246, TLS 1.2, so this document, which is associated with RFC 5246,
includes only the handshake extension mechanisms and the specific includes only the handshake extension mechanisms and the specific
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. It is provided that the ServerNameList can contain
more only one name of any particular name_type.
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.
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
skipping to change at page 29, line 9 skipping to change at page 30, line 9
155 Beaver Street 155 Beaver Street
Milford, MA 01757 USA Milford, MA 01757 USA
Tel: +1-508-634-2066 Tel: +1-508-634-2066
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
INTERNET-DRAFT TLS Extension Definitions INTERNET-DRAFT TLS Extension Definitions
Copyright and IPR Provisions Copyright and IPR Provisions
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
The definitive version of an IETF Document is that published by, or include Simplified BSD License text as described in Section 4.e of
under the auspices of, the IETF. Versions of IETF Documents that are the Trust Legal Provisions and are provided without warranty as
published by third parties, including those that are translated into described in the BSD License. The definitive version of an IETF
other languages, should not be considered to be definitive versions Document is that published by, or under the auspices of, the IETF.
of IETF Documents. The definitive version of these Legal Provisions Versions of IETF Documents that are published by third parties,
is that published by, or under the auspices of, the IETF. Versions of including those that are translated into other languages, should not
these Legal Provisions that are published by third parties, including be considered to be definitive versions of IETF Documents. The
those that are translated into other languages, should not be definitive version of these Legal Provisions is that published by, or
considered to be definitive versions of these Legal Provisions. For under the auspices of, the IETF. Versions of these Legal Provisions
the avoidance of doubt, each Contributor to the IETF Standards that are published by third parties, including those that are
Process licenses each Contribution that he or she makes as part of translated into other languages, should not be considered to be
the IETF Standards Process to the IETF Trust pursuant to the definitive versions of these Legal Provisions. For the avoidance of
provisions of RFC 5378. No language to the contrary, or terms, doubt, each Contributor to the IETF Standards Process licenses each
conditions or rights that differ from or are inconsistent with the Contribution that he or she makes as part of the IETF Standards
rights and licenses granted under RFC 5378, shall have any effect and Process to the IETF Trust pursuant to the provisions of RFC 5378. No
shall be null and void, whether published or posted by such language to the contrary, or terms, conditions or rights that differ
Contributor, or included with or in such Contribution. from or are inconsistent with the rights and licenses granted under
RFC 5378, shall have any effect and shall be null and void, whether
published or posted by such Contributor, or included with or in such
Contribution.
 End of changes. 30 change blocks. 
67 lines changed or deleted 79 lines changed or added

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