draft-ietf-curdle-dnskey-ed25519-00.txt   draft-ietf-curdle-dnskey-ed25519-01.txt 
Internet Engineering Task Force O. Sury Internet Engineering Task Force O. Sury
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track R. Edmonds Intended status: Standards Track R. Edmonds
Expires: July 31, 2016 Farsight Security, Inc. Expires: August 19, 2016 Farsight Security, Inc.
January 28, 2016 February 16, 2016
Ed25519 for DNSSEC Ed25519 for DNSSEC
draft-ietf-curdle-dnskey-ed25519-00 draft-ietf-curdle-dnskey-ed25519-01
Abstract Abstract
This document describes how to specify Ed25519 keys and signatures in This document describes how to specify Ed25519 keys and signatures in
DNS Security (DNSSEC). It uses the Ed25519 instance of the Edwards- DNS Security (DNSSEC). It uses the Edwards-curve Digital Security
curve Digital Signature Algorithm (EdDSA). Algorithm (EdDSA) with the Ed25519 parameter choice.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2016. This Internet-Draft will expire on August 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
1. Introduction 1. Introduction
DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and
[RFC4035], uses cryptographic keys and digital signatures to provide [RFC4035], uses cryptographic keys and digital signatures to provide
authentication of DNS data. Currently, the most popular signature authentication of DNS data. Currently, the most popular signature
algorithm in use is RSA. [RFC5933] and [RFC6605] later defined the algorithm in use is RSA. [RFC5933] and [RFC6605] later defined the
use of GOST and NIST specified elliptic curve cryptography in DNSSEC. use of GOST and NIST specified elliptic curve cryptography in DNSSEC.
This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG
resource records (RRs) with a new signing algorithm: the Ed25519 resource records (RRs) with a new signing algorithm, Edwards-curve
instance of the Edwards-curve Digital Signature Algorithm. A more Digital Signature Algorithm (EdDSA) with the Ed25519 parameter
thorough description of Ed25519 can be found in choice. A more thorough description of EdDSA and Ed25519 can be
[I-D.irtf-cfrg-eddsa]. found in [I-D.irtf-cfrg-eddsa].
Concerns about the real-world security of elliptic curve cryptography
have emerged since ECDSA was standardized for DNSSEC. The only two
curves standardized for use with ECDSA in DNSSEC, NIST P-256 and NIST
P-384, fail several of the [SafeCurves] security criteria and are
considered "unsafe". This document adds an additional elliptic curve
algorithm and parameter choice to DNSSEC, allowing additional
flexibility.
There are three main advantages of the EdDSA algorithm: It does not
require the use of a unique random number for each signature, there
are no padding or truncation issues as with ECDSA, and it is more
resilient to side-channel attacks.
Ed25519 has a 128-bit security target, which is considered to be Ed25519 has a 128-bit security target, which is considered to be
equivalent in strength to RSA with ~3000-bit keys. Ed25519 public equivalent in strength to RSA with ~3000-bit keys. Ed25519 public
keys are 256 bits (32 bytes) long while signatures are 512 bits (64 keys are 256 bits (32 bytes) long while signatures are 512 bits (64
bytes) long. bytes) long.
The usage of the Ed25519 algorithm in DNSSEC has advantages and The usage of elliptic curve cryptography in DNSSEC has advantages and
disadvantages relative to RSA. Ed25519 keys are much shorter than disadvantages relative to RSA as already described in [RFC6605].
RSA keys. At comparable strengths, Ed25519 keys are 352 bytes Even when compared to the use of RSA at reduced relative strengths
smaller than RSA-3072 keys. Similarly, an Ed25519 signature saves (for instance, 1024- or 2048-bit RSA), Ed25519 still requires
320 bytes over an RSA-3072 signature. substantially smaller keys and signatures. The authors of the study
Making the Case for Elliptic Curves in DNSSEC [ECCSIZE] came to the
However, DNSSEC with RSA is not commonly deployed on the Internet conclusion that using elliptic curve cryptography rather than RSA in
with signatures as large as 3072 bits. [RFC6781] contemplates the DNSSEC can effectively prevent fragmentation of DNSSEC responses as
routine use of RSA-1024 and RSA-2048 in DNSSEC. Even when compared well as significantly reduce the amplification attack potential in
to the use of RSA at reduced strengths, Ed25519 still provides DNSSEC.
substantially smaller keys and signatures. The authors of Making the
Case for Elliptic Curves in DNSSEC [ECCSIZE] study comes to
conclusion that using Eliptic Curves in DNSSEC can effectively
prevent fragmentation of DNSSEC responses as well as significantly
reduce the am- plification attack potential in DNSSEC.
Signing with Ed25519 is significantly faster than signing with Signing with Ed25519 is significantly faster than signing with either
equivalently strong RSA, and it is also faster than signing with the equivalently strong RSA or the two existing curves standardized for
existing ECDSA algorithms defined in [RFC6605]. However, the use with the ECDSA algorithm in DNSSEC, while the validation of RSA
validation of RSA signatures is significantly faster than the signatures is still significantly faster than the validation of
validation of Ed25519 signatures. The authors of Not Yet Published Ed25519 signatures. However, the authors of the TBD [ECCSPEED] study
[ECCSPEED] study comes to conclusion that even if DNSSEC deployment came to the conclusion that even if the deployment of elliptic curve
grows to cover 100% of the name space, a resolver will be able to cryptography in DNSSEC grows to cover 100% of the name space, a
cope with the CPU cycles required to perform validation on a single resolver will still be able to perform validation using a single CPU
core. core.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. DNSKEY and RRSIG Resource Records for Ed25519 3. DNSKEY and RRSIG Resource Records for Ed25519
skipping to change at page 6, line 7 skipping to change at page 6, line 7
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
TODO: Fill out this section. TODO: Fill out this section.
8. Security Considerations 8. Security Considerations
The security level of Ed25519 is is slightly under the standard The security level of Ed25519 is slightly under the standard 128-bit
128-bit level ([RFC7748]). Security considerations listed in level ([RFC7748]). Security considerations listed in [RFC7748] also
[RFC7748] also apply to the usage of Ed25519 in DNSSEC. Such an apply to the usage of Ed25519 in DNSSEC. Such an assessment could,
assessment could, of course, change in the future if new attacks that of course, change in the future if new attacks that work better than
work better than the ones known today are found. the ones known today are found.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.irtf-cfrg-eddsa] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-02
(work in progress), January 2016. (work in progress), January 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements",
4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>. <http://www.rfc-editor.org/info/rfc4033>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
skipping to change at page 7, line 14 skipping to change at page 7, line 14
[ECCSPEED] [ECCSPEED]
van Rijswijk-Deij, R. and K. Hageman, "TBD", 2016, <TBD>. van Rijswijk-Deij, R. and K. Hageman, "TBD", 2016, <TBD>.
[RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of [RFC5933] Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of
GOST Signature Algorithms in DNSKEY and RRSIG Resource GOST Signature Algorithms in DNSKEY and RRSIG Resource
Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July
2010, <http://www.rfc-editor.org/info/rfc5933>. 2010, <http://www.rfc-editor.org/info/rfc5933>.
[RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI Signature Algorithm (DSA) for DNSSEC", RFC 6605,
10.17487/RFC6605, April 2012, DOI 10.17487/RFC6605, April 2012,
<http://www.rfc-editor.org/info/rfc6605>. <http://www.rfc-editor.org/info/rfc6605>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
Operational Practices, Version 2", RFC 6781, DOI 10.17487/
RFC6781, December 2012,
<http://www.rfc-editor.org/info/rfc6781>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, DOI Code: The Implementation Status Section", RFC 6982,
10.17487/RFC6982, July 2013, DOI 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <http://www.rfc-editor.org/info/rfc6982>.
[SafeCurves]
Bernstein, D. and T. Lange, "SafeCurves: choosing safe
curves for elliptic-curve cryptography", 2016,
<http://safecurves.cr.yp.to/>.
Authors' Addresses Authors' Addresses
Ondrej Sury Ondrej Sury
CZ.NIC CZ.NIC
Milesovska 1136/5 Milesovska 1136/5
Praha 130 00 Praha 130 00
CZ CZ
Phone: +420 222 745 111 Phone: +420 222 745 111
Email: ondrej.sury@nic.cz Email: ondrej.sury@nic.cz
Robert Edmonds Robert Edmonds
Farsight Security, Inc. Farsight Security, Inc.
155 Bovet Rd #476 177 Bovet Rd #180
San Mateo, California 94402 San Mateo, California 94402
US US
Phone: +1 650 489 7919 Phone: +1 650 489 7919
Email: edmonds@fsi.io Email: edmonds@fsi.io
 End of changes. 15 change blocks. 
52 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/