508 lines
17 KiB
Plaintext
508 lines
17 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Internet Engineering Task Force (IETF) V. Dolmatov, Ed.
|
||
Request for Comments: 5933 A. Chuprina
|
||
Category: Standards Track I. Ustinov
|
||
ISSN: 2070-1721 Cryptocom Ltd.
|
||
July 2010
|
||
|
||
|
||
Use of GOST Signature Algorithms in DNSKEY
|
||
and RRSIG Resource Records for DNSSEC
|
||
|
||
Abstract
|
||
|
||
This document describes how to produce digital signatures and hash
|
||
functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms
|
||
for DNSKEY, RRSIG, and DS resource records, for use in the Domain
|
||
Name System Security Extensions (DNSSEC).
|
||
|
||
Status of This Memo
|
||
|
||
This is an Internet Standards Track document.
|
||
|
||
This document is a product of the Internet Engineering Task Force
|
||
(IETF). It represents the consensus of the IETF community. It has
|
||
received public review and has been approved for publication by the
|
||
Internet Engineering Steering Group (IESG). Further information on
|
||
Internet Standards is available in Section 2 of RFC 5741.
|
||
|
||
Information about the current status of this document, any errata,
|
||
and how to provide feedback on it may be obtained at
|
||
http://www.rfc-editor.org/info/rfc5933.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (c) 2010 IETF Trust and the persons identified as the
|
||
document authors. All rights reserved.
|
||
|
||
This document is subject to BCP 78 and the IETF Trust's Legal
|
||
Provisions Relating to IETF Documents
|
||
(http://trustee.ietf.org/license-info) in effect on the date of
|
||
publication of this document. Please review these documents
|
||
carefully, as they describe your rights and restrictions with respect
|
||
to this document. Code Components extracted from this document must
|
||
include Simplified BSD License text as described in Section 4.e of
|
||
the Trust Legal Provisions and are provided without warranty as
|
||
described in the Simplified BSD License.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 1]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
|
||
2.1. Using a Public Key with Existing Cryptographic
|
||
Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2.2. GOST DNSKEY RR Example . . . . . . . . . . . . . . . . . . 4
|
||
3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4
|
||
3.1. RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 5
|
||
4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4.1. DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
|
||
5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
6. Implementation Considerations . . . . . . . . . . . . . . . . . 6
|
||
6.1. Support for GOST Signatures . . . . . . . . . . . . . . . . 6
|
||
6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
|
||
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
|
||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7
|
||
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
|
||
|
||
1. Introduction
|
||
|
||
The Domain Name System (DNS) is the global hierarchical distributed
|
||
database for Internet Naming. The DNS has been extended to use
|
||
cryptographic keys and digital signatures for the verification of the
|
||
authenticity and integrity of its data. RFC 4033 [RFC4033], RFC 4034
|
||
[RFC4034], and RFC 4035 [RFC4035] describe these DNS Security
|
||
Extensions, called DNSSEC.
|
||
|
||
RFC 4034 describes how to store DNSKEY and RRSIG resource records,
|
||
and specifies a list of cryptographic algorithms to use. This
|
||
document extends that list with the signature and hash algorithms
|
||
GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94
|
||
([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and
|
||
how to produce RRSIG resource records with these algorithms.
|
||
|
||
Familiarity with DNSSEC and with GOST signature and hash algorithms
|
||
is assumed in this document.
|
||
|
||
The term "GOST" is not officially defined, but is usually used to
|
||
refer to the collection of the Russian cryptographic algorithms
|
||
GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 2]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
GOST 28147-89 [RFC5830]. Since GOST 28147-89 is not used in DNSSEC,
|
||
"GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in
|
||
this document.
|
||
|
||
1.1. Terminology
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in [RFC2119].
|
||
|
||
2. DNSKEY Resource Records
|
||
|
||
The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].
|
||
|
||
GOST R 34.10-2001 public keys are stored with the algorithm
|
||
number 12.
|
||
|
||
The wire format of the public key is compatible with RFC 4491
|
||
[RFC4491]:
|
||
|
||
According to [GOST3410] and [RFC5832], a public key is a point on the
|
||
elliptic curve Q = (x,y).
|
||
|
||
The wire representation of a public key MUST contain 64 octets, where
|
||
the first 32 octets contain the little-endian representation of x and
|
||
the second 32 octets contain the little-endian representation of y.
|
||
|
||
Corresponding public key parameters are those identified by
|
||
id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
|
||
and the digest parameters are those identified by
|
||
id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].
|
||
|
||
2.1. Using a Public Key with Existing Cryptographic Libraries
|
||
|
||
At the time of this writing, existing GOST-aware cryptographic
|
||
libraries are capable of reading GOST public keys via a generic X509
|
||
API if the key is encoded according to RFC 4491 [RFC4491],
|
||
Section 2.3.2.
|
||
|
||
To make this encoding from the wire format of a GOST public key with
|
||
the parameters used in this document, prepend the 64 octets of key
|
||
data with the following 37-byte sequence:
|
||
|
||
0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
|
||
0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
|
||
0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 3]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
2.2. GOST DNSKEY RR Example
|
||
|
||
Given a private key with the following value (the value of the
|
||
GostAsn1 field is split here into two lines to simplify reading; in
|
||
the private key file, it must be in one line):
|
||
|
||
Private-key-format: v1.2
|
||
Algorithm: 12 (ECC-GOST)
|
||
GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
|
||
iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=
|
||
|
||
The following DNSKEY RR stores a DNS zone key for example.net:
|
||
|
||
example.net. 86400 IN DNSKEY 256 3 12 (
|
||
aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
|
||
MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
|
||
w4X1gpNrZiC01g==
|
||
) ; key id = 59732
|
||
|
||
3. RRSIG Resource Records
|
||
|
||
The value of the signature field in the RRSIG RR follows RFC 4490
|
||
[RFC4490] and is calculated as follows. The values for the RDATA
|
||
fields that precede the signature data are specified in RFC 4034
|
||
[RFC4034].
|
||
|
||
hash = GOSTR3411(data)
|
||
|
||
where "data" is the wire format data of the resource record set that
|
||
is signed, as specified in RFC 4034 [RFC4034].
|
||
|
||
The hash MUST be calculated with GOST R 34.11-94 parameters
|
||
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
|
||
|
||
The signature is calculated from the hash according to the
|
||
GOST R 34.10-2001 standard, and its wire format is compatible with
|
||
RFC 4490 [RFC4490].
|
||
|
||
Quoting RFC 4490:
|
||
|
||
"The signature algorithm GOST R 34.10-2001 generates a digital
|
||
signature in the form of two 256-bit numbers, r and s. Its octet
|
||
string representation consists of 64 octets, where the first
|
||
32 octets contain the big-endian representation of s and the second
|
||
32 octets contain the big-endian representation of r".
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 4]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
3.1. RRSIG RR Example
|
||
|
||
With the private key from Section 2.2, sign the following RRSet,
|
||
consisting of one A record:
|
||
|
||
www.example.net. 3600 IN A 192.0.2.1
|
||
|
||
Setting the inception date to 2000-01-01 00:00:00 UTC and the
|
||
expiration date to 2030-01-01 00:00:00 UTC, the following signature
|
||
RR will be valid:
|
||
|
||
www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
|
||
20000101000000 59732 example.net.
|
||
7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
|
||
kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
|
||
zi67+wBbbW/jrA== )
|
||
|
||
Note: The ECC-GOST signature algorithm uses random data, so the
|
||
actual computed signature value will differ between signature
|
||
calculations.
|
||
|
||
4. DS Resource Records
|
||
|
||
The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the
|
||
digest type 3. The wire format of a digest value is compatible with
|
||
RFC 4490 [RFC4490], that is, the digest is in little-endian
|
||
representation.
|
||
|
||
The digest MUST always be calculated with GOST R 34.11-94 parameters
|
||
identified by id-GostR3411-94-CryptoProParamSet [RFC4357].
|
||
|
||
4.1. DS RR Example
|
||
|
||
For Key Signing Key (KSK):
|
||
|
||
example.net. 86400 DNSKEY 257 3 12 (
|
||
LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
|
||
gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
|
||
SRGR7ZYcx+YIQw==
|
||
) ; key id = 40692
|
||
|
||
The DS RR will be
|
||
|
||
example.net. 3600 IN DS 40692 12 3 (
|
||
22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
|
||
2071398F )
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 5]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
5. Deployment Considerations
|
||
|
||
5.1. Key Sizes
|
||
|
||
According to RFC 4357 [RFC4357], the key size of GOST public keys
|
||
MUST be 512 bits.
|
||
|
||
5.2. Signature Sizes
|
||
|
||
According to the GOST R 34.10-2001 digital signature algorithm
|
||
specification ([GOST3410], [RFC5832]), the size of a GOST signature
|
||
is 512 bits.
|
||
|
||
5.3. Digest Sizes
|
||
|
||
According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a
|
||
GOST digest is 256 bits.
|
||
|
||
6. Implementation Considerations
|
||
|
||
6.1. Support for GOST Signatures
|
||
|
||
DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY
|
||
resource records created with the GOST algorithms as defined in this
|
||
document.
|
||
|
||
6.2. Support for NSEC3 Denial of Existence
|
||
|
||
Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and
|
||
NSEC3 [RFC5155].
|
||
|
||
7. Security Considerations
|
||
|
||
Currently, the cryptographic resistance of the GOST R 34.10-2001
|
||
digital signature algorithm is estimated as 2**128 operations of
|
||
multiple elliptic curve point computations on prime modulus of order
|
||
2**256.
|
||
|
||
Currently, the cryptographic resistance of the GOST R 34.11-94 hash
|
||
algorithm is estimated as 2**128 operations of computations of a step
|
||
hash function. (There is a known method to reduce this estimate to
|
||
2**105 operations, but it demands padding the colliding message with
|
||
1024 random bit blocks each of 256-bit length; thus, it cannot be
|
||
used in any practical implementation).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 6]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
8. IANA Considerations
|
||
|
||
This document updates the IANA registry "DNS Security Algorithm
|
||
Numbers" [RFC4034]. The following entries have been added to the
|
||
registry:
|
||
|
||
Zone Trans.
|
||
Value Algorithm Mnemonic Signing Sec. References Status
|
||
12 GOST R 34.10-2001 ECC-GOST Y * RFC 5933 OPTIONAL
|
||
|
||
This document updates the RFC 4034 Digest Types assignment
|
||
([RFC4034], Section A.2) by adding the value and status for the
|
||
GOST R 34.11-94 algorithm:
|
||
|
||
Value Algorithm Status
|
||
3 GOST R 34.11-94 OPTIONAL
|
||
|
||
9. Acknowledgments
|
||
|
||
This document is a minor extension to RFC 4034 [RFC4034]. Also, we
|
||
tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509],
|
||
and RFC 4357 [RFC4357] for consistency. The authors of and
|
||
contributors to these documents are gratefully acknowledged for their
|
||
hard work.
|
||
|
||
The following people provided additional feedback, text, and valuable
|
||
assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson,
|
||
Jelte Jansen, and Wouter Wijngaards.
|
||
|
||
10. References
|
||
|
||
10.1. Normative References
|
||
|
||
[GOST3410] "Information technology. Cryptographic data security.
|
||
Signature and verification processes of [electronic]
|
||
digital signature.", GOST R 34.10-2001, Gosudarstvennyi
|
||
Standard of Russian Federation, Government Committee of
|
||
Russia for Standards, 2001. (In Russian).
|
||
|
||
[GOST3411] "Information technology. Cryptographic data security.
|
||
Hashing function.", GOST R 34.11-94, Gosudarstvennyi
|
||
Standard of Russian Federation, Government Committee of
|
||
Russia for Standards, 1994. (In Russian).
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 7]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
|
||
Domain Name System (DNS)", RFC 3110, May 2001.
|
||
|
||
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "DNS Security Introduction and Requirements",
|
||
RFC 4033, March 2005.
|
||
|
||
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Resource Records for the DNS Security Extensions",
|
||
RFC 4034, March 2005.
|
||
|
||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||
Rose, "Protocol Modifications for the DNS Security
|
||
Extensions", RFC 4035, March 2005.
|
||
|
||
[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional
|
||
Cryptographic Algorithms for Use with GOST 28147-89,
|
||
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
|
||
Algorithms", RFC 4357, January 2006.
|
||
|
||
[RFC4490] Leontiev, S., Ed. and G. Chudov, Ed., "Using the
|
||
GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and
|
||
GOST R 34.10-2001 Algorithms with Cryptographic Message
|
||
Syntax (CMS)", RFC 4490, May 2006.
|
||
|
||
[RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the
|
||
GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94
|
||
Algorithms with the Internet X.509 Public Key
|
||
Infrastructure Certificate and CRL Profile", RFC 4491,
|
||
May 2006.
|
||
|
||
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
|
||
Security (DNSSEC) Hashed Authenticated Denial of
|
||
Existence", RFC 5155, March 2008.
|
||
|
||
10.2. Informative References
|
||
|
||
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
|
||
(DS) Resource Records (RRs)", RFC 4509, May 2006.
|
||
|
||
[RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption,
|
||
Decryption, and Message Authentication Code (MAC)
|
||
Algorithms", RFC 5830, March 2010.
|
||
|
||
[RFC5831] Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function
|
||
Algorithm", RFC 5831, March 2010.
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 8]
|
||
|
||
RFC 5933 Use of GOST Signatures in DNSSEC July 2010
|
||
|
||
|
||
[RFC5832] Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature
|
||
Algorithm", RFC 5832, March 2010.
|
||
|
||
Authors' Addresses
|
||
|
||
Vasily Dolmatov (editor)
|
||
Cryptocom Ltd.
|
||
14/2, Kedrova St.
|
||
Moscow, 117218
|
||
Russian Federation
|
||
|
||
Phone: +7 499 124 6226
|
||
EMail: dol@cryptocom.ru
|
||
|
||
|
||
Artem Chuprina
|
||
Cryptocom Ltd.
|
||
14/2, Kedrova St.
|
||
Moscow, 117218
|
||
Russian Federation
|
||
|
||
Phone: +7 499 124 6226
|
||
EMail: ran@cryptocom.ru
|
||
|
||
|
||
Igor Ustinov
|
||
Cryptocom Ltd.
|
||
14/2, Kedrova St.
|
||
Moscow, 117218
|
||
Russian Federation
|
||
|
||
Phone: +7 499 124 6226
|
||
EMail: igus@cryptocom.ru
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Dolmatov, et al. Standards Track [Page 9]
|
||
|