SM2 Digital Signature Algorithm for DNSSEC
Internet-Draft draft-cuiling-dnsop-sm2-alg-15
Cuiling Zhang
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
China
zhangcuiling@cnnic.cn
Yukun Liu
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
China
liuyukun@cnnic.cn
Feng Leng
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
China
lengfeng@cnnic.cn
Qi Zhao
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
China
zhaoqi@cnnic.cn
Zheng He
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
China
hezh@cnnic.cn
18 January 2024
This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC).
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 [RFC4033], [RFC4034], and [RFC4035]. It uses cryptographic keys and digital signatures to provide authentication of DNS data. DNSSEC signature algorithms are registered in the DNSSEC algorithm IANA registry [IANA].
This document defines the DNSKEY and RRSIG resource records (RRs) of 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 [GBT-32918.2-2016] or ISO/IEC14888-3:2018 [ISO-IEC14888-3_2018], and GB/T 32905-2016 [GBT-32905-2016] or ISO/IEC10118-3:2018 [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 [RFC2119].
SM3 DS Records
The implementation of SM3 in DNSSEC follows the implementation of SHA-256 as specified in [RFC4509] except that the underlying algorithm is SM3 with digest type code [TBD1, waiting for an IANA's code assignment].
The generation of a SM3 hash value is described in Section 5 of [GBT-32905-2016] and generates 256-bit hash value.
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 profile are as follows:

   p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
   a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
   b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93
   xG = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7
   yG = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0
   n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123

DNSKEY and RRSIG Resource Records for SM2
DNSKEY Resource Records
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". (Conversion of a point to an octet string is described in Section 4.2.8 of GB/T 32918.1-2016 [GBT-32918.1-2016].)
RRSIG Resource Records
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 described in Section 4.2.1 of [GBT-32918.1-2016].) Each integer MUST be encoded as 32 octets.
Process details are described in Section 6 "Digital signature generation algorithm and its process" in [GBT-32918.2-2016].
The algorithm number associated with the DNSKEY and RRSIG resource records is [TBD2, waiting for an IANA’s code assignment], 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 [RFC5155].
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 SHA-1, as defined in [RFC5155]. 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.
If using NSEC3, the iterations MUST be 0 and salt MUST be an empty string as recommended in Section 3.1 of [RFC9276].
Example
The following is an example of SM2 keys and signatures in DNS zone file format, including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs and DS RR.

Private-key-format: v1.3
Algorithm: [TBD2] (SM2SM3)
PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=

example. 3600 IN DS 27215 TBD2 TBD1 (
86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e )

example. 3600  IN   DNSKEY  256 3 TBD2 (
    7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug
    ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ
    wu+qUuDsgoBK4w==
    ) ; ZSK; alg = SM2SM3 ; key id = 65042
example. 3600  IN   RRSIG   DNSKEY TBD2 1 3600 (
    20230901000000 20220901000000 65042 example.
    lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl
    lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36
    Jsuu0FSO5k48Qg== )

example. 0  IN   NSEC3PARAM 1 0 10 AABBCCDD
example. 0  IN   RRSIG    NSEC3PARAM TBD2 1 0 (
    20230901000000 20220901000000 65042 example.
    aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj

62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3
1 1 10 AABBCCDD (
GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )
62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG
NSEC3 TBD2 2 3600 (
20230901000000 20220901000000 65042 example. FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )
Here is an example program [Example_Program] based on dnspython and gmssl, which supplies key generating, zone signing, zone validating and DS RR generating functions for convenience.
IANA Considerations
This document will update the IANA registry for digest types in DS records, currently called "Digest Algorithms," in the "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group.

       Value          TBD1
       Digest Type    SM3
       Status         OPTIONAL
       Reference      This document

This document will update the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers".

       Number         TBD2
       Description    SM2 signing algorithm with SM3 hashing algorithm
       Mnemonic       SM2SM3
       Zone Signing   Y
       Trans. Sec.    *
       Reference      This document

* There has been no determination of standardization of the use of this algorithm with Transaction Security.
Security Considerations
The security strength of SM2 depends on the size of the key. Longer key provides stronger security strength. The security of ECC-based algorithms is influenced by the curve it uses, too.
Like any cryptographic algorithm, it may come to pass that a weakness is found in either SM2 or SM3. In this case, the proper remediation is crypto-agility. In the case of DNSSEC, the appropriate approach would be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records. Care MUST be taken in this situation to permit appropriate rollovers, taking into account record caching. See [RFC7583] for details. Choice of a suitable replacement algorithm should be one that is both widely implemented and not known to have weaknesses.
The security considerations listed in [RFC4509] apply here as well.
References
Normative References
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC4033]

DNS Security Introduction and Requirements
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4033
DOI 10.17487/RFC4033
[RFC4034]

Resource Records for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4034
DOI 10.17487/RFC4034
[RFC4035]

Protocol Modifications for the DNS Security Extensions
R. Arends
R. Austein
M. Larson
D. Massey
S. Rose
March 2005
RFC 4035
DOI 10.17487/RFC4035
[IANA]

Domain Name System Security (DNSSEC) Algorithm Numbers
IANA
April 2020
Registered DNSSEC Algorithm Numbers
[RFC4509]

Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
W. Hardaker
May 2006
RFC 4509
DOI 10.17487/RFC4509
[RFC5155]

DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
B. Laurie
G. Sisson
R. Arends
D. Blacka
March 2008
RFC 5155
DOI 10.17487/RFC5155
[RFC9276]

Guidance for NSEC3 Parameter Settings
W. Hardaker
V. Dukhovni
August 2022
BCP 236
RFC 9276
DOI 10.17487/RFC9276
[RFC7583]

DNSSEC Key Rollover Timing Considerations
S. Morris
J. Ihren
J. Dickinson
W. Mekking
October 2015
RFC 7583
DOI 10.17487/RFC7583
[GBT-32918.1-2016]

Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 1: General
Standardization Administration of China
March 2017
GB/T 32918.2-2016
[GBT-32918.2-2016]

Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm
Standardization Administration of China
March 2017
GB/T 32918.2-2016
[ISO-IEC14888-3_2018]

IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms
International Organization for Standardization
November 2018
ISO/IEC 14888-3:2018
[GBT-32905-2016]

Information security technology --- SM3 cryptographic hash algorithm
Standardization Administration of China
March 2017
GB/T 32905-2016
[ISO-IEC10118-3_2018]

IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions
International Organization for Standardization
October 2018
ISO/IEC 10118-3:2018
Informative References
[Example_Program]

Sign and Validate DNSSEC Signature with SM2SM3 Algorithm
C. Zhang
April 2023
SM2SM3 DNSSEC Example Program