draft-ietf-dnsext-dnssec-rsasha256-01.txt | draft-ietf-dnsext-dnssec-rsasha256-02.txt | |||
---|---|---|---|---|
DNS Extensions working group J. Jansen | DNS Extensions working group J. Jansen | |||
Internet-Draft NLnet Labs | Internet-Draft NLnet Labs | |||
Expires: July 5, 2006 January 2006 | Expires: June 13, 2008 December 11, 2007 | |||
Use of RSA/SHA-256 DNSKEY and RRSIG Resource Records in DNSSEC | Use of SHA-2 algorithms with RSA in DNSKEY and RRSIG Resource Records | |||
draft-ietf-dnsext-dnssec-rsasha256-01 | for DNSSEC | |||
draft-ietf-dnsext-dnssec-rsasha256-02 | ||||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
skipping to change at page 1, line 33 | skipping to change at page 1, line 34 | |||
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/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
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. | |||
This Internet-Draft will expire on July 5, 2006. | This Internet-Draft will expire on June 13, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
This document describes how to produce RSA/SHA-256 DNSKEY and RRSIG | This document describes how to produce RSA/SHA-256 and RSA/SHA-512 | |||
resource records for use in the Domain Name System Security | DNSKEY and RRSIG resource records for use in the Domain Name System | |||
Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). | Security Extensions (DNSSEC, RFC4033, RFC4034, and RFC4035). | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . . 3 | 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 | |||
3. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . . . 3 | 2.1. RSA/SHA-256 DNSKEY Resource Records . . . . . . . . . . . . 3 | |||
4. Implementation Considerations . . . . . . . . . . . . . . . . 4 | 2.2. RSA/SHA-512 DNSKEY Resource Records . . . . . . . . . . . . 3 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 | |||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | 3.1. RSA/SHA-256 RRSIG Resource Records . . . . . . . . . . . . 4 | |||
6.1 SHA-1 versus SHA-256 Considerations for RRSIG resource | 3.2. RSA/SHA-512 RRSIG Resource Records . . . . . . . . . . . . 4 | |||
records . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 4. Implementation Considerations . . . . . . . . . . . . . . . . . 5 | |||
6.2 Signature Type Downgrade Attacks . . . . . . . . . . . . . 5 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource | |||
8.1 Normative References . . . . . . . . . . . . . . . . . . . 5 | records . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
8.2 Informative References . . . . . . . . . . . . . . . . . . 6 | 6.2. Signature Type Downgrade Attacks . . . . . . . . . . . . . 6 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
Intellectual Property and Copyright Statements . . . . . . . . 7 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | ||||
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 8 | ||||
1. Introduction | 1. Introduction | |||
The Domain Name System (DNS) is the global hierarchical distributed | The Domain Name System (DNS) is the global hierarchical distributed | |||
database for Internet Addressing. The DNS has been extended to use | database for Internet Addressing. The DNS has been extended to use | |||
digital signatures and cryptographic keys for the verification of | cryptographic keys and digital signatures for the verification of the | |||
data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] describe these DNS | integrity of its data. RFC4033 [1], RFC4034 [2], and RFC4035 [3] | |||
Security Extensions. | describe these DNS Security Extensions, called DNSSEC. | |||
RFC4034 describes how to store DNSKEY and RRSIG resource records, and | RFC4034 describes how to store DNSKEY and RRSIG resource records, and | |||
specifies a list of cryptographic algorithms to use. This document | specifies a list of cryptographic algorithms to use. This document | |||
extends that list with the algorithm RSA/SHA-256, and specifies how | extends that list with the algorithm RSA/SHA-256 and RSA/SHA-512, and | |||
to store RSA/SHA-256 DNSKEY data and how to produce RSA/SHA-256 RRSIG | specifies how to store DNSKEY data and how to produce RRSIG resource | |||
resource records. | records with these hash algorithms. | |||
Familiarity with the RSA [7] and SHA-256 [5] algorithms is assumed in | Familiarity with DNSSEC, RSA [7] and the SHA-2 [5] family of | |||
this document. | algorithms is assumed in this document. | |||
2. RSA/SHA-256 DNSKEY Resource Records | To refer to both SHA-256 and SHA-512, this document will use the name | |||
SHA-2. This is done to improve readability. When a part of text is | ||||
specific for either SHA-256 or SHA-512, their specific names are | ||||
used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be | ||||
grouped using the name RSA/SHA-2. | ||||
RSA public keys for use with RSA/SHA-256 are stored in DNSKEY | 2. DNSKEY Resource Records | |||
resource records (RRs) with the algorithm number [TBA]. | ||||
The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 | The format of the DNSKEY RR can be found in RFC4034 [2] and RFC3110 | |||
[6]. | [6]. | |||
3. RSA/SHA-256 RRSIG Resource Records | 2.1. RSA/SHA-256 DNSKEY Resource Records | |||
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource | RSA public keys for use with RSA/SHA-256 are stored in DNSKEY | |||
records (RRs) with algorithm number [TBA]. | resource records (RRs) with the algorithm number [TBA]. | |||
For use with NSEC3, the algorithm number of RSA/SHA-256 will be | ||||
[TBA]. | ||||
2.2. RSA/SHA-512 DNSKEY Resource Records | ||||
RSA public keys for use with RSA/SHA-512 are stored in DNSKEY | ||||
resource records (RRs) with the algorithm number [TBA]. | ||||
For use with NSEC3, the algorithm number of RSA/SHA-512 will be | ||||
[TBA]. | ||||
3. RRSIG Resource Records | ||||
The value of the signature field in the RRSIG RR is calculated as | The value of the signature field in the RRSIG RR is calculated as | |||
follows. The values for the fields that precede the signature data | follows. The values for the fields that precede the signature data | |||
are specified in RFC4034 [2]. | are specified in RFC4034 [2]. | |||
hash = SHA-256(data) | hash = SHA-XXX(data) | |||
Where XXX is either 256 or 512, depending on the algorithm used. | ||||
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n) | |||
Where SHA-256 is the message digest algorithm as specified in FIPS | Where SHA-XXX is the message digest algorithm as specified in FIPS | |||
180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of | 180 [5], | is concatenation, 00, 01, FF and 00 are fixed octets of | |||
corresponding hexadecimal value, "e" is the private exponent of the | corresponding hexadecimal value, "e" is the private exponent of the | |||
signing RSA key, and "n" is the public modulus of the signing key. | signing RSA key, and "n" is the public modulus of the signing key. | |||
The FF octet MUST be repeated the maximum number of times so that the | The FF octet MUST be repeated the maximum number of times so that the | |||
total length of the signature equals the length of the modulus of the | total length of the signature equals the length of the modulus of the | |||
signer's public key ("n"). "data" is the data of the resource record | signer's public key ("n"). "data" is the data of the resource record | |||
set that is signed, as specified in RFC4034 [2]. | set that is signed, as specified in RFC4034 [2]. | |||
The prefix should make the use of standard cryptographic libraries | ||||
easier. These specifications are taken directly from PKCS #1 v2.1 | ||||
section 9.2 [4]. The prefixes for the different algorithms are | ||||
specified below. | ||||
3.1. RSA/SHA-256 RRSIG Resource Records | ||||
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource | ||||
records (RRs) with algorithm number [TBA]. | ||||
The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as | The prefix is the ASN.1 BER SHA-256 algorithm designator prefix as | |||
specified in PKCS 2.1 [4]: | specified in PKCS 2.1 [4]: | |||
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 | hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 | |||
This prefix should make the use of standard cryptographic libraries | 3.2. RSA/SHA-512 RRSIG Resource Records | |||
easier. These specifications are taken directly from PKCS #1 v2.1 | ||||
section 9.2 [4]. | RSA/SHA-512 signatures are stored in the DNS using RRSIG resource | |||
records (RRs) with algorithm number [TBA]. | ||||
The prefix is the ASN.1 BER SHA-512 algorithm designator prefix as | ||||
specified in PKCS 2.1 [4]: | ||||
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40 | ||||
4. Implementation Considerations | 4. Implementation Considerations | |||
DNSSEC aware implementations MUST be able to support RRSIG resource | DNSSEC aware implementations SHOULD be able to support RRSIG resource | |||
records with the RSA/SHA-256 algorithm. | records with the RSA/SHA-2 algorithms. | |||
If both RSA/SHA-256 and RSA/SHA-1 RRSIG resource records are | If both RSA/SHA-2 and RSA/SHA-1 RRSIG resource records are available | |||
available for a certain rrset, with a secure path to their keys, the | for a certain rrset, with a secure path to their keys, the validator | |||
validator SHOULD ignore the SHA-1 signature. If the RSA/SHA-256 | SHOULD ignore the SHA-1 signature. If the RSA/SHA-2 signature does | |||
signature does not verify the data, and the RSA/SHA-1 does, the | not verify the data, and the RSA/SHA-1 signature does, the validator | |||
validator SHOULD mark the data with the security status from the RSA/ | SHOULD mark the data with the security status from the RSA/SHA-2 | |||
SHA-256 signature. | signature. | |||
5. IANA Considerations | 5. IANA Considerations | |||
IANA has not yet assigned an algorithm number for RSA/SHA-256. | IANA has not yet assigned an algorithm number for RSA/SHA-256 and | |||
RSA/SHA-512. | ||||
The algorithm list from RFC4034 Appendix A.1 [2] is extended with the | The algorithm list from RFC4034 Appendix A.1 [2] is extended with the | |||
following entry: | following entries: | |||
Zone | Zone | |||
Value Algorithm [Mnemonic] Signing References Status | Value Algorithm [Mnemonic] Signing References Status | |||
----- ----------- ----------- -------- ---------- --------- | ----- ----------- ----------- ------- ---------- -------- | |||
[tba] RSA/SHA-256 [RSASHA256] y [TBA] MANDATORY | [TBA] RSA/SHA-256 [RSASHA256] y [TBA] OPTIONAL | |||
[TBA] RSA/SHA-256-NSEC3 [RSASHA256NSEC3] y [TBA] OPTIONAL | ||||
[TBA] RSA/SHA-512 [RSASHA512] y [TBA] OPTIONAL | ||||
[TBA] RSA/SHA-512-NSEC3 [RSASHA512NSEC3] y [TBA] OPTIONAL | ||||
6. Security Considerations | 6. Security Considerations | |||
6.1 SHA-1 versus SHA-256 Considerations for RRSIG resource records | 6.1. SHA-1 versus SHA-2 Considerations for RRSIG resource records | |||
Users of DNSSEC are encouraged to deploy SHA-256 as soon as software | Users of DNSSEC are encouraged to deploy SHA-2 as soon as software | |||
implementations allow for it. SHA-256 is widely believed to be more | implementations allow for it. SHA-2 is widely believed to be more | |||
resilient to attack than SHA-1, and confidence in SHA-1's strength is | resilient to attack than SHA-1, and confidence in SHA-1's strength is | |||
being eroded by recently-announced attacks. Regardless of whether or | being eroded by recently-announced attacks. Regardless of whether or | |||
not the attacks on SHA-1 will affect DNSSEC, it is believed (at the | not the attacks on SHA-1 will affect DNSSEC, it is believed (at the | |||
time of this writing) that SHA-256 is the better choice for use in DS | time of this writing) that SHA-2 is the better choice for use in | |||
records. | DNSSEC records. | |||
SHA-256 is considered sufficiently strong for the immediate future, | SHA-2 is considered sufficiently strong for the immediate future, but | |||
but predictions about future development in cryptography and | predictions about future development in cryptography and | |||
cryptanalysis are beyond the scope of this document. | cryptanalysis are beyond the scope of this document. | |||
6.2 Signature Type Downgrade Attacks | 6.2. Signature Type Downgrade Attacks | |||
Since each RRset MUST be signed with each algorithm present in the | Since each RRset MUST be signed with each algorithm present in the | |||
DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious | DNSKEY RRset at the zone apex (see [3] Section 2.2), a malicious | |||
party cannot filter out the RSA/SHA256 RRSIG, and force the validator | party cannot filter out the RSA/SHA-2 RRSIG, and force the validator | |||
to use the RSA/SHA1 signature if both are present in the zone. | to use the RSA/SHA-1 signature if both are present in the zone. | |||
Together with the implementation considerations from Section 4 of | Together with the implementation considerations from Section 4 of | |||
this document, this provides resilience against algorithm downgrade | this document, this provides resilience against algorithm downgrade | |||
attacks, if the validator supports RSA/SHA256. | attacks, if the validator supports RSA/SHA-2. | |||
7. Acknowledgments | 7. Acknowledgments | |||
This document is a minor extension to RFC4034 [2]. Also, we try to | This document is a minor extension to RFC4034 [2]. Also, we try to | |||
follow the documents RFC3110 [6] and draft-ietf-dnsext-ds-sha256.txt | follow the documents RFC3110 [6] and RFC4509 [8] for consistency. | |||
[8] for consistency. The authors of and contributors to these | The authors of and contributors to these documents are gratefully | |||
documents are gratefully acknowledged for their hard work. | acknowledged for their hard work. | |||
The following people provided additional feedback and text: Jaap | The following people provided additional feedback and text: Jaap | |||
Akkerhuis, Rob Austein, Miek Gieben and Wouter Wijngaards. | Akkerhuis, Rob Austein, Miek Gieben, Scott Rose and Wouter | |||
Wijngaards. | ||||
8. References | 8. References | |||
8.1 Normative References | 8.1. Normative References | |||
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||
"DNS Security Introduction and Requirements", RFC 4033, | "DNS Security Introduction and Requirements", RFC 4033, | |||
March 2005. | March 2005. | |||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||
"Resource Records for the DNS Security Extensions", RFC 4034, | "Resource Records for the DNS Security Extensions", RFC 4034, | |||
March 2005. | March 2005. | |||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, | |||
skipping to change at page 6, line 5 | skipping to change at page 7, line 5 | |||
[4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards | [4] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards | |||
(PKCS) #1: RSA Cryptography Specifications Version 2.1", | (PKCS) #1: RSA Cryptography Specifications Version 2.1", | |||
RFC 3447, February 2003. | RFC 3447, February 2003. | |||
[5] National Institute of Standards and Technology, "Secure Hash | [5] National Institute of Standards and Technology, "Secure Hash | |||
Standard", FIPS PUB 180-2, August 2002. | Standard", FIPS PUB 180-2, August 2002. | |||
[6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name | [6] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name | |||
System (DNS)", RFC 3110, May 2001. | System (DNS)", RFC 3110, May 2001. | |||
8.2 Informative References | 8.2. Informative References | |||
[7] Schneier, B., "Applied Cryptography Second Edition: protocols, | [7] Schneier, B., "Applied Cryptography Second Edition: protocols, | |||
algorithms, and source code in C", Wiley and Sons , ISBN 0-471- | algorithms, and source code in C", Wiley and Sons , ISBN 0-471- | |||
11709-9, 1996. | 11709-9, 1996. | |||
[8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) | [8] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) | |||
Resource Records (RRs)", Work in Progress Feb 2006. | Resource Records (RRs)", RFC 4509, May 2006. | |||
Author's Address | Author's Address | |||
Jelte Jansen | Jelte Jansen | |||
NLnet Labs | NLnet Labs | |||
Kruislaan 419 | Kruislaan 419 | |||
Amsterdam 1098VA | Amsterdam 1098VA | |||
NL | NL | |||
Email: jelte@NLnetLabs.nl | Email: jelte@NLnetLabs.nl | |||
URI: http://www.nlnetlabs.nl/ | URI: http://www.nlnetlabs.nl/ | |||
Intellectual Property Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | ||||
This document is subject to the rights, licenses and restrictions | ||||
contained in BCP 78, and except as set forth therein, the authors | ||||
retain all their rights. | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND | ||||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | ||||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | ||||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Intellectual Property | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
Intellectual Property Rights or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; nor does it represent that it has | might or might not be available; nor does it represent that it has | |||
made any independent effort to identify any such rights. Information | made any independent effort to identify any such rights. Information | |||
on the procedures with respect to rights in RFC documents can be | on the procedures with respect to rights in RFC documents can be | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 7, line 29 | skipping to change at page 8, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
Disclaimer of Validity | ||||
This document and the information contained herein are provided on an | ||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Copyright Statement | ||||
Copyright (C) The Internet Society (2006). This document is subject | ||||
to the rights, licenses and restrictions contained in BCP 78, and | ||||
except as set forth therein, the authors retain all their rights. | ||||
Acknowledgment | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 37 change blocks. | ||||
88 lines changed or deleted | 132 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |