draft-ietf-tls-dnssec-chain-extension-01.txt   draft-ietf-tls-dnssec-chain-extension-02.txt 
TLS M. Shore TLS M. Shore
Internet-Draft No Mountain Software Internet-Draft No Mountain Software
Intended status: Standards Track R. Barnes Intended status: Standards Track R. Barnes
Expires: January 8, 2017 Mozilla Expires: July 15, 2017 Mozilla
S. Huque S. Huque
Verisign Labs Verisign Labs
W. Toorop W. Toorop
NLNet Labs NLNet Labs
July 7, 2016 January 11, 2017
A DANE Record and DNSSEC Authentication Chain Extension for TLS A DANE Record and DNSSEC Authentication Chain Extension for TLS
draft-ietf-tls-dnssec-chain-extension-01 draft-ietf-tls-dnssec-chain-extension-02
Abstract Abstract
This draft describes a new TLS extension for transport of a DNS This draft describes a new TLS extension for transport of a DNS
record set serialized with the DNSSEC signatures needed to record set serialized with the DNSSEC signatures needed to
authenticate that record set. The intent of this proposal is to authenticate that record set. The intent of this proposal is to
allow TLS clients to perform DANE authentication of a TLS server allow TLS clients to perform DANE authentication of a TLS server
certificate without needing to perform additional DNS record lookups. certificate without needing to perform additional DNS record lookups.
It will typically not be used for general DNSSEC validation of TLS It will typically not be used for general DNSSEC validation of TLS
endpoint names. endpoint names.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 8, 2017. This Internet-Draft will expire on July 15, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3 3. DNSSEC Authentication Chain Extension . . . . . . . . . . . . 3
3.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol, TLS 1.2 . . . . . . . . . . . . . . . . . . . . 4
3.2. DNSSEC Authentication Chain Data . . . . . . . . . . . . 4 3.2. Protocol, TLS 1.3 . . . . . . . . . . . . . . . . . . . . 4
4. Construction of Serialized Authentication Chains . . . . . . 7 3.3. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . 4
5. Caching and Regeneration of the Authentication Chain . . . . 7 3.4. DNSSEC Authentication Chain Data . . . . . . . . . . . . 5
6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Construction of Serialized Authentication Chains . . . . . . 8
7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 8 5. Caching and Regeneration of the Authentication Chain . . . . 8
8. Mandating use of this extension . . . . . . . . . . . . . . . 8 6. Verification . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Trust Anchor Maintenance . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Mandating use of this extension . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
12.2. Informative References . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Updates from -00 . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 10
Appendix B. Test vector . . . . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Updates from -01 . . . . . . . . . . . . . . . . . . 13
Appendix B. Updates from -00 . . . . . . . . . . . . . . . . . . 13
Appendix C. Test vector . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Requirements Notation 1. Requirements Notation
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].
2. Introduction 2. Introduction
This draft describes a new TLS [RFC5246] extension for transport of a This draft describes a new TLS [RFC5246] extension for transport of a
skipping to change at page 3, line 38 skipping to change at page 3, line 42
anchor. anchor.
This specification is based on Adam Langley's original proposal for This specification is based on Adam Langley's original proposal for
serializing DNSSEC authentication chains and delivering them in an serializing DNSSEC authentication chains and delivering them in an
X.509 certificate extension [I-D.agl-dane-serializechain]. It X.509 certificate extension [I-D.agl-dane-serializechain]. It
modifies the approach by using wire format DNS records in the modifies the approach by using wire format DNS records in the
serialized data (assuming that the data will be prepared and consumed serialized data (assuming that the data will be prepared and consumed
by a DNS-specific library), and by using a TLS extension to deliver by a DNS-specific library), and by using a TLS extension to deliver
the data. the data.
3. DNSSEC Authentication Chain Extension As described in the DANE specification [RFC6698], this procuedure
applies to the DANE authentication of X.509 certificates. Other
credentials may be supported, as needed, in the future.
3.1. Protocol 3. DNSSEC Authentication Chain Extension
3.1. Protocol, TLS 1.2
A client MAY include an extension of type "dnssec_chain" in the A client MAY include an extension of type "dnssec_chain" in the
(extended) ClientHello. The "extension_data" field of this extension (extended) ClientHello. The "extension_data" field of this extension
MUST be empty. MUST be empty.
Servers receiving a "dnssec_chain" extension in the client hello, and Servers receiving a "dnssec_chain" extension in the client hello, and
which are capable of being authenticated via DANE, MAY return a which are capable of being authenticated via DANE, MAY return a
serialized authentication chain in the extended ServerHello message, serialized authentication chain in the extended ServerHello message,
using the format described below. If a server is unable to return an using the format described below. If a server is unable to return an
authentication chain, or does not wish to return an authentication authentication chain, or does not wish to return an authentication
chain, it does not include a dnssec_chain extension. As with all TLS chain, it does not include a dnssec_chain extension. As with all TLS
extensions, if the server does not support this extension it will not extensions, if the server does not support this extension it will not
return any authentication chain. return any authentication chain.
A client must not be able to force a server to perform lookups on A client must not be able to force a server to perform lookups on
arbitrary domain names using this mechanism. Therefore, a server arbitrary domain names using this mechanism. Therefore, a server
MUST NOT construct chains for domain names other than its own. MUST NOT construct chains for domain names other than its own.
3.2. DNSSEC Authentication Chain Data 3.2. Protocol, TLS 1.3
A client MAY include an extension of type "dnssec_chain" in the
ClientHello. The "extension_data" field of this extension MUST be
empty.
Servers receiving a "dnssec_chain" extension in the client hello, and
which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the Certificate message, using the
format described below. The authentication chain will be an
extension to the certificate_list to which the certificate being
authenticated belongs.
The extension protocol behavior otherwise follows that specified for
TLS version 1.2.
3.3. Raw Public Keys
[RFC7250] specifies the use of raw public keys for both server and
client authentication in TLS 1.2. It points out that in cases where
raw public keys are being used, code for certificate path validation
is not required. However, DANE provides a mechanism for securely
binding a raw public key to a named entity in the DNS, and when using
DANE for authentication a raw key may be validated using a path
chaining back to a DNSSEC trust root. This has the added benefit of
mitigating an unknown key share attack, as described in
[I-D.barnes-dane-uks].
The mechanism for encoding DNSSEC authentication chains in a TLS
extension, as described in this document, is not limited to public
keys encapsulated in PKIX or X.509 containers but MAY be applied to
raw public keys and other representations, as well.
3.4. DNSSEC Authentication Chain Data
The "extension_data" field of the "dnssec_chain" extension MUST The "extension_data" field of the "dnssec_chain" extension MUST
contain a DNSSEC Authentication Chain encoded in the following form: contain a DNSSEC Authentication Chain encoded in the following form:
opaque AuthenticationChain<0..2^16-1> opaque AuthenticationChain<0..2^16-1>
The AuthenticationChain structure is composed of a sequence of The AuthenticationChain structure is composed of a sequence of
uncompressed wire format DNS resource record sets (RRset) and uncompressed wire format DNS resource record sets (RRset) and
corresponding signatures (RRsig) records. The record sets and corresponding signatures (RRsig) records. The record sets and
signatures are presented in validation order, starting at the target signatures are presented in the order returned by the DNS server
DANE record, followed by the DNSKEY and DS record sets for each queried by the TLS server, although they MAY be returned in
intervening DNS zone up to a trust anchor chosen by the server, validation order, starting at the target DANE record, followed by the
typically the DNS root. DNSKEY and DS record sets for each intervening DNS zone up to a trust
anchor chosen by the server, typically the DNS root.
This sequence of native DNS wire format records enables easier This sequence of native DNS wire format records enables easier
generation of the data structure on the server and easier generation of the data structure on the server and easier
verification of the data on client by means of existing DNS library verification of the data on client by means of existing DNS library
functions. However this document describes the data structure in functions. However this document describes the data structure in
sufficient detail that implementers if they desire can write their sufficient detail that implementers if they desire can write their
own code to do this. own code to do this.
Each RRset in the chain is composed of a sequence of wire format DNS Each RRset in the chain is composed of a sequence of wire format DNS
resource records. The format of the resource record is described in resource records. The format of the resource record is described in
RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be
presented in the canonical form and ordering as described in RFC 4034 presented in the canonical form and ordering as described in RFC 4034
[RFC4034]. [RFC4034].
RR(i) = owner | type | class | TTL | RDATA length | RDATA RR(i) = owner | type | class | TTL | RDATA length | RDATA
RRs within the RRset are ordered canonically, by treating the RDATA RRs within the RRset MAY be ordered canonically, by treating the
portion of each RR as a left-justified unsigned octet sequence in RDATA portion of each RR as a left-justified unsigned octet sequence
which the absence of an octet sorts before a zero octet. in which the absence of an octet sorts before a zero octet.
The RRsig record is in DNS wire format as described in RFC 4034 The RRsig record is in DNS wire format as described in RFC 4034
[RFC4034], Section 3.1. The signature portion of the RDATA, as [RFC4034], Section 3.1. The signature portion of the RDATA, as
described in the same section, is the following: described in the same section, is the following:
signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )
where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with where, RRSIG_RDATA is the wire format of the RRSIG RDATA fields with
the Signer's Name field in canonical form and the signature field the Signer's Name field in canonical form and the signature field
excluded. excluded.
skipping to change at page 7, line 44 skipping to change at page 8, line 44
The components of the authentication chain are built by starting at The components of the authentication chain are built by starting at
the target record set and its corresponding RRSIG. Then traversing the target record set and its corresponding RRSIG. Then traversing
the DNS tree upwards towards the trust anchor zone (normally the DNS the DNS tree upwards towards the trust anchor zone (normally the DNS
root), for each zone cut, the DNSKEY and DS RRsets and their root), for each zone cut, the DNSKEY and DS RRsets and their
signatures are added. If DNS responses messages contain any domain signatures are added. If DNS responses messages contain any domain
names utilizing name compression [RFC1035], then they must be names utilizing name compression [RFC1035], then they must be
uncompressed. uncompressed.
In the future, proposed DNS protocol enhancements, such as the EDNS In the future, proposed DNS protocol enhancements, such as the EDNS
Chain Query extension [I-D.ietf-dnsop-edns-client-subnet] may offer Chain Query extension [RFC7901] may offer easy ways to obtain all of
easy ways to obtain all of the chain data in one transaction with an the chain data in one transaction with an upstream DNSSEC aware
upstream DNSSEC aware recursive server. recursive server.
5. Caching and Regeneration of the Authentication Chain 5. Caching and Regeneration of the Authentication Chain
DNS records have Time To Live (TTL) parameters, and DNSSEC signatures DNS records have Time To Live (TTL) parameters, and DNSSEC signatures
have validity periods (specifically signature expiration times). have validity periods (specifically signature expiration times).
After the TLS server constructs the serialized authentication chain, After the TLS server constructs the serialized authentication chain,
it SHOULD cache and reuse it in multiple TLS connection handshakes. it SHOULD cache and reuse it in multiple TLS connection handshakes.
However, it MUST refresh and rebuild the chain as TTLs and signature However, it MUST refresh and rebuild the chain as TTLs and signature
validity periods dictate. A server implementation could carefully validity periods dictate. A server implementation could carefully
track these parameters and requery component records in the chain track these parameters and requery component records in the chain
skipping to change at page 9, line 46 skipping to change at page 10, line 46
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <http://www.rfc-editor.org/info/rfc4035>.
[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, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, DOI Extensions: Extension Definitions", RFC 6066,
10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS) [RFC7633] Hallam-Baker, P., "X.509v3 Transport Layer Security (TLS)
Feature Extension", RFC 7633, DOI 10.17487/RFC7633, Feature Extension", RFC 7633, DOI 10.17487/RFC7633,
October 2015, <http://www.rfc-editor.org/info/rfc7633>. October 2015, <http://www.rfc-editor.org/info/rfc7633>.
skipping to change at page 11, line 5 skipping to change at page 12, line 5
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>. <http://www.rfc-editor.org/info/rfc5905>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <http://www.rfc-editor.org/info/rfc7120>. 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via [RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via
Opportunistic DNS-Based Authentication of Named Entities Opportunistic DNS-Based Authentication of Named Entities
(DANE) Transport Layer Security (TLS)", RFC 7672, DOI (DANE) Transport Layer Security (TLS)", RFC 7672,
10.17487/RFC7672, October 2015, DOI 10.17487/RFC7672, October 2015,
<http://www.rfc-editor.org/info/rfc7672>. <http://www.rfc-editor.org/info/rfc7672>.
[RFC7901] Wouters, P., "CHAIN Query Requests in DNS", RFC 7901,
DOI 10.17487/RFC7901, June 2016,
<http://www.rfc-editor.org/info/rfc7901>.
[I-D.agl-dane-serializechain] [I-D.agl-dane-serializechain]
Langley, A., "Serializing DNS Records with DNSSEC Langley, A., "Serializing DNS Records with DNSSEC
Authentication", draft-agl-dane-serializechain-01 (work in Authentication", draft-agl-dane-serializechain-01 (work in
progress), July 2011. progress), July 2011.
[I-D.ietf-dnsop-edns-client-subnet] [I-D.barnes-dane-uks]
Contavalli, C., Gaast, W., tale, t., and W. Kumari, Barnes, R., Thomson, M., and E. Rescorla, "Unknown Key-
"Client Subnet in DNS Queries", draft-ietf-dnsop-edns- Share Attacks on DNS-based Authentications of Named
client-subnet-07 (work in progress), March 2016. Entities (DANE)", draft-barnes-dane-uks-00 (work in
progress), October 2016.
Appendix A. Updates from -00 Appendix A. Updates from -01
o Added TLS 1.3 support
o Added section describing applicability to raw public keys
o Softened language about record order
Appendix B. Updates from -00
o Edits based on comments from Rick van Rein o Edits based on comments from Rick van Rein
o Warning about not overloading X.509 wildcards on DNSSEC wildcards o Warning about not overloading X.509 wildcards on DNSSEC wildcards
(from V. Dukhovny) (from V. Dukhovny)
o Added MUST include negative proof on wildcards (from V. Dukhovny) o Added MUST include negative proof on wildcards (from V. Dukhovny)
o Removed "TODO" on allowing the server to deliver only one o Removed "TODO" on allowing the server to deliver only one
signature per RRset signature per RRset
o Added additional minor edits suggested by Viktor Dukhovny o Added additional minor edits suggested by Viktor Dukhovny
Appendix B. Test vector Appendix C. Test vector
[data go here] [data go here]
Authors' Addresses Authors' Addresses
Melinda Shore Melinda Shore
No Mountain Software No Mountain Software
EMail: melinda.shore@nomountain.net EMail: melinda.shore@nomountain.net
 End of changes. 21 change blocks. 
47 lines changed or deleted 107 lines changed or added

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