idnits 2.17.1 draft-dolmatov-dnsext-dnssec-gost-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 05, 2009) is 5371 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) == Missing Reference: 'GOSTR341001' is mentioned on line 123, but not defined == Unused Reference: 'NIST800-57' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'RFC3447' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'DRAFT1' is defined on line 316, but no explicit reference was found in the text == Unused Reference: 'DRAFT2' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'DRAFT3' is defined on line 325, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3410' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3411' ** Downref: Normative reference to an Informational RFC: RFC 4357 -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- No information found for draft-dolmatov-cryptocom-gost3410-2001 - is the name correct? == Outdated reference: A later version (-07) exists of draft-dolmatov-cryptocom-gost341194-01 == Outdated reference: A later version (-08) exists of draft-dolmatov-cryptocom-gost2814789-01 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNS Extensions working group V.Dolmatov, Ed. 2 Internet-Draft Cryptocom Ltd. 3 Intended status: Standards Track August 05, 2009 4 Expires: Febuary 05, 2010 6 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records 7 for DNSSEC 8 draft-dolmatov-dnsext-dnssec-gost-01 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. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on February 05 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes how to produce GOST signature and hash algorithms 47 DNSKEY and RRSIG resource records for use in the Domain Name System 48 Security Extensions (DNSSEC, RFC 4033, RFC 4034, and RFC 4035). 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Using a public key with existing cryptographic libraries. . 3 55 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3 56 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 3 57 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 59 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 4 61 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Implementation Considerations . . . . . . . . . . . . . . . . . 4 63 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 4 64 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 4 65 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 4 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 67 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 5 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 The Domain Name System (DNS) is the global hierarchical distributed 76 database for Internet Naming. The DNS has been extended to use 77 cryptographic keys and digital signatures for the verification of the 78 authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 79 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security 80 Extensions, called DNSSEC. 82 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 83 and specifies a list of cryptographic algorithms to use. This 84 document extends that list with the signature and hash algorithms 85 GOST [GOST3410, GOST3411], 86 and specifies how to store DNSKEY data and how to produce 87 RRSIG resource records with these hash algorithms. 89 Familiarity with DNSSEC and GOST signature and hash 90 algorithms is assumed in this document. 92 The term "GOST" is not officially defined, but is usually used to 93 refer to the collection of the Russian cryptographic algorithms 94 GOST R 34.10-2001, GOST R 34.11-94, GOST 28147-89. Since GOST 28147-89 95 is not used in DNSSEC, GOST will only refer to GOST R 34.10-2001 96 (signatire algorithm) and GOST R 34.11-94 (hash algorithm) in this 97 document. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. DNSKEY Resource Records 105 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. 107 GOST R 34.10-2001 public keys are stored with the algorithm number {TBA1}. 109 The public key parameters are those identified by 110 id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357]. 111 The digest parameters for signature are those identified by 112 id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. 114 The wire format of the public key is compatible with RFC 4491 [RFC4491]: 116 According to [GOSTR341001], a public key is a point on the elliptic 117 curve Q = (x,y). 119 The wire representation of a public key MUST contain 64 octets, where the 120 first 32 octets contain the little-endian representation of x and the 121 second 32 octets contain the little-endian representation of y. This 122 corresponds to the binary representation of (256||256) from 123 [GOSTR341001], ch. 5.3. 125 2.1. Using a public key with existing cryptographic libraries 127 Existing GOST-aware cryptographic libraries at time of this document 128 writing are capable to read GOST public keys via generic X509 API if the 129 key is encoded according to RFC 4491 [RFC4491], section 2.3.2. 131 To make this encoding from the wire format of a GOST public key, prepend 132 a key data with the following 37-byte sequence: 134 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12 135 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03 136 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40 138 2.2. GOST DNSKEY RR Example 140 The following DNSKEY RR stores a DNS zone key for example.com 142 example.com. 86400 IN DNSKEY 256 3 {TBA1} ( RamuUwTG1r4RUqsgXu/xF6B+Y 143 tJLzZEykiZ4C2Fa1gV1pI/8GA 144 el2Wm69Cz5h1T9eYAQKFAGwzW 145 m4Lke0E26aw== ) 147 3. RRSIG Resource Records 149 The value of the signature field in the RRSIG RR follows the RFC 4490 150 [RFC4490] and is calculated as follows. The values for the RDATA fields 151 that precede the signature data are specified in RFC 4034 [RFC4034]. 153 hash = GOSTR3411(data) 155 where "data" is the wire format data of the resource record set that is 156 signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated with 157 GOST R 34.11-94 parameters identified by 158 id-GostR3411-94-CryptoProParamSet [RFC4357]. 160 Signature is calculated from the hash according to the GOST R 34.10-2001 161 standard and its wire format is compatible with RFC 4490 [RFC4490]. 162 Quoting RFC 4490: 164 "The signature algorithm GOST R 34.10-2001 generates a digital 165 signature in the form of two 256-bit numbers, r and s. Its octet 166 string representation consists of 64 octets, where the first 32 167 octets contain the big-endian representation of s and the second 32 168 octets contain the big-endian representation of r." 170 4. DS Resource Records 172 GOST R 34.11-94 digest algorithm is denoted in DS RR by the digest type 173 {TBA2}. The wire format of a digest value is compatible with RFC 4490 174 [RFC4490]. Quoting RFC 4490: 176 "A 32-byte digest in little-endian representation." 178 The digest MUST always be calculated with GOST R 34.11-94 parameters 179 identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. 181 5. Deployment Considerations 183 5.1. Key Sizes 185 According to RFC4357 [RFC4357] key size of GOST public keys MUST 186 be 512 bits. 188 5.2. Signature Sizes 190 According to GOST signature algorithm [GOST3410] size of GOST signature 191 is 512 bit. 193 5.3. Digest Sizes 195 According to GOST R 34.11-94 [GOST3411] size of GOST digest is 256 bit. 197 6. Implementation Considerations 199 6.1. Support for GOST signatures 201 DNSSEC aware implementations SHOULD be able to support RRSIG and 202 DNSKEY resource records created with the GOST algorithms as 203 defined in this document. 205 6.2. Support for NSEC3 Denial of Existence 207 NSEC3 support is not described in this document. 209 7. Security considerations 211 Current cryptographic resistance of GOST 34.10-2001 digital signature 212 algorithm is estimated as 2**128 operations of elliptic curve point 213 computations on simple modulus 2**256. 214 Current cryptographic resistance of GOST 34.11-94 hash algorithm is 215 estimated as 2**128 operations of copmutations of step hash function. 216 (There is known method to reduce this estimate to 2**105 operations, 217 but it demands padding the colliding message with 1024 random bit 218 blocks each of 256 bit length, thus it cannot be used in any 219 practical implementation). 221 8. IANA Considerations 223 This document updates the IANA registry "DNS SECURITY ALGORITHM 224 NUMBERS -- per [RFC4035] " 225 (http://www.iana.org/assignments/dns-sec-alg-numbers). The following 226 entries are added to the registry: 227 Zone Trans. 228 Value Algorithm Mnemonic Signing Sec. References Status 229 {TBA1} GOST R 34.10-2001 GOST Y * (this memo) OPTIONAL 231 This document updates the RFC 4034 [RFC4034] Digest Types assignment 232 (RFC 4034, section A.2): 234 Value Algorithm Status 235 {TBA2} GOST R 34.11-94 OPTIONAL 237 9. Acknowledgments 239 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 240 try to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509] 241 and RFC 4357 [RFC4357] for consistency. The authors of and 242 contributors to these documents are gratefully acknowledged for 243 their hard work. 245 The following people provided additional feedback and text: Dmitry 246 Burkov, Jaap Akkerhuis, Olafur Gundmundsson,Jelte Jansen 247 and Wouter Wijngaards. 249 10. References 251 10.1. Normative References 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", RFC 2119, March 1997. 256 [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 257 Name System (DNS)", RFC 3110, May 2001. 259 [RFC4033] Arends R., Austein R., Larson M., Massey D., and S. 260 Rose, "DNS Security Introduction and Requirements", 261 RFC 4033, March 2005. 263 [RFC4034] Arends R., Austein R., Larson M., Massey D., and S. 264 Rose, "Resource Records for the DNS Security Extensions", 265 RFC 4034, March 2005. 267 [RFC4035] Arends R., Austein R., Larson M., Massey D., and S. 268 Rose, "Protocol Modifications for the DNS Security 269 Extensions", RFC 4035, March 2005. 271 [GOST3410] "Information technology. Cryptographic data security. 272 Signature and verification processes of [electronic] 273 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 274 Standard of Russian Federation, Government Committee of 275 the Russia for Standards, 2001. (In Russian) 277 [GOST3411] "Information technology. Cryptographic Data Security. 278 Hashing function.", GOST R 34.11-94, Gosudarstvennyi 279 Standard of Russian Federation, Government Committee of 280 the Russia for Standards, 1994. (In Russian) 282 [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional 283 Cryptographic Algorithms for Use with GOST 28147-89, 284 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 285 Algorithms", RFC 4357, January 2006. 287 [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 288 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 289 Algorithms with Cryptographic Message Syntax (CMS)", 290 RFC 4490, May 2006. 292 [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 293 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 294 Algorithms with the Internet X.509 Public Key 295 Infrastructure Certificate and CRL Profile", RFC 4491, 296 May 2006. 298 10.2. Informative References 300 [NIST800-57] 301 Barker E., Barker W., Burr W., Polk W., and M. Smid, 302 "Recommendations for Key Management", NIST SP 800-57, 303 March 2007. 305 [RFC3447] Jonsson J. and B. Kaliski, "Public-Key Cryptography 306 Standards (PKCS) #1: RSA Cryptography Specifications 307 Version 2.1", RFC 3447, February 2003. 309 [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer 310 (DS) Resource Records (RRs)", RFC 4509, May 2006. 312 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 313 Security (DNSSEC) Hashed Authenticated Denial of 314 Existence", RFC 5155, March 2008. 316 [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., 317 "GOST R 34.10-2001 digital signature algorithm" 318 draft-dolmatov-cryptocom-gost3410-2001-02, 319 work in progress 321 [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., 322 "GOST R 34.11-94 Hash function algorithm" 323 draft-dolmatov-cryptocom-gost341194-01, work in progress 325 [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., 326 "GOST 28147-89 encryption, decryption and MAC algorithms" 327 draft-dolmatov-cryptocom-gost2814789-01, work in progress 329 Authors' Addresses 331 Vasily Dolmatov, Ed. 332 Cryptocom Ltd. 333 Bolotnikovskaya, 23 334 Moscow, 117303, Russian Federation 336 EMail: dol@cryptocom.ru 338 Artem Chuprina 339 Cryptocom Ltd. 340 Bolotnikovskaya, 23 341 Moscow, 117303, Russian Federation 343 EMail: ran@cryptocom.ru 345 Igor Ustinov 346 Cryptocom Ltd. 347 Bolotnikovskaya, 23 348 Moscow, 117303, Russian Federation 350 EMail: igus@cryptocom.ru