RFC 9563

SM2 Digital Signature Algorithm for DNSSEC

📅 published December 2024, from ietf

RFC 9563: SM2 Digital Signature Algorithm for DNSSEC 🎀

Okay bestie, here's the title block tea 💅

  • Request for Comments: 9563
  • Authors: C. Zhang, Y. Liu, F. Leng, Q. Zhao, and Z. He, all from CNNIC 🌸
  • Stream: Independent Submission, so it's not from the IETF stream 🦋
  • Category: Informational
  • Date: December 2024
  • ISSN: 2070-1721
  • Obsoletes and Updates: the title block doesn't list either, so this doc doesn't obsolete or update anything 🫶

Abstract ✨

So the big idea is that this doc explains how to use the SM2 digital signature algorithm and the SM3 hash algorithm for DNS Security (DNSSEC) 🔐

Heads up, it's an Independent Submission to the RFC series, so the IETF community hasn't reached consensus on it 🙈

Status of This Memo 📝

This one is not an Internet Standards Track spec. It's published just for informational purposes 🌈

It's a contribution to the RFC Series, and it's independent of any other RFC stream. The RFC Editor picked to publish it at their discretion and makes no statement about how useful it is for implementing or deploying. Documents approved by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 💅

You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9563 🔗

Copyright (c) 2024 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) as in effect on the date of publication of this document. Please read those carefully, because they spell out your rights and restrictions for this document 📜

Table of Contents 🗺️

1.  Introduction
2.  SM3 DS Records
3.  SM2 Parameters
4.  DNSKEY and RRSIG Resource Records for SM2
  4.1.  DNSKEY Resource Records
  4.2.  RRSIG Resource Records
5.  Support for NSEC3 Denial of Existence
6.  Example
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Authors' Addresses

1. Introduction 🌟

So DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. It uses cryptographic keys and digital signatures to provide authentication of DNS data. The DNSSEC signature algorithms are registered in the DNSSEC algorithm numbers registry [IANA] 🗂️

This document defines the DNSKEY and RRSIG resource records (RRs) for new signing algorithms. SM2 uses elliptic curves over 256-bit prime fields with the SM3 hash algorithm. (You can find a description of SM2 in GM/T 0003.2-2012 [GMT-0003.2] or ISO/IEC14888-3:2018 [ISO-IEC14888-3_2018], and a description of SM3 in GM/T 0004-2012 [GMT-0004] or ISO/IEC10118-3:2018 [ISO-IEC10118-3_2018].) It also defines the DS RR for the SM3 one-way hash algorithm. In the signing algorithm defined here, the size of the elliptic curve key matches the size of the hash output. Both are 256 bits 🦋

Real talk, a lot of implementations may not support SM2 signatures and SM3 digests. Section 5.2 of [RFC6840] specifies how to handle answers in that case 🥺

Caution: this spec is not a standard and doesn't have IETF community consensus 🚨 It uses cryptographic algorithms that are national standards for China, plus ISO/IEC standards (ISO/IEC 14888:3-2018 [ISO-IEC14888-3_2018] and ISO/IEC 10118:3-2018 [ISO-IEC10118-3_2018]). Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses. Be careful out there 💀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀 These are the only capitalized rule words in this doc, so when you see them in caps, they're doing the official BCP 14 job 💅

2. SM3 DS Records 🍓

Implementing SM3 in DNSSEC follows the way SHA-256 is implemented in [RFC4509], except the underlying algorithm is SM3 with digest type code 6 🧚

Generating an SM3 hash value is described in Section 5 of [GMT-0004], and it produces a 256-bit hash value 🔥

3. SM2 Parameters 🧮

Okay so verifying SM2 signatures requires the signer and the verifier to agree on the parameters they're using. The SM2 digital signature algorithm has been added to [ISO-IEC14888-3_2018]. The curve parameters used in this profile are below 👑

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 🔑

4.1. DNSKEY Resource Records 🗝️

