idnits 2.17.1 draft-ietf-dnsext-dnssec-gost-07.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 06, 2010) is 5159 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. 'GOST3410' -- Possible downref: Non-RFC (?) normative reference: ref. 'GOST3411' ** Downref: Normative reference to an Informational RFC: RFC 4357 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 March 06, 2010 4 Expires: September 06, 2010 6 Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records 7 for DNSSEC 8 draft-ietf-dnsext-dnssec-gost-07 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 September 06 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 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with 43 respect to this document. Code Components extracted from this 44 document must include Simplified BSD License text as described in 45 Section 4.e of the Trust Legal Provisions and are provided without 46 warranty as described in the Simplified BSD License. 48 Abstract 50 This document describes how to produce signature and hash using 51 GOST (R 34.10-2001, R 34.11-94) algorithms foor DNSKEY, RRSIG and DS 52 resource records for use in the Domain Name System Security 53 Extensions (DNSSEC). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Using a public key with existing cryptographic libraries. . 3 60 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 3 61 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 62 3.1 RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . . 4 63 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 66 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 68 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5 70 6.1. Support for GOST signatures . . . . . . . . . . . . . . . . 5 71 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5 72 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7. Security consideration . . . . . . . . . . . . . . . . . . . . . 5 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 The Domain Name System (DNS) is the global hierarchical distributed 84 database for Internet Naming. The DNS has been extended to use 85 cryptographic keys and digital signatures for the verification of the 86 authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 87 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security 88 Extensions, called DNSSEC. 90 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 91 and specifies a list of cryptographic algorithms to use. This 92 document extends that list with the signature and hash algorithms 93 GOST [GOST3410, GOST3411], 94 and specifies how to store DNSKEY data and how to produce 95 RRSIG resource records with these hash algorithms. 97 Familiarity with DNSSEC and GOST signature and hash 98 algorithms is assumed in this document. 100 The term "GOST" is not officially defined, but is usually used to 101 refer to the collection of the Russian cryptographic algorithms 102 GOST R 34.10-2001[DRAFT1], GOST R 34.11-94[DRAFT2], 103 GOST 28147-89[DRAFT3]. 104 Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to 105 the GOST R 34.10-2001 and GOST R 34.11-94 in this document. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 2. DNSKEY Resource Records 113 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. 115 GOST R 34.10-2001 public keys are stored with the algorithm number 116 {TBA1}. 118 The wire format of the public key is compatible with 119 RFC 4491 [RFC4491]: 121 According to [GOST3410], a public key is a point on the elliptic 122 curve Q = (x,y). 124 The wire representation of a public key MUST contain 64 octets, 125 where the first 32 octets contain the little-endian representation 126 of x and the second 32 octets contain the little-endian 127 representation of y. 128 This corresponds to the binary representation of (256||256) 129 from [GOST3410], ch. 5.3. 131 Corresponding public key parameters are those identified by 132 id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357], 133 and the digest parameters are those identified by 134 id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357]. 136 2.1. Using a public key with existing cryptographic libraries 138 Existing GOST-aware cryptographic libraries at the time of this 139 document writing are capable to read GOST public keys via a generic 140 X509 API if the key is encoded according to RFC 4491 [RFC4491], 141 section 2.3.2. 143 To make this encoding from the wire format of a GOST public key 144 with the parameters used in this document, prepend the 64 octets 145 of key data with the following 37-byte sequence: 147 0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 148 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 149 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40 151 2.2. GOST DNSKEY RR Example 153 Given a private key with the following value (the value of GostAsn1 154 field is split here into two lines to simplify reading; in the 155 private key file it must be in one line): 157 Private-key-format: v1.2 158 Algorithm: {TBA1} (ECC-GOST) 159 GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQgp9c 160 t2LQaNS1vMKPLEN9zHYjLPNMIQN6QB9vt3AghZFA= 161 The following DNSKEY RR stores a DNS zone key for example.net 163 example.net. 86400 IN DNSKEY 256 3 {TBA1} ( 164 GtTJjmZKUXV+lHLG/6crB6RCR+EJR51Islpa 165 6FqfT0MUfKhSn1yAo92+LJ0GDssTiAnj0H0I 166 9Jrfial/yyc5Og== 167 ) ; key id = 10805 169 3. RRSIG Resource Records 171 The value of the signature field in the RRSIG RR follows RFC 4490 172 [RFC4490] and is calculated as follows. The values for the RDATA 173 fields that precede the signature data are specified 174 in RFC 4034 [RFC4034]. 176 hash = GOSTR3411(data) 178 where "data" is the wire format data of the resource record set 179 that is signed, as specified in RFC 4034 [RFC4034]. 181 Hash MUST be calculated with GOST R 34.11-94 parameters identified 182 by id-GostR3411-94-CryptoProParamSet [RFC4357]. 184 Signature is calculated from the hash according to the 185 GOST R 34.10-2001 standard and its wire format is compatible with 186 RFC 4490 [RFC4490]. 188 Quoting RFC 4490: 190 "The signature algorithm GOST R 34.10-2001 generates a digital 191 signature in the form of two 256-bit numbers, r and s. Its octet 192 string representation consists of 64 octets, where the first 32 193 octets contain the big-endian representation of s and the second 32 194 octets contain the big-endian representation of r." 196 3.1. RRSIG RR Example 198 With the private key from section 2.2 sign the following RRSet, 199 consisting of one A record: 201 www.example.net. 3600 IN A 192.0.2.1 203 Setting the inception date to 2000-01-01 00:00:00 UTC and the 204 expiration date to 2030-01-01 00:00:00 UTC, the following signature 205 should be created (assuming {TBA1}==249 until proper code is 206 assigned by IANA) 208 www.example.net. 3600 IN RRSIG A {TBA1} 3 3600 20300101000000 ( 209 20000101000000 10805 example.net. 210 k3m0r5bm6kFQmcRlHshY3jIj7KL6KTUsPIAp 211 Vy466khKuWEUoVvSkqI+9tvMQySQgZcEmS0W 212 HRFSm0XS5YST5g== ) 213 Note: Several ECC-GOST signatures calculated for the same message text 214 will differ because of using of a random element is used in signature 215 generation process. 217 4. DS Resource Records 219 GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest 220 type {TBA2}.The wire format of a digest value is compatible with 221 RFC4490 [RFC4490], that is digest is in little-endian representation. 223 The digest MUST always be calculated with GOST R 34.11-94 parameters 224 identified by id-GostR3411-94-CryptoProParamSet [RFC4357]. 226 4.1. DS RR Example 228 For key signing key (assuming {TBA1}==249 until proper code is 229 assigned by IANA) 231 example.net. 86400 DNSKEY 257 3 {TBA1} ( 232 1aYdqrVz3JJXEURLMdmeI7H1CyTFfPVFBIGA 233 EabZFP+7NT5KPYXzjDkRbPWleEFbBilDNQNi 234 q/q4CwA4WR+ovg== 235 ) ; key id = 6204 237 The DS RR will be 239 example.net. 3600 IN DS 6204 {TBA1} {TBA2} ( 240 0E6D6CB303F89DBCF614DA6E21984F7A62D08BDD0A05B3A22CC63D1B 241 553BC61E ) 243 5. Deployment Considerations 245 5.1. Key Sizes 247 According to RFC4357 [RFC4357], the key size of GOST public keys 248 MUST be 512 bits. 250 5.2. Signature Sizes 252 According to the GOST signature algorithm specification [GOST3410], 253 the size of a GOST signature is 512 bits. 255 5.3. Digest Sizes 257 According to the GOST R 34.11-94 [GOST3411], the size of a GOST 258 digest is 256 bits. 260 6. Implementation Considerations 262 6.1. Support for GOST signatures 264 DNSSEC aware implementations MAY be able to support RRSIG and 265 DNSKEY resource records created with the GOST algorithms as 266 defined in this document. 268 6.2. Support for NSEC3 Denial of Existence 270 Any DNSSEC-GOST implementation MUST support both NSEC[RFC4035] and 271 NSEC3 [RFC5155] 273 6.3 Byte order 275 Due to the fact that all existing industry implementations of GOST 276 cryptographic libraries are returning GOST blobs without 277 transformation from little-endian format and in order to avoid the 278 necessity for DNSSEC developers to handle different cryptographic 279 algorithms differently, it was chosen to send these blobs on the 280 wire "as is" without transformation of endianness. 282 7. Security considerations 284 Currently, the cryptographic resistance of the GOST 34.10-2001 285 digital signature algorithm is estimated as 2**128 operations 286 of multiple elliptic curve point computations on prime modulus 287 of order 2**256. 289 Currently, the cryptographic resistance of GOST 34.11-94 hash 290 algorithm is estimated as 2**128 operations of computations of a 291 step hash function. (There is known method to reduce this 292 estimate to 2**105 operations, but it demands padding the 293 colliding message with 1024 random bit blocks each of 256 bit 294 length, thus it cannot be used in any practical implementation). 296 8. IANA Considerations 298 This document updates the IANA registry "DNS Security Algorithm 299 Numbers" [RFC4034] 300 (http://www.iana.org/assignments/dns-sec-alg-numbers). 301 The following entries are added to the registry: 302 Zone Trans. 303 Value Algorithm Mnemonic Signing Sec. References Status 304 {TBA1} GOST R 34.10-2001 ECC-GOST Y * (this memo) OPTIONAL 306 This document updates the RFC 4034 Digest Types assignment 307 (section A.2)by adding the value and status for the GOST R 34.11-94 308 algorithm: 310 Value Algorithm Status 311 {TBA2} GOST R 34.11-94 OPTIONAL 313 9. Acknowledgments 315 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 316 tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], 317 and RFC 4357 [RFC4357] for consistency. The authors of and 318 contributors to these documents are gratefully acknowledged for 319 their hard work. 321 The following people provided additional feedback and text: Dmitry 322 Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen 323 and Wouter Wijngaards. 325 10. References 327 10.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", RFC 2119, March 1997. 332 [RFC3110] Eastlake D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain 333 Name System (DNS)", RFC 3110, May 2001. 335 [RFC4033] Arends R., Austein R., Larson M., Massey D., and S. 336 Rose, "DNS Security Introduction and Requirements", 337 RFC 4033, March 2005. 339 [RFC4034] Arends R., Austein R., Larson M., Massey D., and S. 340 Rose, "Resource Records for the DNS Security Extensions", 341 RFC 4034, March 2005. 343 [RFC4035] Arends R., Austein R., Larson M., Massey D., and S. 344 Rose, "Protocol Modifications for the DNS Security 345 Extensions", RFC 4035, March 2005. 347 [GOST3410] "Information technology. Cryptographic data security. 348 Signature and verification processes of [electronic] 349 digital signature.", GOST R 34.10-2001, Gosudarstvennyi 350 Standard of Russian Federation, Government Committee of 351 the Russia for Standards, 2001. (In Russian) 353 [GOST3411] "Information technology. Cryptographic Data Security. 354 Hashing function.", GOST R 34.11-94, Gosudarstvennyi 355 Standard of Russian Federation, Government Committee of 356 the Russia for Standards, 1994. (In Russian) 358 [RFC4357] Popov V., Kurepkin I., and S. Leontiev, "Additional 359 Cryptographic Algorithms for Use with GOST 28147-89, 360 GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 361 Algorithms", RFC 4357, January 2006. 363 [RFC4490] S. Leontiev and G. Chudov, "Using the GOST 28147-89, 364 GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 365 Algorithms with Cryptographic Message Syntax (CMS)", 366 RFC 4490, May 2006. 368 [RFC4491] S. Leontiev and D. Shefanovski, "Using the GOST 369 R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 370 Algorithms with the Internet X.509 Public Key 371 Infrastructure Certificate and CRL Profile", RFC 4491, 372 May 2006. 374 [RFC5155] B. Laurie, G. Sisson, R. Arends and D. Blacka, "DNS 375 Security (DNSSEC) Hashed Authenticated Denial of 376 Existence", RFC 5155, February 2008. 378 10.2. Informative References 380 [RFC4509] Hardaker W., "Use of SHA-256 in DNSSEC Delegation Signer 381 (DS) Resource Records (RRs)", RFC 4509, May 2006. 383 [DRAFT1] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., 384 "GOST R 34.10-2001 digital signature algorithm" 385 draft-dolmatov-cryptocom-gost34102001-08, 12.12.09 386 work in progress. 388 [DRAFT2] Dolmatov V., Kabelev D., Ustinov I., Vyshensky S., 389 "GOST R 34.11-94 Hash function algorithm" 390 draft-dolmatov-cryptocom-gost341194-07, 12.12.09 391 work in progress. 393 [DRAFT3] Dolmatov V., Kabelev D., Ustinov I., Emelyanova I., 394 "GOST 28147-89 encryption, decryption and MAC algorithms" 395 draft-dolmatov-cryptocom-gost2814789-08, 12.12.09 396 work in progress. 398 Authors' Addresses 400 Vasily Dolmatov, Ed. 401 Cryptocom Ltd. 402 Kedrova 14, bld.2 403 Moscow, 117218, Russian Federation 405 EMail: dol@cryptocom.ru 407 Artem Chuprina 408 Cryptocom Ltd. 409 Kedrova 14, bld.2 410 Moscow, 117218, Russian Federation 412 EMail: ran@cryptocom.ru 414 Igor Ustinov 415 Cryptocom Ltd. 416 Kedrova 14, bld.2 417 Moscow, 117218, Russian Federation 419 EMail: igus@cryptocom.ru