Internet Engineering Task Force G. Deng Internet-Draft S. Shen Intended status: Standards Track N. Kong Expires: March 5, 2013 CNNIC September 2012 Use of SM2 and SM3 algorithms in DNSKEY and RRSIG Resource Records for DNSSEC draft-deng-sec-dnsec-alg-00 Abstract This document describes how to generate signature and hash using SM2 and SM3 algorithms for DNSKEY, RRSIG and DS resource records in Domain Name System Security Extensions (DNSSEC). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 5, 2013. Copyright Notice Copyright (c) 2012 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. Deng, et al. Expires March 5, 2013 [Page 1] Internet-Draft SM2 and SM3 for DNSSEC September 2012 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3 2.1. SM2 DNSKEY RR Example . . . . . . . . . . . . . . . . . . . 3 3. RRSIG Resource Records . . . . . . . . . . . . . . . . . . . . 4 3.1. RRSIG RR Example . . . . . . . . . . . . . . . . . . . . . 4 4. DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 4 4.1. DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5 5. Deployment Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 5 5.3. Digest Sizes . . . . . . . . . . . . . . . . . . . . . . . 5 6. Implementation Considerations . . . . . . . . . . . . . . . . . 5 6.1. Support for SM2 signatures . . . . . . . . . . . . . . . . 5 6.2. Support for NSEC3 Denial of Existence . . . . . . . . . . . 5 6.3. Byte order . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 6 8. Security considerations . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Deng, et al. Expires March 5, 2013 [Page 2] Internet-Draft SM2 and SM3 for DNSSEC September 2012 1. Introduction The Domain Name System (DNS) is a globally distributed, scalable and hierarchical database that provides a consistent name space for referring to resources. The DNS has been extended to use hash functions and digital signatures to provide origin authentication and integrity protection for its data. RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security Extensions which consist of a set of new resource record types and modifications to the existing DNS protocol ([RFC1035]). RFC 4034 describes the wire format of DNSKEY, RRSIG and DS resource records, and specifies a list of cryptographic algorithms to use. This document extends that list with the signature algorithm SM2 [SM2] and hash algorithm SM3 [SM3], and specifies how to store DNSKEY data and how to generate RRSIG and DS resource records with these cryptographic algorithms. 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 resource record can be found in RFC 4034 [RFC4034]. SM2 [SM2] public keys are stored with the algorithm number 249 (which is a proposed value with pending approval of IANA). According to [SM2], a public key is a point on the elliptic curve Q = (x,y) where x and y are the x-coordinate and y-coordinate value, respectively. The wire representation of a public key MUST contain 64 octets, where the first 32 octets contain the x and the second 32 octets contain the y. 2.1. SM2 DNSKEY RR Example In SM2 [SM2], the size of private key is 32 bytes. Set a private key to the following value which is presented in the form of base64 encoding: Algorithm: 249 (SM2) SM2 Private Key: EosvqL1DPGwGjI2APf95eSpRmlUXGxtlDCNmHRWJcmM= Deng, et al. Expires March 5, 2013 [Page 3] Internet-Draft SM2 and SM3 for DNSSEC September 2012 Using the corresponding public key of above private key, the following DNSKEY RR stores a DNS public key for example.net: example.net. 86400 IN DNSKEY 256 3 249 (1VSMeCXLtWFQo1Bs1XRkr4 oa4FGd+vPFgiHcgQyvKN2SEHN2j+PVnOVOeaSURc9z/tIwhlNwJyZNFolG1HlTPg==) 3. RRSIG Resource Records The value of the signature field in the RRSIG RR follows SM2 [SM2] and is calculated as follows. The values for the RDATA fields that precede the signature data are specified in RFC 4034 [RFC4034]. hash = SM3(data) where "data" is the wire format data of the resource record set that is signed, as specified in RFC 4034 [RFC4034]. Hash MUST be calculated according to SM3 [SM3] and hash size is 256 bits; Signature is calculated from the hash according to SM2 [SM2] and signature size is 512 bits. 3.1. RRSIG RR Example With the private key from section 2.1, sign the following RRSet, consisting of one A record: host.example.com. 86400 IN A 192.253.253.1 Setting the inception date to 2012-09-12 00:00:00 UTC and the expiration date to 2012-10-12 00:00:00 UTC, the following signature should be valid: host.example.com. 86400 IN RRSIG A 249 3 86400 20121012000000 (20120912000000 2642 example.com. EeZjSD4pbx6e5wxsxFLSaIwgT1oZP5Qriy c6qC8Qo2GSXGJorSrfEjB1y7q65qTJRbym5eZTWdQKoOYmC2Go4w==) 4. DS Resource Records SM3 [SM3] digest algorithm is denoted in DS RRs by the digest type 12 (which is a proposed value with pending approval of IANA) before a specific one is assigned by IANA. The digest MUST always be calculated with parameters defined in [SM3]. Deng, et al. Expires March 5, 2013 [Page 4] Internet-Draft SM2 and SM3 for DNSSEC September 2012 4.1. DS RR Example For key signing key dskey.example.com. 86400 IN DNSKEY 256 3 249 (1VSMeCXLtWFQo1Bs1XRkr4oa4FGd+ vPFgiHcgQyvKN2SEHN2j+PVnOVOeaSURc9z/ tIwhlNwJyZNFolG1HlTPg==) ; key id = 60485 The DS RR will be dskey.example.com. 86400 IN DS 60485 249 12 (76D4267B639C43BC3EC837266FE4913D86A4C9CB2BC98EC55128CD32F64C5EBA) 5. Deployment Considerations 5.1. Key Sizes According to SM2 [SM2], the size of SM2 public key is 512 bits. 5.2. Signature Sizes According to SM2 [SM2], the size of a SM2 signature is 512 bits. 5.3. Digest Sizes According to the SM3 [SM3], the size of a SM3 digest is 256 bits. 6. Implementation Considerations 6.1. Support for SM2 signatures DNSSEC aware implementations MAY be able to support RRSIG and DNSKEY resource records created with the SM2 algorithms as defined in this document. 6.2. Support for NSEC3 Denial of Existence Any DNSSEC-SM2 implementation MUST support both NSEC [RFC4035] and NSEC3 [RFC5155]. 6.3. Byte order According to SM3 [SM3], the endianness of SM3 is big-endian. Deng, et al. Expires March 5, 2013 [Page 5] Internet-Draft SM2 and SM3 for DNSSEC September 2012 7. IANA consideration This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following two entries are added to the registry: Number 249(proposed) Algorithm SM2 Mnemonic ECC-SM2 Zone Signing Y Trans. Sec. * Reference this document Status optional This document updates the IANA registry for digest types in DS records, currently called "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms". The following entries are added: Value 12(proposed) Digest Type SM3 Status OPTIONAL * There has been no determination of standardization of the use of this algorithm with Transaction Security. 8. Security considerations This document gives more algorithm choices to the algorithm list in RFC 4034 and does not bring in extra risk in protocol aspect. In the aspect of algorithm strength, the proposed signature algorithm is ECC based with key size of 256 bits. Theoretically, the strength of that algorithm is on the same level as RSA based signature of 2048 bits. And there are no known successful attacks since the algorithm is published till this document is published. 9. References 9.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Deng, et al. Expires March 5, 2013 [Page 6] Internet-Draft SM2 and SM3 for DNSSEC September 2012 [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. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008. 9.2. Informative References [SM2] Shen, S. and X. Lee, "SM2 Digital Signature Algorithm", October 2011, . [SM3] Chinese Commercial Cryptography Administration Office, "", December 2010, . Authors' Addresses Guangqing Deng CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3430 Email: dengguangqing@cnnic.cn Sean Shen CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3038 Email: shenshuo@cnnic.cn Deng, et al. Expires March 5, 2013 [Page 7] Internet-Draft SM2 and SM3 for DNSSEC September 2012 Ning Kong CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China Phone: +86 10 5881 3147 Email: nkong@cnnic.cn Deng, et al. Expires March 5, 2013 [Page 8]