RFC 8080

Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC

πŸ“… published February 2017, from ietf

RFC 8080: Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC πŸŽ€

okay bestie, let's get into it πŸ’… here's the title block tea:

  • Number: RFC 8080
  • Authors: O. Sury (CZ.NIC) and R. Edmonds (Fastly) 🧚
  • Category: Standards Track, so this is an official IETF standard πŸ‘‘
  • ISSN: 2070-1721
  • Date: February 2017
  • Obsoletes/Updates: the title block doesn't list any RFCs it obsoletes or updates. The only "update" is to an IANA registry, which is covered in Section 7 πŸ“‹

Abstract ✨

okay so this doc explains how to use Edwards-curve Digital Security Algorithm (EdDSA) keys and signatures in DNS Security (DNSSEC) πŸ” it uses EdDSA with two curves: Ed25519 and Ed448. the vibes are very cryptographic and very iconic πŸ’œ

Status of This Memo πŸ“

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). for more on Internet Standards, check Section 2 of RFC 7841 🫢

you can find info on the current status, any errata, and how to give feedback at http://www.rfc-editor.org/info/rfc8080 ✨

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved πŸ’…

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully because they spell out your rights and restrictions πŸ™ˆ code components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License πŸ“

Table of Contents πŸ—‚οΈ

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
3.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . .   2
4.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . .   3
5.  Algorithm Number for DS, DNSKEY, and RRSIG Resource Records .   3
6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
  6.1.  Ed25519 Examples  . . . . . . . . . . . . . . . . . . . .   3
  6.2.  Ed448 Examples  . . . . . . . . . . . . . . . . . . . . .   4
7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   7
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1. Introduction 🌸

okay so DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. it uses cryptographic keys and digital signatures to give authentication of DNS data πŸ” right now the most popular signature algorithm in use is RSA. GOST [RFC5933] and NIST-specified elliptic curve cryptography [RFC6605] are also standardized 🧚

[RFC8032] describes the elliptic curve signature system Edwards-curve Digital Signature Algorithm (EdDSA) and recommends two curves, Ed25519 and Ed448 πŸ¦‹

so this doc defines how DNSSEC's DS, DNSKEY, and RRSIG resource records (RRs) work with a new signing algorithm, EdDSA, using a choice of two curves: Ed25519 and Ed448 ✨

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 Resource Records πŸ”‘

an Ed25519 public key is a 32-octet value. it gets 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 Section 5.1.5 of [RFC8032] 🌈

an Ed448 public key is a 57-octet value. it gets 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 Section 5.2.5 of [RFC8032] ✨

4. RRSIG Resource Records πŸ¦‹

an Ed25519 signature is a 64-octet value. it gets encoded into the Signature field of an RRSIG resource record as a simple bit string πŸ’… the Ed25519 signature algorithm and verification of the Ed25519 signature are described in Sections 5.1.6 and 5.1.7 of [RFC8032], respectively πŸ”₯

an Ed448 signature is a 114-octet value. it gets encoded into the Signature field of an RRSIG resource record as a simple bit string πŸ’€ the Ed448 signature algorithm and verification of the Ed448 signature are described in Sections 5.2.6 and 5.2.7 of [RFC8032], respectively πŸ‘‘

5. Algorithm Number for DS, DNSKEY, and RRSIG Resource Records πŸ”’

the algorithm number for Ed25519 in DS, DNSKEY, and RRSIG resource records is 15 πŸ“ the algorithm number for Ed448 in those same records is 16 πŸ’œ this registration is fully defined in the IANA Considerations section πŸ“‹

6. Examples 🧁

6.1. Ed25519 Examples 🌟

here's the first Ed25519 example, bestie 🫢

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: ODIyNjAzODQ2MjgwODAxMjI2NDUxOTAyMDQxNDIyNjI=

example.com. 3600 IN DNSKEY 257 3 15 (
             l02Woi0iS8Aa25FQkUd9RMzZHJpBoRQwAQEX1SxZJA4= )

example.com. 3600 IN DS 3613 15 2 (
             3aa5ab37efce57f737fc1627013fee07bdf241bd10f3b1964ab55c78e79
             a304b )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 3613 example.com. (
             Edk+IB9KNNWg0HAjm7FazXyrd5m3Rk8zNZbvNpAcM+eysqcUOMIjWoevFkj
             H5GaMWeG96GUVZu6ECKOQmemHDg== )

and here's the second Ed25519 example πŸ’–

Private-key-format: v1.2
Algorithm: 15 (ED25519)
PrivateKey: DSSF3o0s0f+ElWzj9E/Osxw8hLpk55chkmx0LYN5WiY=

example.com. 3600 IN DNSKEY 257 3 15 (
             zPnZ/QwEe7S8C5SPz2OfS5RR40ATk2/rYnE9xHIEijs= )

example.com. 3600 IN DS 35217 15 2 (
             401781b934e392de492ec77ae2e15d70f6575a1c0bc59c5275c04ebe80c
             6614c )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 35217 example.com. (
             5LL2obmzdqjWI+Xto5eP5adXt/T5tMhasWvwcyW4L3SzfcRawOle9bodhC+
             oip9ayUGjY9T/rL4rN3bOuESGDA== )

6.2. Ed448 Examples πŸ¦‹

now the Ed448 examples, which are giving big cryptographic main character energy πŸ‘‘

Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: xZ+5Cgm463xugtkY5B0Jx6erFTXp13rYegst0qRtNsOYnaVpMx0Z/c5EiA9x
            8wWbDDct/U3FhYWA

