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]
