idnits 2.17.1 draft-yao-dnsext-alias-algorithm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2010) is 5007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'EDNS0' is defined on line 202, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 214, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 218, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 221, but no explicit reference was found in the text == Unused Reference: 'RFC2672bis' is defined on line 242, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) -- Duplicate reference: RFC2671, mentioned in 'RFC2671', was also mentioned in 'EDNS0'. ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jiankang. Yao 3 Internet-Draft Jian. Jin 4 Intended status: Standards Track Wei. Mao 5 Expires: February 12, 2011 CNNIC 6 August 11, 2010 8 Alias algorithm identifier assignment mechanism for DNSSEC 9 draft-yao-dnsext-alias-algorithm-00.txt 11 Abstract 13 DNS Security Extensions (DNSSEC) has been developed to provide origin 14 authentication and integrity protection for DNS data by using digital 15 signatures. The DNSKEY, RRSIG, and DS RRs use an 8-bit number to 16 identify the security algorithm being used. More and more new 17 RRTYPEs will appear in future. This document defines an alias 18 algorithm identifier assignment method for DNSSEC 8-bit algorithm 19 numbers. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 12, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3. The Alias algorithm identifer assignment . . . . . . . . . . . 3 71 4. Validating the RRSIG for the new RRTYPE . . . . . . . . . . . . 4 72 5. Compatiliable with the old vaildating resolver . . . . . . . . 4 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 76 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 5 77 9.1. draft-yao-dnsext-alias-algorithm: Version 00 . . . . . . . 5 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 The DNS Security Extensions (DNSSEC) [RFC4033], [RFC4034], [RFC4035] 86 and [RFC5155] were developed to provide origin authentication and 87 integrity protection for DNS data by using digital signatures. Every 88 DNSKEY, RRSIG, or DS RR contains an algorithm code number. These 89 algorithm numbers help validators to identify which cryptographic 90 algorithm was used. The algorithm numbers which can be used is 91 within 256. More RRTYPES will appear in future. The new RRTYPE may 92 use the alias algorithm number. In order to prevent the new RRTYPE 93 unaware resolvers from attempting to validate responses from the 94 RRTYPE signed zones, some specification might request to allocates 95 the new DNSKEY alias algorithm identifiers for the current algorithms 96 used. For example Algorithm 6, DSA-NSEC3-SHA1 is an alias for 97 algorithm 3, DSA. This is not a new algorithm, just an additional 98 identifiers for the existing algorithm. The new RRTYPE unaware 99 resolvers will not know these new identifiers and treat responses 100 from the new RRTYPE signed zone as insecure, otherwise the new RRTYPE 101 RR will be regarded as bogus if there is no such a mechanism. Using 102 other alias algorithms for the new RRTYPE requires allocation of a 103 new alias algorithm numbers. Based on the rule of first come first 104 served, the 8-bit algorithm allocation pool would soon be exhausted 105 if more and more new RRTYPEs and algorithms had appeared in the DNS 106 protocols. This document defines an alias algorithm number 107 assignment for the DNSSEC 8-bit algorithm numbers. 109 1.1. Terminology 111 All the basic terms used in this specification are defined in the 112 documents [RFC1034] and [RFC1035]. DNSSEC related terms are defined 113 in [RFC4033], [RFC4034], and [RFC4035] 115 2. Motivation 117 This document tackles the problem that the new RRTYPE requests the 118 alias algorithm number assignment but the algorithm number space is 119 not enough. 121 3. The Alias algorithm identifer assignment 123 Every algorithm identifier that might be used for the new RRTYPE 124 should have the alias identifier. Based on the current algorithm 125 which has been allocated, the follow algorithm should have the alias 126 identifier number: 128 +-------------------+-----------------+-------------------+ 129 | Description | Mnemonic | Original Mnemonic | 130 +-------------------+-----------------+-------------------+ 131 | Diffie-Hellman | alias-dh | DH | 132 | DSA/SHA1 | alias-DSA-SHA1 | DSA/SHA1 | 133 | URSA/SHA-1 | alias-RSASHA1 | RSASHA1 | 134 | RSA/SHA-256 | alias-RSASHA256 | RSASHA256 | 135 | RSA/SHA-512 | alias-RSASHA512 | RSASHA512 | 136 | GOST R 34.10-2001 | alias-ECC-GOST | ECC-GOST | 137 +-------------------+-----------------+-------------------+ 139 Other algorithm's alias identifiers will be assigned in future 140 according to the future requirements. 142 4. Validating the RRSIG for the new RRTYPE 144 The validating resolver following this specification MUST check the 145 type covered of the RRSIG before the verification. Only when the 146 validating resolver knows the RRTYPE, it can begin to verify the 147 signature of the RRSIG. Otherwise, the validating resolver MUST 148 regard the RRSIG in which the type covered is unknown to the resolver 149 as insecure instead of bogus. 151 5. Compatiliable with the old vaildating resolver 153 The old validating resolver deployed will not know the new identifier 154 for the algorithm. Zones signed according to this new specification 155 MUST only use these alias algorithm identifiers for their DNSKEY RRs 156 if there has the new RRTYPE in the zone. The old resolver will treat 157 the RRSIG whose algorithm identifier is unknown to them as insecure, 158 otherwise the RR with the new type will be regarded as bogus if there 159 is no such a mechanism. 161 6. IANA Considerations 163 This document updates the IANA registry "DNS SECURITY ALGORITHM 164 NUMBERS". IANA is requested to assign the algorithm number to the 165 following alias algorithm identifier. 167 +--------+-------------------+-----------------+-------------------+ 168 | Number | Description | Mnemonic | Original Mnemonic | 169 +--------+-------------------+-----------------+-------------------+ 170 | XX1 | Diffie-Hellman | alias-dh | DH | 171 | XX2 | DSA/SHA1 | alias-DSA-SHA1 | DSA/SHA1 | 172 | XX3 | URSA/SHA-1 | alias-RSASHA1 | RSASHA1 | 173 | XX4 | RSA/SHA-256 | alias-RSASHA256 | RSASHA256 | 174 | XX5 | RSA/SHA-512 | alias-RSASHA512 | RSASHA512 | 175 | XX6 | GOST R 34.10-2001 | alias-ECC-GOST | ECC-GOST | 176 +--------+-------------------+-----------------+-------------------+ 178 7. Security Considerations 180 TBD 182 8. Acknowledgements 184 Many ideas are from the discussion in the DNSOP and DNSEXT mailing 185 list. Thanks a lot to all in the list. Many important comments and 186 suggestions are contributed by many members of the DNSEXT and DNSOP 187 WGs. Thanks a lot to the DNS team members of CNNIC such as zhng li 188 kun, han feng and sun guo nian. 190 9. Change History 192 [[anchor9: RFC Editor: Please remove this section.]] 194 9.1. draft-yao-dnsext-alias-algorithm: Version 00 196 o the initial version 198 10. References 200 10.1. Normative References 202 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 203 RFC 2671, August 1999. 205 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 206 STD 13, RFC 1034, November 1987. 208 [RFC1035] Mockapetris, P., "Domain names - implementation and 209 specification", STD 13, RFC 1035, November 1987. 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 215 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 216 RFC 2136, April 1997. 218 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 219 RFC 2671, August 1999. 221 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 222 (RR) Types", RFC 3597, September 2003. 224 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 225 Rose, "DNS Security Introduction and Requirements", 226 RFC 4033, March 2005. 228 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 229 Rose, "Resource Records for the DNS Security Extensions", 230 RFC 4034, March 2005. 232 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 233 Rose, "Protocol Modifications for the DNS Security 234 Extensions", RFC 4035, March 2005. 236 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 237 Security (DNSSEC) Hashed Authenticated Denial of 238 Existence", RFC 5155, March 2008. 240 10.2. Informative References 242 [RFC2672bis] 243 Rose, S. and W. Wijngaards, "Update to DNAME Redirection 244 in the DNS", Internet-Draft ietf-dnsext-rfc2672bis-dname- 245 17.txt, 6 2009. 247 Authors' Addresses 249 Jiankang YAO 250 CNNIC 251 No.4 South 4th Street, Zhongguancun 252 Beijing 254 Phone: +86 10 58813007 255 Email: yaojk@cnnic.cn 256 Jian Jin 257 CNNIC 258 No.4 South 4th Street, Zhongguancun 259 Beijing 261 Phone: +86 10 58813000 262 Email: jinjian@cnnic.cn 264 Wei MAO 265 CNNIC 266 No.4 South 4th Street, Zhongguancun 267 Beijing 269 Phone: +86 10 58812230 270 Email: maowei_ietf@cnnic.cn