Network Working Group P. Hoffman
Internet-Draft VPN Consortium
Intended status: Standards Track January 25, 2010
Expires: July 29, 2010
Elliptic Curve DSA for DNSSEC
draft-hoffman-dnssec-ecdsa-01
Abstract
This document describes how to specify Elliptic Curve DSA keys and
signatures in DNSSEC. It lists curves of different sizes, and uses
the SHA-2 family of hashes for signatures.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 29, 2010.
Copyright Notice
Copyright (c) 2010 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
Hoffman Expires July 29, 2010 [Page 1]
Internet-Draft ECDSA for DNSSEC January 2010
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 BSD License.
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.
1. Introduction
DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035
([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and
digital signatures to provide authentication of DNS data. Currently,
the most popular signature algorithm is RSA with SHA-1, using keys
1024 or 2048 bits long.
This document defines the DNSKEY and RRSIG resource records (RRs) of
three new signing algorithms: ECDSA with curve P-224 and SHA-256,
ECDSA with curve P-256 and SHA-256, and ECDSA with curve P-384 and
SHA-384. It also defines the DS RR for the SHA-384 one-way hash
algorithm; the associated DS RR for SHA-256 is already defined in RFC
4509 [RFC4509].
Current estimates are that ECDSA with curve P-256 has an approximate
equivalent strength to RSA with 3072-bit keys. Using ECDSA with
curve P-256 in DNSSEC has some advantages and disadvantages relative
to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are
much shorter than RSA keys; at this size, the difference is 256
versus 3072 bits. Similarly, ECDSA signatures are much shorter than
RSA signatures. This is relevant because DNSSEC stores and transmits
both keys and signatures.
Signing with ECDSA is significantly faster than with RSA (over 20
times in some implementations). However, validating RSA signatures
is significantly faster than validating ECDSA signatures (about 5
times faster in some implementations).
Some of the material in this document is copied liberally from RFC
Hoffman Expires July 29, 2010 [Page 2]
Internet-Draft ECDSA for DNSSEC January 2010
5430 [RFC5430].
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. SHA-384 DS Records
SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 4634 [RFC4634],
and is similar to SHA-256 in many ways. The implementation of SHA-
384 in DNSSEC follows the implementation of SHA-256 as specified in
RFC 4509 except that the underlying algorithm is SHA-384, the digest
value is 48 bytes long, and the digest type code is {TBA-1}.
3. ECDSA Parameters
Verifying ECDSA signatures requires agreement between the signer and
the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists
some NIST-recommended elliptic curves. These are the same curves as
listed in RFC 5114 [RFC5114]. The curves used in this document are:
FIPS 186-3 RFC 5114
------------------------------------------------------------------
P-224 (Section D.1.2.2) 224-bit Random ECP Group (Section 2.5)
P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6)
P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7)
4. DNSKEY and RRSIG Resource Records for ECDSA
ECDSA public keys consist of a single value, called "Q" in FIPS
186-3. In DNSSEC keys, Q is a simple bit string that represents the
uncompressed form of a curve point.
The ECDSA signature is the combination of two non-negative integers,
called "r" and "s" in FIPS 186-3. The two integers, each of which is
formatted as a simple bit string, are combined into a single longer
bit string for DNSSEC as the concatenation "r | s".
The algorithm numbers associated with the DNSKEY and RRSIG resource
records are fully defined in the IANA Considerations section. They
are:
o DNSKEY and RRSIG RRs signifying ECDSA with the P-224 curve and
SHA-256 use the algorithm number {TBA-2}.
Hoffman Expires July 29, 2010 [Page 3]
Internet-Draft ECDSA for DNSSEC January 2010
o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and
SHA-256 use the algorithm number {TBA-3}.
o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and
SHA-384 use the algorithm number {TBA-4}.
Conformant implementations MUST support signing and/or validation of
signatures with both ECDSA with the P-256 curve and SHA-256, and with
ECDSA with the P-384 curve and SHA-384. (ECDSA with the P-224 curve
and SHA-256 is defined here for systems that want to have a strength
equivalence of RSA with 2048-bit keys, but is not required for
conformance.)
5. Support for NSEC3 Denial of Existence
RFC 5155 [RFC5155] defines new algorithm identifiers for existing
signing algorithms, to indicate that zones signed with these
algorithm identifiers can use NSEC3 as well as NSEC records to
provide denial of existence. That mechanism was chosen to protect
implementations predating RFC 5155 from encountering resource records
they could not know about. This document does not define such
algorithm aliases.
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. Examples
[[ To be filled in later. ]]
7. IANA Considerations
This document updates the IANA registry for digest types in DS
records, currently called "Delegation Signer Resource Record, Digest
Algorithms". The following entry is added:
Value {TBA-1}
Digest Type SHA-384
Status OPTIONAL
This document updates the IANA registry "Domain Name System Security
Hoffman Expires July 29, 2010 [Page 4]
Internet-Draft ECDSA for DNSSEC January 2010
(DNSSEC) Algorithm Numbers". The following three entries are added
to the registry:
Number {TBA-2}
Description ECDSA Curve P-224 with SHA-256
Mnemonic ECDSAP224SHA256
Zone Signing Y
Trans. Sec. *
Reference This document
Number {TBA-3}
Description ECDSA Curve P-256 with SHA-256
Mnemonic ECDSAP256SHA256
Zone Signing Y
Trans. Sec. *
Reference This document
Number {TBA-4}
Description ECDSA Curve P-384 with SHA-384
Mnemonic ECDSAP384SHA384
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 strength of ECDSA with curve P-224, P-256 or P-384
is generally considered to be equivalent to half the size of the key,
or 112 bits, 128 bits, and 192 bits, respectively. Such an
assessment could, of course, change in the future if new attacks that
work better than the ones known today are found.
9. References
9.1. Normative References
[FIPS-180-3]
National Institute of Standards and Technology, U.S.
Department of Commerce, "Secure Hash Standard (SHS)",
FIPS 180-3, October 2008.
[FIPS-186-3]
National Institute of Standards and Technology, U.S.
Hoffman Expires July 29, 2010 [Page 5]
Internet-Draft ECDSA for DNSSEC January 2010
Department of Commerce, "Digital Signature Standard",
FIPS 186-3, June 2009.
[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.
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114,
January 2008.
[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
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile
for Transport Layer Security (TLS)", RFC 5430, March 2009.
Appendix A. Change History
This entire section should be removed before publication as an RFC.
A.1. Changes betweeen draft-hoffman-dnssec-ecdsa-00 and -01
Numerous editorial fixes from Alfred Hoenes.
In the IANA Considerations, used the same wording about TSIG as is
used in draft-ietf-dnsext-dnssec-rsasha256-14: "There has been no
Hoffman Expires July 29, 2010 [Page 6]
Internet-Draft ECDSA for DNSSEC January 2010
determination of standardization of the use of this algorithm with
Transaction Security."
Author's Address
Paul Hoffman
VPN Consortium
Email: paul.hoffman@vpnc.org
Hoffman Expires July 29, 2010 [Page 7]