SM2 public keys consist of a single value, called "P". In DNSSEC keys, P is a string of 64 octets that represents the uncompressed form of a curve point, "x | y". (Converting a point to an octet string is described in Section 4.2.8 of [GMT-0003.1].)

4.2. RRSIG Resource Records ✍️

An SM2 signature is the combination of two non-negative integers, called "r" and "s". Each integer is formatted as a simple octet string, and for DNSSEC they get glued into one longer octet string as the concatenation "r | s". (Converting the integers to bit strings is described in Section 4.2.1 of [GMT-0003.1].) Each integer MUST be encoded as 32 octets 💖

Process details are described in Section 6 of [GMT-0003.2] 🧠

The algorithm number for the DNSKEY and RRSIG resource records is 17, which is covered in the IANA Considerations section 🔢

Conformant implementations that create records to be put into the DNS MAY implement signing and verification for the SM2 digital signature algorithm. Conformant DNSSEC verifiers MAY implement verification for the above algorithm 🌸

5. Support for NSEC3 Denial of Existence 🙅‍♀️

This document does not define the 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 doesn't implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence 🦋

If you're using NSEC3, the iterations MUST be 0 and the salt MUST be an empty string, as recommended in Section 3.1 of [RFC9276] ✨

6. Example 🧁

The following is an example of SM2 keys and signatures in DNS zone file format. It includes a DNSKEY RR, an NSEC3PARAM RR, NSEC3 RRs with RRSIG RRs, and a DS RR 📄

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

example. 3600 IN DS 27215 17 6 (
   86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e
   )

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

example. 0  IN   NSEC3PARAM 1 0 10 AABBCCDD
example. 0  IN   RRSIG    NSEC3PARAM 17 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 17 2
    3600 (
    20230901000000 20220901000000 65042 example.
    FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
    hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )

[Example_Program] is an example program based on dnspython and gmssl. For convenience, it provides key generating, zone signing, zone validating, and DS RR generating functions 🛠️

7. IANA Considerations 📚

IANA has registered the following in the "Digest Algorithms" registry, within the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group 🎀

     +=======+=============+==========+===============+
     | Value | Digest Type | Status   | Reference     |
     +=======+=============+==========+===============+
     | 6     | SM3         | OPTIONAL | This document |
     +-------+-------------+----------+---------------+

                          Table 1

IANA has also registered the following in the "DNS Security Algorithm Numbers" registry, within the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group 🌈

+========+================+==========+=========+========+===========+
| Number | Description    | Mnemonic | Zone    | Trans. | Reference |
|        |                |          | Signing | Sec.   |           |
+========+================+==========+=========+========+===========+
| 17     | SM2 signing    | SM2SM3   | Y       | *      | This      |
|        | algorithm      |          |         |        | document  |
|        | with SM3       |          |         |        |           |
|        | hashing        |          |         |        |           |
|        | algorithm      |          |         |        |           |
+--------+----------------+----------+---------+--------+-----------+

                           Table 2

* There has been no determination of standardization of the use of this algorithm with Transaction Security 🙈

8. Security Considerations 🛡️

Okay, this part is serious, so listen up 👀 The security strength of SM2 depends on the size of the key. A longer key gives you stronger security strength. The security of ECC-based algorithms is also influenced by the curve they use 💅

Like any cryptographic algorithm, it may come to pass that a weakness is found in either SM2 or SM3. If that happens, the proper fix is crypto-agility. For DNSSEC, the right move would be to regenerate the 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 🚨 A suitable replacement algorithm should be both widely implemented and not known to have weaknesses 🫧

The security considerations listed in [RFC4509] apply here as well 🔐

9. References 📖

9.1. Normative References

9.2. Informative References

9.1. Normative References 💖

okay so these are the docs the spec leans on so hard that you can't really read it without them 📚✨ they're the foundation, bestie 🫶

9.2. Informative References 🌸

these ones are the "here's a real example you can poke at" section 🧚

Authors' Addresses 🎀

the crew behind this doc, all working out of CNNIC in Beijing 🇨🇳✨

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
📦 where this page comes from