Internet DRAFT - draft-deng-sec-dnsec-alg

draft-deng-sec-dnsec-alg






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, <http://www.ics.uci.edu/~fielding/pubs/
              dissertation/rest_arch_style.htm>.

   [SM3]      Chinese Commercial Cryptography Administration Office, "",
              December 2010,
              <http://www.oscca.gov.cn/News/201012/News_1199.htm>.


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]