Ed448 for DNSSEC
draft-ietf-curdle-dnskey-ed448-00

Abstract

This document describes how to specify Ed448 keys and signatures in DNS Security (DNSSEC). It uses the Edwards-curve Digital Security Algorithm (EdDSA) with the Ed448 parameter choice.

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 September 9, 2016.

Copyright Notice

Copyright (c) 2016 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.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. DNSKEY and RRSIG Resource Records for Ed448
• 4. Examples
• 5. Acknowledgements
• 6. IANA Considerations
• 7. Implementation Status
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

DNSSEC, which is broadly defined in [RFC4033], [RFC4034], and [RFC4035], uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm in use is RSA. [RFC5933] and [RFC6605] later defined the use of GOST and NIST specified elliptic curve cryptography in DNSSEC.

This document defines the use of DNSSEC's DS, DNSKEY, and RRSIG resource records (RRs) with a new signing algorithm, Edwards-curve Digital Signature Algorithm (EdDSA) with the Ed448 parameter choice. A more thorough description of EdDSA and Ed448 can be 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.

Ed448 has a 224-bit security target, which is considered to be equivalent in strength to RSA with ~15000-bit keys. Ed448 public keys are 456 bits (57 bytes) long while signatures are 912 bits (114 bytes) long.

The usage of elliptic curve cryptography in DNSSEC has advantages and disadvantages relative to RSA as already described in [RFC6605]. Even when compared to the use of RSA at reduced relative strengths (for instance, 1024- or 2048-bit RSA), Ed448 still requires substantially smaller keys and signatures. The authors of the study Making the Case for Elliptic Curves in DNSSEC [ECCSIZE] came to the conclusion that using elliptic curve cryptography rather than RSA in DNSSEC can effectively prevent fragmentation of DNSSEC responses as well as significantly reduce the amplification attack potential in DNSSEC.

Ed448 is provided for those applications with relaxed performance requirements and where there is a desire to hedge against analytical attacks on elliptic curves. Still signing with Ed448 is significantly faster than signing with either equivalently strong RSA or the two existing curves standardized for use with the ECDSA algorithm in DNSSEC, while the validation of RSA signatures is still significantly faster than the validation of Ed448 signatures. However, the authors of the TBD [ECCSPEED] study came to the conclusion that even if the deployment of elliptic curve cryptography in DNSSEC grows to cover 100% of the name space, a resolver will still be able to perform validation using a single CPU core.

2. Requirements Language

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].

3. DNSKEY and RRSIG Resource Records for Ed448

An Ed448 public key consists of a 57-byte value, which is encoded into the Public Key field of a DNSKEY resource record as a simple bit string. The generation of a public key is defined in Chapter 5.2.5 in [I-D.irtf-cfrg-eddsa].

An Ed448 signature consists of a 114-byte value, which is encoded into the Signature field of an RRSIG resource record as a simple bit string. The Ed448 signature algorithm is described in Chapter 5.2.6 and verification of the Ed448 signature is described in Chapter 5.2.7 in [I-D.irtf-cfrg-eddsa].

The algorithm number associated with the use of Ed448 in DS, DNSKEY and RRSIG resource records is TBD. This registration is fully defined in the IANA Considerations section.

4. Examples

This section needs an update after the algorithm for Ed448 is assigned.

 Private-key-format: v1.2
 Algorithm: TBD (ED448)
 PrivateKey: TBD

 example.com. 3600 IN DNSKEY 257 3 TBD (
         TBD )

 example.com. 3600 IN DS 3613 TBD 2 (
         TBD )

 www.example.com. 3600 IN A 192.0.2.1
 www.example.com. 3600 IN RRSIG A TBD 3 3600 (
         20150820000000 20150730000000 3613 example.com.
         TBD )
         

 Private-key-format: v1.2
 Algorithm: TBD (ED448)
 PrivateKey: TBD

 example.com. 3600 IN DNSKEY 257 3 TBD (
         TBD )

 example.com. 3600 IN DS 55648 TBD 2 (
         TBD )

 www.example.com. 3600 IN A 192.0.2.1
 www.example.com. 3600 IN RRSIG A TBD 3 3600 (
         20150820000000 20150730000000 35452 example.com.
         TBD )
         

5. Acknowledgements

Some of the material in this document is copied liberally from [RFC6605].

The authors of this document wish to thank Jan Vcelak, Pieter Lexis and Kees Monshouwer for a review of this document.

6. IANA Considerations

This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following entry has been added to the registry:

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

7. Implementation Status

(Note to the RFC Editor: please remove this entire section as well as the reference to RFC 6982 before publication.)

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

TODO: Fill out this section.

8. Security Considerations

The security level of Ed448 is slightly under the standard 128-bit level ([RFC7748]). Security considerations listed in [RFC7748] also apply to the usage of Ed448 in DNSSEC. 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

9.2. Informative References

Authors' Addresses