idnits 2.17.1 draft-ietf-dnsop-rfc5933-bis-02.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 draft header indicates that this document obsoletes RFC5933, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2020) is 1306 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) ** Downref: Normative reference to an Informational RFC: RFC 6986 ** Downref: Normative reference to an Informational RFC: RFC 7091 ** Downref: Normative reference to an Informational RFC: RFC 7836 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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 Intended status: Standards Track JSC "NPK Kryptonite" 6 Expires: April 1, 2021 September 28, 2020 8 Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource 9 Records for DNSSEC 10 draft-ietf-dnsop-rfc5933-bis-02 12 Abstract 14 This document describes how to produce digital signatures and hash 15 functions using the GOST R 34.10-2012 and GOST R 34.11-2012 16 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the 17 Domain Name System Security Extensions (DNSSEC). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 1, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . 3 56 2.1. Using a Public Key with Existing Cryptographic Libraries 3 57 2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . 4 58 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . 4 59 3.1. RRSIG RR Example . . . . . . . . . . . . . . . . . . . . 4 60 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. DS RR Example . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5 63 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . 5 65 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 67 6.1. Support for GOST Signatures . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 10.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The Domain Name System (DNS) is the global hierarchical distributed 79 database for Internet Naming. The DNS has been extended to use 80 cryptographic keys and digital signatures for the verification of the 81 authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034 82 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security 83 Extensions, called DNSSEC. 85 RFC 4034 describes how to store DNSKEY and RRSIG resource records, 86 and specifies a list of cryptographic algorithms to use. This 87 document extends that list with the signature and hash algorithms 88 GOST R 34.10-2012 ([RFC7091]) and GOST R 34.11-2012 ([RFC6986]), and 89 specifies how to store DNSKEY data and how to produce RRSIG resource 90 records with these algorithms. 92 This document obsoletes RFC5933 [RFC5933]. This document also marks 93 the DNS Security Algorithm GOST R 34.10-2001 as obsolete. 95 Familiarity with DNSSEC and with GOST signature and hash algorithms 96 is assumed in this document. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. DNSKEY Resource Records 108 The format of the DNSKEY RR can be found in RFC 4034 [RFC4034]. 110 GOST R 34.10-2012 public keys are stored with the algorithm number 111 TBA1. 113 According to RFC 7091 [RFC7091], a public key is a point on the 114 elliptic curve Q = (x,y). The wire representation of a public key 115 MUST contain 64 octets, where the first 32 octets contain the little- 116 endian representation of x and the second 32 octets contain the 117 little-endian representation of y. 119 As RFC 6986 and RFC 7091 allows 2 variants of length of the output 120 hash and signature and many variants of parameters of the digital 121 signature, for the purpose of this document we use 256-bit variant of 122 the digital signature algorithm, corresponding 256-bit variant of the 123 digest algorithm. We select the parameters for the digital signature 124 algorithm to be id-tc26-gost-3410-2012-256-paramSetA in RFC 7836 125 [RFC7836]. 127 2.1. Using a Public Key with Existing Cryptographic Libraries 129 At the time of this writing, existing GOST-aware cryptographic 130 libraries are capable of reading GOST public keys via a generic X509 131 API if the key is encoded according to RFC 7091 [RFC7091], 132 Section 2.3.2. 134 To make this encoding from the wire format of a GOST public key with 135 the parameters used in this document, prepend the 64 octets of key 136 data with the following 32-byte sequence: 138 0x30 0x5e 0x30 0x17 0x06 0x08 0x2a 0x85 0x03 0x07 0x01 0x01 0x01 139 0x01 0x30 0x0b 0x06 0x09 0x2a 0x85 0x03 0x07 0x01 0x02 0x01 0x01 140 0x01 0x03 0x43 0x00 0x04 0x40 142 2.2. GOST DNSKEY RR Example 144 Given a private key with the following value (the value of the 145 Gost12Asn1 field is split here into two lines to simplify reading; in 146 the private key file, it must be in one line): 148 Private-key-format: v1.2 149 Algorithm: 23 (ECC-GOST12) 150 Gost12Asn1: MD4CAQAwFwYIKoUDBwEBAQEwCwYJKoUDBwECAQEBBCA0 151 zvTDpCSjdRCERkd6WDA2TF/ABQLp9MPZRl7hMXCVGg== 153 The following DNSKEY RR stores a DNS zone key for example: 155 example. 600 IN DNSKEY 256 3 23 ( 156 XkZ6T+qQ9teOMsA/YK+kTzELhuMPTsYggdy2b+sfzJ6t 157 H9eniziMX3gjMnUZIyrnSIchLjup8xpy+UU5l1Eyjw== 158 ) ;{id = 13439 (zsk), size = 512b} 160 3. RRSIG Resource Records 162 The value of the signature field in the RRSIG RR follows RFC 7091 163 [RFC7091] and is calculated as follows. The values for the RDATA 164 fields that precede the signature data are specified in RFC 4034 165 [RFC4034]. 167 hash = GOSTR3411-2012(data) 169 where "data" is the wire format data of the resource record set that 170 is signed, as specified in RFC 4034 [RFC4034]. 172 The signature is calculated from the hash according to the GOST R 173 34.10-2012 standard, and its wire format is compatible with RFC 7091 174 [RFC7091]. 176 3.1. RRSIG RR Example 178 With the private key from this document, consisting of one MX record: 180 example. 600 IN MX 10 mail.example. 182 Setting the inception date to 2020-01-04 17:25:26 UTC and the 183 expiration date to 2020-02-01 17:25:26 UTC, the following signature 184 RR will be valid: 186 example. 600 IN RRSIG MX 23 1 600 20200201172526 ( 187 20200104172526 13439 example. 188 EtrsAEGsNRf12HKjwNTg8U2HZ5JOSo34UaTcshoE1kwd 189 5Ror4I7zltmWAgd4b9OBn80tsajtL0Vuf45u8kEAgA== 190 ) 192 Note: The ECC-GOST12 signature algorithm uses random data, so the 193 actual computed signature value will differ between signature 194 calculations. 196 4. DS Resource Records 198 The GOST R 34.11-2012 digest algorithm is denoted in DS RRs by the 199 digest type TBA2. The wire format of a digest value is compatible 200 with RFC 6986 [RFC6986]. 202 4.1. DS RR Example 204 For Key Signing Key (KSK): 206 example. IN DNSKEY 257 3 23 ( 207 hP3ISWPT8ehEEut8ozbqPcmbTAQK0jce7MHmK0geOiRo 208 kFALGwsMrBf0H0AK2qrVJCWCJL+50v9UNZAS5mE70g== 209 ) ;{id = 7574 (ksk), size = 512b} 211 The DS RR will be: 213 example. IN DS 7574 23 5 ( 214 990f40dc548a4dbcb4b80a0760f194ac 215 0cc18484578834c1ac1f749f70c84103 216 ) 218 5. Deployment Considerations 220 5.1. Key Sizes 222 The key size of GOST public keys conforming to this specification 223 MUST be 512 bits. 225 5.2. Signature Sizes 227 The size of a GOST signature conforming to this specification MUST be 228 512 bits. 230 5.3. Digest Sizes 232 The size of a GOST digest conforming to this specification MUST be 233 256 bits. 235 6. Implementation Considerations 237 6.1. Support for GOST Signatures 239 DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY 240 resource records created with the GOST algorithms as defined in this 241 document. 243 7. Security Considerations 245 Currently, the cryptographic resistance of the GOST R 34.10-2012 246 digital signature algorithm is estimated as 2**128 operations of 247 multiple elliptic curve point computations on prime modulus of order 248 2**256. 250 Currently, the cryptographic collision resistance of the GOST R 251 34.11-2012 hash algorithm is estimated as 2**128 operations of 252 computations of a step hash function. 254 8. IANA Considerations 256 This document updates the IANA registry "DNS Security Algorithm 257 Numbers". The following entries have been added to the registry: 259 Zone Trans. 260 Value Algorithm Mnemonic Signing Sec. References Status 261 TBA1 GOST R 34.10-2012 ECC-GOST12 Y * RFC TBA OPTIONAL 263 The entry for the Algorithm "GOST R 34.10-2001", number 12 should be 264 updated as such: Description field should be changed to "GOST R 265 34.10-2001 (deprecated, see TBA1" and Zone Signing field should be 266 changed to "N". 268 This document updates the RFC IANA registry "Delegation Signer (DS) 269 Resource Record (RR) Type Digest Algorithms" by adding an entry for 270 the GOST R 34.11-2012 algorithm: 272 Value Algorithm Status 273 TBA2 GOST R 34.11-2012 OPTIONAL 275 The entry for Value 3, GOST R 34.11-94 should be updated to have its 276 Status changed to '-'. 278 This paragraph shoud be removed before the publication of RFC: For 279 the purpose of example computations, the following values were used: 280 TBA1 = 23, TBA2 = 5. 282 9. Acknowledgments 284 This document is a minor extension to RFC 4034 [RFC4034]. Also, we 285 tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], 286 and RFC 5933 [RFC5933] for consistency. The authors of and 287 contributors to these documents are gratefully acknowledged for their 288 hard work. 290 The following people provided additional feedback, text, and valuable 291 assistance: Alexander Venedyukhin, Valery Smyslov, Tim Wicinski, TODO 293 10. References 295 10.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the 303 Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, 304 May 2001, . 306 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 307 Rose, "DNS Security Introduction and Requirements", 308 RFC 4033, DOI 10.17487/RFC4033, March 2005, 309 . 311 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 312 Rose, "Resource Records for the DNS Security Extensions", 313 RFC 4034, DOI 10.17487/RFC4034, March 2005, 314 . 316 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 317 Rose, "Protocol Modifications for the DNS Security 318 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 319 . 321 [RFC6986] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.11-2012: 322 Hash Function", RFC 6986, DOI 10.17487/RFC6986, August 323 2013, . 325 [RFC7091] Dolmatov, V., Ed. and A. Degtyarev, "GOST R 34.10-2012: 326 Digital Signature Algorithm", RFC 7091, 327 DOI 10.17487/RFC7091, December 2013, 328 . 330 [RFC7836] Smyshlyaev, S., Ed., Alekseev, E., Oshkin, I., Popov, V., 331 Leontiev, S., Podobaev, V., and D. Belyavsky, "Guidelines 332 on the Cryptographic Algorithms to Accompany the Usage of 333 Standards GOST R 34.10-2012 and GOST R 34.11-2012", 334 RFC 7836, DOI 10.17487/RFC7836, March 2016, 335 . 337 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 338 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 339 May 2017, . 341 10.2. Informative References 343 [RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer 344 (DS) Resource Records (RRs)", RFC 4509, 345 DOI 10.17487/RFC4509, May 2006, 346 . 348 [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of 349 GOST Signature Algorithms in DNSKEY and RRSIG Resource 350 Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July 351 2010, . 353 Authors' Addresses 355 Dmitry Belyavskiy 356 TCINET 357 8 marta st 358 Moscow 359 Russian Federation 361 Phone: +7 916 262 5593 362 Email: beldmit@gmail.com 364 Vasily Dolmatov (editor) 365 JSC "NPK Kryptonite" 366 Spartakovskaya sq., 14, bld 2, JSC "NPK Kryptonite" 367 Moscow 105082 368 Russian Federation 370 Email: vdolmatov@gmail.com