example.com. 3600 IN DNSKEY 257 3 16 (
             3kgROaDjrh0H2iuixWBrc8g2EpBBLCdGzHmn+G2MpTPhpj/OiBVHHSfPodx
             1FYYUcJKm1MDpJtIA )

example.com. 3600 IN DS 9713 16 2 (
             6ccf18d5bc5d7fc2fceb1d59d17321402f2aa8d368048db93dd811f5cb2
             b19c7 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 9713 example.com. (
             Nmc0rgGKpr3GKYXcB1JmqqS4NYwhmechvJTqVzt3jR+Qy/lSLFoIk1L+9e3
             9GPL+5tVzDPN3f9kAwiu8KCuPPjtl227ayaCZtRKZuJax7n9NuYlZJIusX0
             SOIOKBGzG+yWYtz1/jjbzl5GGkWvREUCUA )
Private-key-format: v1.2
Algorithm: 16 (ED448)
PrivateKey: WEykD3ht3MHkU8iH4uVOLz8JLwtRBSqiBoM6fF72+Mrp/u5gjxuB1DV6NnPO
            2BlZdz4hdSTkOdOA

example.com. 3600 IN DNSKEY 257 3 16 (
             kkreGWoccSDmUBGAe7+zsbG6ZAFQp+syPmYUurBRQc3tDjeMCJcVMRDmgcN
             Lp5HlHAMy12VoISsA )

example.com. 3600 IN DS 38353 16 2 (
             645ff078b3568f5852b70cb60e8e696cc77b75bfaaffc118cf79cbda1ba
             28af4 )

example.com. 3600 IN MX 10 mail.example.com.

example.com. 3600 IN RRSIG MX 3 3600 (
             1440021600 1438207200 38353 example.com. (
             +JjANio/LIzp7osmMYE5XD3H/YES8kXs5Vb9H8MjPS8OAGZMD37+LsCIcjg
             5ivt0d4Om/UaqETEAsJjaYe56CEQP5lhRWuD2ivBqE0zfwJTyp4WqvpULbp
             vaukswvv/WNEFxzEYQEIm9+xDlXj4pMAMA )

7. IANA Considerations πŸ“‹

this doc updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers" 🌈 these entries got added to the registry:

              +--------------+----------+----------+
              | Number       | 15       | 16       |
              | Description  | Ed25519  | Ed448    |
              | Mnemonic     | ED25519  | ED448    |
              | Zone Signing | Y        | Y        |
              | Trans. Sec.  | *        | *        |
              | Reference    | RFC 8080 | RFC 8080 |
              +--------------+----------+----------+
* There has been no determination of standardization of the use of
             this algorithm with Transaction Security.

8. Security Considerations πŸ”

this section is seriously important, bestie, so read it carefully πŸ™ˆ

the security considerations of [RFC8032] and [RFC7748] get inherited when you use Ed25519 and Ed448 in DNSSEC πŸ’œ

Ed25519 is intended to operate at around the 128-bit security level, and Ed448 at around the 224-bit security level. a sufficiently large quantum computer would be able to break both πŸ’€ reasonable projections of what classical computers can do conclude that Ed25519 is perfectly safe ✨ Ed448 is provided for applications with relaxed performance requirements and where there's a desire to hedge against analytical attacks on elliptic curves πŸ›‘οΈ

these assessments could change in the future if new attacks that work better than the ones known today are found 😭

a private key used for a DNSSEC zone MUST NOT be used for any other purpose than for that zone. otherwise, cross-protocol or cross-application attacks are possible 🚨

9. References πŸ“š

9.1. Normative References πŸ’–

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "DNS Security Introduction and Requirements",
           RFC 4033, DOI 10.17487/RFC4033, March 2005,
           <http://www.rfc-editor.org/info/rfc4033>.

[RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Resource Records for the DNS Security Extensions",
           RFC 4034, DOI 10.17487/RFC4034, March 2005,
           <http://www.rfc-editor.org/info/rfc4034>.

[RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
           Rose, "Protocol Modifications for the DNS Security
           Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
           <http://www.rfc-editor.org/info/rfc4035>.

[RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
           for Security", RFC 7748, DOI 10.17487/RFC7748, January
           2016, <http://www.rfc-editor.org/info/rfc7748>.

[RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
           Signature Algorithm (EdDSA)", RFC 8032,
           DOI 10.17487/RFC8032, January 2017,
           <http://www.rfc-editor.org/info/rfc8032>.

9.2. Informative References πŸ¦‹

[RFC5933]  Dolmatov, V., Ed., Chuprina, A., and I. Ustinov, "Use of
           GOST Signature Algorithms in DNSKEY and RRSIG Resource
           Records for DNSSEC", RFC 5933, DOI 10.17487/RFC5933, July
           2010, <http://www.rfc-editor.org/info/rfc5933>.

[RFC6605]  Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital
           Signature Algorithm (DSA) for DNSSEC", RFC 6605,
           DOI 10.17487/RFC6605, April 2012,
           <http://www.rfc-editor.org/info/rfc6605>.

Acknowledgements 🫢

Okay bestie, so some of the material in this document is copied liberally from [RFC6605] πŸ’œ Credit where it's due!

The authors of this document wish to thank Jan Vcelak, Pieter Lexis, Kees Monshouwer, Simon Josefsson, Paul Hoffman, and others for reviewing this document. They're absolute legends πŸ‘‘βœ¨


Authors' Addresses πŸ¦‹

Ondrej Sury CZ.NIC Milesovska 1136/5 Praha 130 00 Czech Republic

Email: ondrej.sury@nic.cz

Robert Edmonds Fastly Atlanta, Georgia United States of America

Email: edmonds@mycre.ws

πŸ“¦ where this page comes from