]> CNNIC

No.4 South 4th Street, Zhongguancun Beijing, 100190 China zhangcuiling@cnnic.cn

CNNIC

No.4 South 4th Street, Zhongguancun Beijing, 100190 China liuyukun@cnnic.cn

CNNIC

No.4 South 4th Street, Zhongguancun Beijing, 100190 China lengfeng@cnnic.cn

CNNIC

No.4 South 4th Street, Zhongguancun Beijing, 100190 China zhaoqi@cnnic.cn

CNNIC

No.4 South 4th Street, Zhongguancun Beijing, 100190 China hezh@cnnic.cn

This document describes how to specify SM2 Digital Signature Algorithm keys and signatures in DNS Security (DNSSEC). It lists the curve and uses SM3 as hash algorithm for signatures. This draft is an independent submission to the RFC series, and does not have consensus of the IETF community.

Introduction DNSSEC is broadly defined in RFCs 4033, 4034, and 4035 (, , and ). It uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, there are several signature algorithms, such as RSA with SHA-256 defined in RFC 5702 ([RFC5702]), and ECDSA with curve P-256 and SHA-256 defined in RFC 6605 (), etc. This document defines the DNSKEY and RRSIG resource records (RRs) of a new signing algorithms: SM2 uses elliptic curves over 256-bit prime fields with SM3 hash algorithm. (A description of SM2 and SM3 can be found in GB/T 32918.2-2016 or ISO/IEC14888-3:2018 , and GB/T 32905-2016 or ISO/IEC10118-3:2018 .) This document also defines the DS RR for the SM3 one-way hash algorithm. In the signing algorithm defined in this document, the size of the key for the elliptic curve is matched with the size of the output of the hash algorithm. Both are 256 bits. 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 RFC 2119 .

SM3 DS Records SM3 is included in ISO/IEC 10118-3:2018 and is similar to SHA-256 in many ways. The implementation of SM3 in DNSSEC follows the implementation of SHA-256 as specified in RFC 4509 except that the underlying algorithm is SM3 with digest type code [TBD1].

SM2 Parameters Verifying SM2 signatures requires agreement between the signer and the verifier of the parameters used. SM2 digital signature algorithm has been added to ISO/IEC 14888-3:2018. And the parameters of the curve used in this document are as follows:

DNSKEY and RRSIG Resource Records for SM2 SM2 public keys consist of a single value, called "P". In DNSSEC keys, P is a string of 32 octets that represents the uncompressed form of a curve point, "x | y". The SM2 signature is the combination of two non-negative integers, called "r" and "s". The two integers, each of which is formatted as a simple octet string, are combined into a single longer octet string for DNSSEC as the concatenation "r | s". (Conversion of the integers to bit strings is the same as ECDSA signature.) Each integer MUST be encoded as 32 octets. Although SM2 uses elliptic curves, the process of digest and signature generation is different from ECDSA. Process details are described in section 6 "Digital signature generation algorithm and its process" in . The algorithm number associated with the DNSKEY and RRSIG resource records is [TBD2], which is described in the IANA Considerations section. Conformant implementations that create records to be put into the DNS MAY implement signing and verification for the above algorithm. Conformant DNSSEC verifiers MAY implement verification for the above algorithm.

Support for NSEC3 Denial of Existence This document does not define algorithm aliases mentioned in RFC 5155 . A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence.

Example The following is an example of SM2 keys and signatures in DNS zone file format.

IANA Considerations This document will update the IANA registry for digest types in DS records, currently called "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms". This document will update the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". * There has been no determination of standardization of the use of this algorithm with Transaction Security.

Security Considerations The security strength of SM2 is considered to be equivalent to half the size of the key, which is 128 bits. For another thing, the security of ECC-based algorithms is influenced by the curve it uses. Thus it's recommended that the DNS server implementations use popular cryptography library which support SM2 and SM3 algorithms, such as OpenSSL. Thus it's convenient to use a different curve if SM2 is compromised. The security considerations listed in RFC 4509 apply here as well.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] This document specifies how to use the SHA-256 digest type in DNS Delegation Signer (DS) Resource Records (RRs). DS records, when stored in a parent zone, point to DNSKEYs in a child zone. [STANDARDS-TRACK] The Domain Name System Security (DNSSEC) Extensions introduced the NSEC resource record (RR) for authenticated denial of existence. This document introduces an alternative resource record, NSEC3, which similarly provides authenticated denial of existence. However, it also provides measures against zone enumeration and permits gradual expansion of delegation-centric zones. [STANDARDS-TRACK] This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures. [STANDARDS-TRACK] Standardization Administration of China International Organization for Standardization Standardization Administration of China International Organization for Standardization Informative References

Example Zone This is a zone showing its RRSIG RRs generated with SM3 hash algorithm and SM2 signature algorithm.

Here is an example program based on dnspython and gmssl, which supplies key generating, zone signing, zone validating and DS RR generating functions for convinience.