idnits 2.17.1 draft-hoffman-dnssec-dsa-sha2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 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 (July 6, 2009) is 5401 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186-3' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Standards Track July 6, 2009 5 Expires: January 7, 2010 7 DSA with SHA-2 for DNSSEC 8 draft-hoffman-dnssec-dsa-sha2-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 7, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document describes how to specify DSA keys and signatures based 57 on SHA-256 with a specific set of parameters in DNSSEC. The keys 58 used are 2048 bits, and have an equivalent security level of 112 59 bits. 61 1. Introduction 63 DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 64 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and 65 digital signatures to provide authentication of DNS data. Currently, 66 the most popular signature algorithm is RSA with SHA-1, using keys 67 1024 or 2048 bits long. The RSA with SHA-256 signature algorithm (as 68 specified in [RSASHA256]) with keys of 1024 to 2048 bits is expected 69 to become popular in the coming years. 71 RFC 2536 [RFC2536] describes the KEY and SIG resource records (RRs) 72 for the DSA with SHA-1 signature algorithm. At the time RFC 2536 was 73 written, SHA-1 was the only hash algorithm that was defined for use 74 with DSA, and the only key size allowed was 1024 bits. FIPS 186-3 75 ([FIPS-186-3]) extends the original DSA definition to permit larger 76 keys. This document neither updates nor replaces RFC 2536. 78 Using DSA with SHA-256 in DNSSEC has some advantages and 79 disadvantages relative to using RSA with SHA-256 when using 2048-bit 80 keys. DSA signatures are much shorter than RSA signatures; at this 81 size, the difference is 512 bits verus 2048 bits. On typical 82 platforms using 2048-bit keys, signing DSA is about three times 83 faster than for RSA, but verifying RSA signatures is more than ten 84 times faster than for DSA. 86 This document specifies the DNSKEY and RRSIG RRs for DSA when used 87 with the SHA-256 hash algorithm for a specific set of DSA parameters 88 from RFC 5114 [RFC5114]. 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 2. DSA Parameters 96 In order for a DSA signature to be validated, the validator needs to 97 know the DSA parameters that were used. The three parameters are 98 called "p", "q", and "g" in FIPS 186-3. FIPS 186-3 calls the private 99 key "x" and the public key "y"; the per-signature secret value is 100 called "k". 102 In some cryptographic protocols, the signer picks their own 103 parameters and transmits them with the signature. However, because 104 of their size, this is often wasteful of bandwidth and storage. 105 Other cryptographic protocols pick well-known parameters that are 106 used by everyone, and the only thing that is passed is an indicator 107 of which parameter set is used. 109 Because DNS messages should be kept short, this document chooses the 110 latter method. The parameters are chosen following the methods 111 described in FIPS 186-3. The size of the parameters is based on the 112 desired strength of the signatures. This document uses DSA with SHA- 113 256 and a 2048-bit y, the public key. Thus, p is 2048 bits, q is 256 114 bits, and g is 2048 bits long. 116 The values used in this document are from RFC 5114, section 2.3. In 117 hexadecimal, they are: 119 p = 87A8E61D B4B6663C FFBBD19C 65195999 8CEEF608 660DD0F2 120 5D2CEED4 435E3B00 E00DF8F1 D61957D4 FAF7DF45 61B2AA30 121 16C3D911 34096FAA 3BF4296D 830E9A7C 209E0C64 97517ABD 122 5A8A9D30 6BCF67ED 91F9E672 5B4758C0 22E0B1EF 4275BF7B 123 6C5BFC11 D45F9088 B941F54E B1E59BB8 BC39A0BF 12307F5C 124 4FDB70C5 81B23F76 B63ACAE1 CAA6B790 2D525267 35488A0E 125 F13C6D9A 51BFA4AB 3AD83477 96524D8E F6A167B5 A41825D9 126 67E144E5 14056425 1CCACB83 E6B486F6 B3CA3F79 71506026 127 C0B857F6 89962856 DED4010A BD0BE621 C3A3960A 54E710C3 128 75F26375 D7014103 A4B54330 C198AF12 6116D227 6E11715F 129 693877FA D7EF09CA DB094AE9 1E1A1597 131 q = 8CF83642 A709A097 B4479976 40129DA2 99B1A47D 1EB3750B 132 A308B0FE 64F5FBD3 134 g = 3FB32C9B 73134D0B 2E775066 60EDBD48 4CA7B18F 21EF2054 135 07F4793A 1A0BA125 10DBC150 77BE463F FF4FED4A AC0BB555 136 BE3A6C1B 0C6B47B1 BC3773BF 7E8C6F62 901228F8 C28CBB18 137 A55AE313 41000A65 0196F931 C77A57F2 DDF463E5 E9EC144B 138 777DE62A AAB8A862 8AC376D2 82D6ED38 64E67982 428EBC83 139 1D14348F 6F2F9193 B5045AF2 767164E1 DFC967C1 FB3F2E55 140 A4BD1BFF E83B9C80 D052B985 D182EA0A DB2A3B73 13D3FE14 141 C8484B1E 052588B9 B7D2BBD2 DF016199 ECD06E15 57CD0915 142 B3353BBB 64E0EC37 7FD02837 0DF92B52 C7891428 CDC67EB6 143 184B523D 1DB246C3 2F630784 90F00EF8 D647D148 D4795451 144 5E2327CF EF98C582 664B4C0F 6CC41659 146 3. DNSKEY and RRSIG Resource Records for DSA with SHA-256 148 The DSA signature is the combination of two non-negative integers, 149 called "r" and "s" in FIPS 186-3. Because q was chosen to be the 150 same size as the output of SHA-256 (256 bits), r and s are each 256 151 bits. The two integers, each of which is formatted as a simple bit 152 string, are combined into a single longer bit string for DNSSEC as 153 the concatenation "r | s". 155 The algorithm number associated with the DNSKEY and RRSIG resource 156 records for DSA with SHA-256 and the parameters in this document is 157 {TBA}; it is fully defined in the IANA Considerations section. The 158 associated DS RR for SHA-256 is already defined in RFC 4509 159 [RFC4509]. 161 4. Support for NSEC3 Denial of Existence 163 RFC 5155 [RFC5155] defines new algorithm identifiers for existing 164 signing algorithms, to indicate that zones signed with these 165 algorithm identifiers can use NSEC3 as well as NSEC records to 166 provide denial of existence. That mechanism was chosen to protect 167 implementations predating RFC 5155 from encountering resource records 168 they could not know about. This document does not define such 169 algorithm aliases. 171 A DNSSEC validator that implements the signing algorithm defined in 172 this document MUST be able to validate negative answers in the form 173 of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. 174 An authoritative server that does not implement NSEC3 MAY still serve 175 zones that use the signing algorithm defined in this document with 176 NSEC denial of existence. 178 5. Examples 180 [[ To be filled in later. ]] 182 6. IANA Considerations 184 This document updates the IANA registry "Domain Name System Security 185 (DNSSEC) Algorithm Numbers". The following entry is added to the 186 registry: 188 Number {TBA} 189 Description DSA with SHA-256 using parameters from RFC 5114, 190 section 2.3 191 Mnemonic DSA2048SHA256 192 Zone Signing Y 193 Trans. Sec. **** Unknown; will fill in later **** 194 Reference This document 196 7. Security Considerations 198 The cryptographic strength of DSA is generally considered to be 199 equivalent to RSA when the DSA public key and the RSA public keys are 200 the same size. Such an assessment could, of course, change in the 201 future if new attacks that work better with one or the other 202 algorithms are found. 204 There are currently no known attacks on the specific set of DSA 205 parameters chosen for this document. Such an assessment could, of 206 course, change in the future. 208 8. References 209 8.1. Normative References 211 [FIPS-186-3] 212 National Institute of Standards and Technology, U.S. 213 Department of Commerce, "Digital Signature Standard", 214 FIPS 186-3, June 2009. 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, March 1997. 219 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 220 Rose, "DNS Security Introduction and Requirements", 221 RFC 4033, March 2005. 223 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 224 Rose, "Resource Records for the DNS Security Extensions", 225 RFC 4034, March 2005. 227 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 228 Rose, "Protocol Modifications for the DNS Security 229 Extensions", RFC 4035, March 2005. 231 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 232 (DS) Resource Records (RRs)", RFC 4509, May 2006. 234 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 235 Security (DNSSEC) Hashed Authenticated Denial of 236 Existence", RFC 5155, March 2008. 238 [RSASHA256] 239 Jansen, J., "Use of SHA-2 algorithms with RSA in DNSKEY 240 and RRSIG Resource Records for DNSSEC", RFC-to-be derived 241 from draft-ietf-dnsext-dnssec-rsasha256, March 2009. 243 8.2. Informative References 245 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 246 (DNS)", RFC 2536, March 1999. 248 [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman 249 Groups for Use with IETF Standards", RFC 5114, 250 January 2008. 252 Author's Address 254 Paul Hoffman 255 VPN Consortium 257 Email: paul.hoffman@vpnc.org