idnits 2.17.1 draft-ietf-dnsop-rfc5933-bis-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 : ---------------------------------------------------------------------------- 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 date (12 November 2021) is 889 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Belyavskiy 3 Internet-Draft TCINET 4 Obsoletes: 5933 (if approved) V. Dolmatov, Ed. 5 Updates: 8624 (if approved) JSC "NPK Kryptonite" 6 Intended status: Informational 12 November 2021 7 Expires: 16 May 2022 9 Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource 10 Records for DNSSEC 11 draft-ietf-dnsop-rfc5933-bis-07 13 Abstract 15 This document describes how to produce digital signatures and hash 16 functions using the GOST R 34.10-2012 and GOST R 34.11-2012 17 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the 18 Domain Name System Security Extensions (DNSSEC). 20 This document obsoletes RFC 5933 and updates RFC 8624. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 16 May 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 3 58 2.1. Using a Public Key with Existing Cryptographic 59 Libraries . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 6 70 6.1. Support for GOST Signatures . . . . . . . . . . . . . . . 6 71 7. Changes to RFC 5933 . . . . . . . . . . . . . . . . . . . . . 6 72 8. Update to RFC 8624 . . . . . . . . . . . . . . . . . . . . . 6 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 75 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 12.2. Informative References . . . . . . . . . . . . . . . . . 8 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 R 34.10-2012 ([RFC7091]) and GOST R 34.11-2012 ([RFC6986]), and 94 specifies how to store DNSKEY data and how to produce RRSIG resource 95 records with these algorithms. 97 This document obsoletes RFC5933 [RFC5933]. This document also marks 98 the DNS Security Algorithm GOST R 34.10-2001 as obsolete. 100 Familiarity with DNSSEC and with GOST signature and hash algorithms 101 is assumed in this document. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described in BCP 108 14 [RFC2119] [RFC8174] when, and only when, they appear in all 109 capitals, as shown here. 111 2. DNSKEY Resource Records 113 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. 115 GOST R 34.10-2012 public keys are stored with the algorithm number 116 TBA1. 118 According to RFC 7091 [RFC7091], a public key is a point on the 119 elliptic curve Q = (x,y). The wire representation of a public key 120 MUST contain 64 octets, where the first 32 octets contain the little- 121 endian representation of x and the second 32 octets contain the 122 little-endian representation of y. 124 As RFC 6986 and RFC 7091 allows 2 variants of length of the output 125 hash and signature and many variants of parameters of the digital 126 signature, for the purpose of this document we use 256-bit variant of 127 the digital signature algorithm, corresponding 256-bit variant of the 128 digest algorithm. We select the parameters for the digital signature 129 algorithm to be id-tc26-gost-3410-2012-256-paramSetA in RFC 7836 130 [RFC7836]. 132 2.1. Using a Public Key with Existing Cryptographic Libraries 134 At the time of this writing, existing GOST-aware cryptographic 135 libraries are capable of reading GOST public keys via a generic X509 136 API if the key is encoded according to RFC 7091 [RFC7091], 137 Section 2.3.2. 139 To make this encoding from the wire format of a GOST public key with 140 the parameters used in this document, prepend the 64 octets of key 141 data with the following 32-byte sequence: 143 0x30 0x5e 0x30 0x17 0x06 0x08 0x2a 0x85 0x03 0x07 0x01 0x01 0x01 144 0x01 0x30 0x0b 0x06 0x09 0x2a 0x85 0x03 0x07 0x01 0x02 0x01 0x01 145 0x01 0x03 0x43 0x00 0x04 0x40 147 2.2. GOST DNSKEY RR Example 149 Given a private key with the following value (the value of the 150 Gost12Asn1 field is split here into two lines to simplify reading; in 151 the private key file, it must be in one line): 153 Private-key-format: v1.2 154 Algorithm: 23 (ECC-GOST12) 155 Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCA0 156 zvTDpCSjdRCERkd6WDA2TF/ABQLp9MPZRl7hMXCVGg== 158 The following DNSKEY RR stores a DNS zone key for example: 160 example. 600 IN DNSKEY 256 3 23 ( 161 XkZ6T+qQ9teOMsA/YK+kTzELhuMPTsYggdy2b+sfzJ6t 162 H9eniziMX3gjMnUZIyrnSIchLjup8xpy+UU5l1Eyjw== 163 ) ;{id = 13439 (zsk), size = 512b} 165 3. RRSIG Resource Records 167 The value of the signature field in the RRSIG RR follows RFC 7091 168 [RFC7091] and is calculated as follows. The values for the RDATA 169 fields that precede the signature data are specified in RFC 4034 170 [RFC4034]. 172 hash = GOSTR3411-2012(data) 174 where "data" is the wire format data of the resource record set that 175 is signed, as specified in RFC 4034 [RFC4034]. 177 The signature is calculated from the hash according to the GOST R 178 34.10-2012 standard, and its wire format is compatible with RFC 7091 179 [RFC7091]. 181 3.1. RRSIG RR Example 183 With the private key from this document, consisting of one MX record: 185 example. 600 IN MX 10 mail.example. 187 Setting the inception date to 2020-01-04 17:25:26 UTC and the 188 expiration date to 2020-02-01 17:25:26 UTC, the following signature 189 RR will be valid: 191 example. 600 IN RRSIG MX 23 1 600 20200201172526 ( 192 20200104172526 13439 example. 193 EtrsAEGsNRf12HKjwNTg8U2HZ5JOSo34UaTcshoE1kwd 194 5Ror4I7zltmWAgd4b9OBn80tsajtL0Vuf45u8kEAgA== 195 ) 197 Note: The ECC-GOST12 signature algorithm uses random data, so the 198 actual computed signature value will differ between signature 199 calculations. 201 4. DS Resource Records 203 The GOST R 34.11-2012 digest algorithm is denoted in DS RRs by the 204 digest type TBA2. The wire format of a digest value is compatible 205 with RFC 6986 [RFC6986]. 207 4.1. DS RR Example 209 For Key Signing Key (KSK): 211 example. IN DNSKEY 257 3 23 ( 212 hP3ISWPT8ehEEut8ozbqPcmbTAQK0jce7MHmK0geOiRo 213 kFALGwsMrBf0H0AK2qrVJCWCJL+50v9UNZAS5mE70g== 214 ) ;{id = 7574 (ksk), size = 512b} 216 The DS RR will be: 218 example. IN DS 7574 23 5 ( 219 990f40dc548a4dbcb4b80a0760f194ac 220 0cc18484578834c1ac1f749f70c84103 221 ) 223 5. Deployment Considerations 225 5.1. Key Sizes 227 The key size of GOST public keys conforming to this specification 228 MUST be 512 bits. 230 5.2. Signature Sizes 232 The size of a GOST signature conforming to this specification MUST be 233 512 bits. 235 5.3. Digest Sizes 237 The size of a GOST digest conforming to this specification MUST be 238 256 bits. 240 6. Implementation Considerations 242 6.1. Support for GOST Signatures 244 DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY 245 resource records created with the GOST algorithms as defined in this 246 document. 248 7. Changes to RFC 5933 250 This document specifies the usage of the signature algorithm GOST R 251 34.10-2012 and hash algorithm GOST R 34.11-2012 instead of the 252 signature algorithm GOST R 34.10-2001 and hash algorithm GOST R 253 34.11-94, specified in RFC 5933. 255 8. Update to RFC 8624 257 This document updates RFC8624 [RFC8624]. The paragraph describing 258 the state of GOST algorithms in section 3.1 of RFC 8624 currently 259 says: 261 ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 262 in [RFC7091]. GOST R 34.10-2012 hasn't been standardized for use in 263 DNSSEC. 265 That paragraph is now replaced with the following: 267 ECC-GOST (GOST R 34.10-2001) has been superseded by GOST R 34.10-2012 268 in [RFC7091]. GOST R 34.10-2012 has been standardized for use in 269 DNSSEC in RFC TBC. 271 9. Security Considerations 273 Currently, the cryptographic resistance of the GOST R 34.10-2012 274 digital signature algorithm is estimated as 2**128 operations of 275 multiple elliptic curve point computations on prime modulus of order 276 2**256. 278 Currently, the cryptographic collision resistance of the GOST R 279 34.11-2012 hash algorithm is estimated as 2**128 operations of 280 computations of a step hash function. 282 10. IANA Considerations 284 This document updates the IANA registry "DNS Security Algorithm 285 Numbers". The following entries have been added to the registry: 287 Zone Trans. 288 Value Algorithm Mnemonic Signing Sec. References Status 289 TBA1 GOST R 34.10-2012 ECC-GOST12 Y * RFC TBA OPTIONAL 291 The entry for the Algorithm "GOST R 34.10-2001", number 12 should be 292 updated as such: Description field should be changed to "GOST R 293 34.10-2001 (deprecated, see TBA1" and Zone Signing field should be 294 changed to "N". 296 This document updates the RFC IANA registry "Delegation Signer (DS) 297 Resource Record (RR) Type Digest Algorithms" by adding an entry for 298 the GOST R 34.11-2012 algorithm: 300 Value Algorithm Status 301 TBA2 GOST R 34.11-2012 OPTIONAL 303 The entry for Value 3, GOST R 34.11-94 should be updated to have its 304 Status changed to '-'. 306 This paragraph shoud be removed before the publication of RFC: For 307 the purpose of example computations, the following values were used: 308 TBA1 = 23, TBA2 = 5. 310 11. Acknowledgments 312 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 313 tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], 314 and RFC 5933 [RFC5933] for consistency. The authors of and 315 contributors to these documents are gratefully acknowledged for their 316 hard work. 318 The following people provided additional feedback, text, and valuable 319 assistance: Alexander Venedyukhin, Valery Smyslov, Tim Wicinski. 321 12. References 323 12.1. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, 327 DOI 10.17487/RFC2119, March 1997, 328 . 330 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the 331 Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, 332 May 2001, . 334 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 335 Rose, "DNS Security Introduction and Requirements", 336 RFC 4033, DOI 10.17487/RFC4033, March 2005, 337 . 339 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 340 Rose, "Resource Records for the DNS Security Extensions", 341 RFC 4034, DOI 10.17487/RFC4034, March 2005, 342 . 344 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 345 Rose, "Protocol Modifications for the DNS Security 346 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 347 . 349 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 350 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 351 2013, . 353 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 354 Digital Signature Algorithm", RFC 7091, 355 DOI 10.17487/RFC7091, December 2013, 356 . 358 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 359 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 360 on the Cryptographic Algorithms to Accompany the Usage of 361 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 362 RFC 7836, DOI 10.17487/RFC7836, March 2016, 363 . 365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 367 May 2017, . 369 [RFC8624] Wouters, P. and O. Sury, "Algorithm Implementation 370 Requirements and Usage Guidance for DNSSEC", RFC 8624, 371 DOI 10.17487/RFC8624, June 2019, 372 . 374 12.2. Informative References 376 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 377 (DS) Resource Records (RRs)", RFC 4509, 378 DOI 10.17487/RFC4509, May 2006, 379 . 381 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 382 GOST Signature Algorithms in DNSKEY and RRSIG Resource 383 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 384 2010, . 386 Authors' Addresses 388 Dmitry Belyavskiy 389 TCINET 390 8 marta st 391 Moscow 392 Russian Federation 394 Phone: +7 916 262 5593 395 Email: beldmit@gmail.com 397 Vasily Dolmatov (editor) 398 JSC "NPK Kryptonite" 399 Spartakovskaya sq., 14, bld 2, JSC "NPK Kryptonite" 400 Moscow 401 105082 402 Russian Federation 404 Email: vdolmatov@gmail.com