SM2 Digital Signature Algorithm for DNSSEC
draft-cuiling-dnsop-sm2-alg-05

Workgroup:          Network Working Group                      C. Zhang
Internet-Draft:     draft-cuiling-dnsop-sm2-alg-05               Y. Liu 
Updates:            8624 (if approved)                          F. Leng
Published:          2023-03-08                                  Q. Zhao
Intended Status:    Informational                                 Z. He
Expires:            2023-09-08                                    CNNIC
                                                                                                                                                                                                                                                         

SM2 Digital Signature Algorithm for DNSSEC

Abstract

        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.

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 https://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 xx xxx 2023.

Copyright Notice

        Copyright (c) 2022 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 
        (https://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 Revised BSD License text as described in Section 4.e of 
        the Trust Legal Provisions and are provided without warranty as 
        described in the Revised BSD License.

1.  Introduction

        DNSSEC is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033], 
        [RFC4034], and [RFC4035]). 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,ECDSA 
        with curve P-256 and SHA-256, 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 [GB/T 32918.2-2016] or ISO/IEC14888-3:2018
        [ISO/IEC14888-3:2018], and GB/T 32905-2016 [GB/T 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.

        Like all ECC-based algorithms, signing with SM2 is significantly 
        faster than RSA based algorithms, while the validating is slower.

        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 [RFC2119].

2.  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[RFC4509] except 
        that the underlying algorithm is SM3 with digest type code [TBD1].

3.  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:

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

4.  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.

        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.

5.  Support for NSEC3 Denial of Existence

        This document does not define algorithm aliases mentioned in RFC 5155 
        [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 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.

6.  Example

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

6.1. SM2 Example

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

        example.net. 3600 IN DNSKEY 257 3 TBD2 (
                jZbZMBImG9dtGWSVEwnv2l32OVKcX7MMJv+83/+A41ia
                ZuO0ajXMcuyJbTr8Ud+kae6UlfqrnsG6tgADIPHxXA== )

        example.net. 3600 IN DS 27215 TBD2 TBD1 (
                86671f82dd872e4ee73647a95dff7fd0af599ff8a43f
                fa26c9a2593091653c0e )
        
        www.example.net. 3600 IN A 192.0.2.1
        www.example.net. 3600 IN RRSIG A TBD2 6 3600 (
                20220428075649 20220331075649 27215 example.net.
                tz295lkfu2InRnLdLhKWDm354I6ZGSmYeOSDswKiQMU7
                /Va0QrH7bD7ZnHB4wWsEjfy1XscwM4P86sVxkMJE7w== )
        

7.  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".

                         Value          TBD1
                         Digest Type    SM3
                         Status         OPTIONAL

        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.

8.  Security Considerations

        The cryptographic work factor of SM2 is generally considered to be 
        equivalent to half the size of the key, which is 128 bits. Such an 
        assessment could, of course, change in the future if new attacks that 
        work better than the ones known today are found.

        SM2 digital signature algorithm has come into use for less than a score
        of years. So SM2SM3 algorithm is mainly used for research and experiment 
        purpose currently. The security of ECC-based algorithms is influenced by 
        the curve it uses. SM2 uses a different curve and has different process with 
        the signature generation and validation, so SM2 could be considered as an
        alternative to ECDSA.

        The security considerations listed in RFC 4509 apply here as well.

9.  References
9.1.  Normative References

        [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                                                 Requirement Levels", BCP 14, RFC 2119, March 1997.

        [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.

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

        [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
                                                 Security (DNSSEC) Hashed Authenticated Denial of
                                                 Existence", RFC 5155, March 2008.

        [RFC6605]  Hoffman, P., and Wouter C.A. Wijngaards, "Elliptic Curve 
                                                 Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605,
                                                 April 2012.
9.2.  Informative References

        [GB/T 32918.2-2016]     Standardization Administration of the People's Republic of
                                                China, "Information security technology --- Public key
                                                cryptographic algorithm SM2 based on elliptic curves ---
                                                Part 2: Digital signature algorithm", GB/T 32918.2-2016,
                                                March 2017, <https://github.com/alipay/tls13-sm-spec/blob/
                                                master/sm-en-pdfs/sm2/GBT.32918.2-2016.SM2-en.pdf>.

        [ISO/IEC14888-3:2018]   International Organization for Standardization, 
                                                "IT Security techniques — Digital signatures with appendix — 
                                                Part 3: Discrete logarithm based mechanisms", 
                                                ISO ISO/IEC 14888-3:2018, November 2018.

        [GB/T 32905-2016]       Standardization Administration of the People's Republic of
                                                China, "SM3 Cryptographic Hash Algorithm", GB/T 32905-2016,
                                                March 2017, <https://github.com/alipay/tls13-sm-spec/blob/
                                                master/sm-en-pdfs/sm3/GBT.32905-2016.SM3-en.pdf>.

        [ISO/IEC10118-3:2018]  International Organization for Standardization, 
                                                 "IT Security techniques -- Hash-functions -- Part 3: Dedicated 
                                                 hash-functions", ISO ISO/IEC 10118-3:2018, October 2018.

Appendix A.  Example Zone

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

        example. 3600  IN   SOA    ns1.example. root.example. (
                            1          ; serial
                            3600       ; refresh (1 hour)
                            300        ; retry (5 minutes)
                            3600000    ; expire (5 weeks 6 days 16 hours)
                            3600       ; minimum (1 hour)
                            )
                    RRSIG   SOA TBD2 1 3600 (
                            20230901000000 20220901000000 65042 example.
                            vXGQ/M+QJbEzdF9MW8rqJVN+QC5LdpK7k7vt
                            nupu/SrZhiKDGcXpORMpprlljlQ6w4YqytdA
                            ZHfbu25HfIyEgw== )
                    NS      ns1.example.
                    NS      ns2.example.
                    RRSIG   NS TBD2 1 3600 (
                            20230901000000 20220901000000 65042 example.
                            xXR6eAWSdv9KpEtX/GccI0AFafmUoARf9Q1i
                            CgtoJKjFCQySqBLVxlgiQQaTpZqY8taepygv
                            8g5o5mHsfmyPiw== )
                    DNSKEY  256 3 TBD2 (
                            7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug
                            ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ
                            wu+qUuDsgoBK4w==
                            ) ; ZSK; alg = SM2SM3 ; key id = 65042
                    DNSKEY  257 3 TBD2 (
                            jZbZMBImG9dtGWSVEwnv2l32OVKcX7MMJv+8
                            3/+A41iaZuO0ajXMcuyJbTr8Ud+kae6Ulfqr
                            nsG6tgADIPHxXA==
                            ) ; KSK; alg = SM2SM3 ; key id = 27215
                    RRSIG   DNSKEY TBD2 1 3600 (
                            20230901000000 20220901000000 65042 example.
                            lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl
                            lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36
                            Jsuu0FSO5k48Qg== )
                    RRSIG   DNSKEY TBD2 1 3600 (
                            20230901000000 20220901000000 27215 example.
                            +MDF1bnH/8zCeOwJQbWSfwb6OCB8fp16rxog
                            S9+PbxHEcKNTOUX3hPxdM8NblDgY19c+KDmr
                            xei2D84M2B50cQ== )
                    0    NSEC3PARAM 1 0 10 AABBCCDD
                    0    RRSIG    NSEC3PARAM TBD2 1 0 (
                            20230901000000 20220901000000 65042 example.
                            aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj
                            6/TGt2/bewiM/Hp9fqOysEcjgWZ7lZbqJsR5
                            HtKlddixnjmOFQ== )
        ns2.example.   A    192.0.2.2
                    RRSIG   A TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            xqot4urj885t1SDnAZnozl4s3t/El1HZVLwb
                            0N2Bb6IdEBtH/SNJdN1Zz/xBysCGkRwoMq2I
                            Uk+v3Yl6Uo8Eiw== )
        ns1.example.   A    192.0.2.1
                    RRSIG   A TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            5ZNwC4No82PeHZd5PgdGmBsvRxjBe3FlnA4S
                            g8/tDZlHM7QSbDDN17r8+qHq+AeXKy8cSF3n
                            U+byf9VjzV9IKA== )
        www.example.   A    192.0.2.3
                    RRSIG    A TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            vNTwnIQzImSG6b6F0dNhNz+mt8oSRITzfiNh
                            mzdvI0w1eHxTetA/3Tu3HLoDYDw+D5uGcoVZ
                            NlvZpyrIU1BIAA== )
        S0OCR8EH8COF31Q1TO66KIDIT4A4RV8R.example.  NSEC3    1 1 10 AABBCCDD (
                            62KP1QB93KRGR6LM7SEVPJVNG90BLUE8
                            A RRSIG )
                    RRSIG   NSEC3 TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            ai3O/vkgVX6DRJFjfwWJI71QNXucCaTpWBAQ
                            JyedgjRGC/XgX1WF60SglDzWmlHdyACPHV4S
                            1dBE344tnNgAtA== )
        GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2.example.  NSEC3    1 1 10 AABBCCDD (
                            NIU1DMQS67H1PIN9JIMC33JCMO8MU99T
                            A RRSIG )
                    RRSIG   NSEC3 TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            3BUwHiacqHADK7Y31kFa4JnGOrURCXlZNmZq
                            B163jles9HCQHIDR60DFZdZhx1sVBsd8Rl+L
                            dUcia3aUgNqwlA== )
        NIU1DMQS67H1PIN9JIMC33JCMO8MU99T.example.  NSEC3    1 1 10 AABBCCDD (
                            OHVFQ9KQA23B5PM64EST8LNRQRLQ624H
                            A RRSIG )
                    RRSIG   NSEC3 TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            ctAutz6smtvUeeCyZPel3BTYJzkJcYGXEDRH
                            hosBrWRiipM/C94nZxFpYioK+mq5tw9yebwH
                            83Vq94AChHbabg== )
        test.example.  A    192.0.2.4
                    RRSIG   A TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            H9+NQdd9o4NTj8siRO8c5IrjJ/6BuNaZdgeh
                            AbcwTcxBvhE7D4XeHH9zUcZ0gVuhdR8WoA8H
                            FVbCrekKGgW7Gw== )
        OHVFQ9KQA23B5PM64EST8LNRQRLQ624H.example.  NSEC3    1 1 10 AABBCCDD (
                            S0OCR8EH8COF31Q1TO66KIDIT4A4RV8R
                            A RRSIG )
                    RRSIG   NSEC3 TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            eygDRIjsL+OXE4leoBuZOFptq+FMkWGfXA19
                            ojaJlnRfeLXEHKBrCFMEe+8l3qlTkGFsBo3N
                            E3tQU4uSMafViA== )
        62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example.  NSEC3    1 1 10 AABBCCDD (
                            GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2
                            NS SOA RRSIG DNSKEY NSEC3PARAM )
                    RRSIG   NSEC3 TBD2 2 3600 (
                            20230901000000 20220901000000 65042 example.
                            FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
                            hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/
                            ie/knp7Edo/hxw== )

Authors' Addresses

         Cuiling Zhang
         CNNIC
         No.4 South 4th Street, Zhongguancun
         Beijing, 100190
         China

         Email: zhangcuiling@cnnic.cn

         Yukun Liu
         CNNIC
         No.4 South 4th Street, Zhongguancun
         Beijing, 100190
         China

         Email: liuyukun@cnnic.cn

         Feng Leng
         CNNIC
         No.4 South 4th Street, Zhongguancun
         Beijing, 100190
         China

         Email: lengfeng@cnnic.cn

         Qi Zhao
         CNNIC
         No.4 South 4th Street, Zhongguancun
         Beijing, 100190
         China

         Email: zhaoqi@cnnic.cn

         Zheng He
         CNNIC
         No.4 South 4th Street, Zhongguancun
         Beijing, 100190
         China

         Email: hezh@cnnic.cn