EdDSA-gebaseerde algoritmen voor DNSSEC in ontwikkeling

Digitale handtekeningen in het DNSSEC-protocol

Het DNSSEC-protocol is volledig gebaseerd op digitale handtekeningen: Digitale handtekeningen (RRSIG-records) onder de DNS-antwoorden (de RRsets) bevestigen de authenticiteit van die responses. Een digitale handtekening (een DS-record) onder de publieke sleutel (#1) van de ondertekenaar (een DNSKEY-record) bevestigt de authenticiteit van zijn handtekeningen. En een digitale handtekening onder de publieke sleutel (#2) van de ondertekenaar van die publieke sleutel (#1) bevestigt die publieke sleutel (#2) weer. Zo wordt bovenop de bestaande DNS-infrastructuur een zogenaamde chain of trust opgebouwd die eindigt bij de rootzone. Die allerlaatste handtekening wordt gezet met een sleutelpaar dat per definitie wordt vertrouwd. De publieke sleutel daarvan is als trust anchor integraal onderdeel van alle resolversoftware.

Het diagram hieronder laat zien hoe voor de domeinnaam example.nl de hele chain of trust naar de rootzone wordt opgebouwd.

Publieke en geheime sleutels

Digitale handtekeningen zijn op hun beurt weer gebaseerd op public-key-cryptografie en hash-functies: Eerst wordt een hash (een digitaal uittreksel) van een elektronisch document (in dit geval een RRset) gemaakt. Die hash wordt vervolgens versleuteld met een private sleutel. Het resultaat is een digitale handtekening specifiek voor dat document.

Bij elke (geheime) private sleutel hoort een publieke sleutel die bij iedereen bekend is (in dit geval gepubliceerd als DNSKEY-record). Deze publieke sleutel kan door iedereen gebruikt worden om te verifiëren dat de betreffende handtekening inderdaad bij dit specifieke document hoort en alleen door de eigenaar van de publieke sleutel gezet kan zijn; hij is immers de enige die de bijbehorende private sleutel kent.

Pubkey-algoritmen en hash-functies

Zowel voor de hashes als voor de public-key-cryptografie bestaan verschillende algoritmen. DNSSEC ondersteunt verschillende combinaties van die 2. Voordat je je zones ondertekent, moet je dus kiezen welke combinatie van pubkey-algoritme en hash-functie je daarvoor gaat gebruiken.

Daarnaast is er nog de aparte keuze van een hash-functie voor de DS/CDS-records.

Op dit moment zijn er een stuk of 15 cryptografische pubkey/hash-combinaties voor DNSSEC gedefinieerd. Het complete overzicht vind je op de website van IANA:

https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml

In de loop der tijd vallen bestaande algoritmen af (deprecated, want verouderd of onveilig) en komen er nieuwe algoritmen bij. Specifiek voor DNSSEC zien we de laatste ontwikkelingen in (toegepaste) cryptografie terug in de publicatie van RFC 8624 als opvolger van RFC 6944.

Aanbevelingen RFC 8624

RFC 8624 geeft een aantal aanbevelingen voor de keuze en toepassing van de verschillende DNSSEC-algoritmen:

• Algoritme nummer 13 (ECDSA Curve P-256 with SHA-256) wordt aanbevolen.

• Naast nummer 8 (RSA/SHA-256), dat lange tijd de standaard was en nu langzaam uitgefaseerd wordt ten gunste van de ECDSA-gebaseerde algoritmen.

• Nummer 10 (RSA/SHA-512), een variant van nummer 8, is nooit populair geworden en wordt inmiddels ontraden.

• Nummer 14 (ECDSA Curve P-384 with SHA-384) is een sterkere versie van nummer 13, maar is op dit moment nog niet nodig.

• De kans is echter groot dat in de toekomst niet nummer 14 maar een

  EdDSA-gebaseerd algoritme (nummer 15, Ed25519) de opvolger van nummer 13 gaat worden.

Kortom: Ga je nu met DNSSEC aan de slag, dan kies je voor algoritme nummer 13. Gebruik je al DNSSEC maar dan gebaseerd op algoritme nummer 8 (of ouder), stap dan op niet al te lange termijn over naar nummer 13.

Hieronder bespreken we de verschillende algoritmen in meer detail.

Niet meer gebruiken

Algoritme nummer 1 (RSA/MD5) moet je in ieder geval niet meer gebruiken vanwege de bewezen onveiligheid van de MD5 hash-functie.

De SHA-1 hash-functie is al in 2011 door NIST afgekeurd voor gebruik in digitale handtekeningen. "SHA-1 is te zwak", zegt Marc Stevens, cryptograaf bij CWI en bekend als kraker van MD5 en SHA-1.

Inmiddels wordt ook de toepassing van deze hash-functie in DNSSEC officieel afgeraden (in RFC 8624). Het gaat dan om algoritmen nummer 3 (DSA/SHA1), 5 (RSA/SHA-1), 6 (DSA-NSEC3-SHA1) en 7 (RSASHA1-NSEC3-SHA1).

Algoritmen nummer 8 en 10 zijn beide gebaseerd op de SHA-2 hash-functie, die op dit moment zonder meer veilig voor gebruik is. Nummer 8 (RSA/SHA-256) was lange tijd de standaard en wordt nu langzaam uitgefaseerd ten gunste van de ECDSA-gebaseerde algoritmen. Nummer 10 (RSA/SHA-512), een variant van nummer 8, is nooit populair geworden en wordt inmiddels ontraden (in RFC 8624).

Verschillende public-key algoritmen

De veiligheid van de verschillende public-key algoritmen –DSA, RSA en ECDSA– is gebaseerd op de wiskundige moeilijkheid om discrete logaritmen uit te rekenen (in complexiteitstermen: "onberekenbaar in redelijke tijd").

Het RSA-algoritme kan echter via een kortere weg gebroken worden, namelijk door het product (de vermenigvuldiging) van 2 grote priemgetallen weer in zijn factoren te ontbinden (priemfactorisatie). Daardoor zijn voor een veilig gebruik van RSA aanzienlijk langere sleutels nodig, wat dit algoritme minder geschikt maakt voor toepassing bij DNSSEC.

DSA is door de Amerikaanse overheid ontwikkeld als vrije tegenhanger van het proprietary RSA-algoritme. Belangrijk aandachtspunt bij de inzet van DSA is dat het enorm kwetsbaar is bij gebruik van een slechte random-generator.

De achterliggende wiskunde voor elliptic curve is een stuk ingewikkelder dan priemfactorisatie om uit te leggen, maar voor de liefhebbers wordt het idee achter ECC hier door Ars Technica op een toegankelijke manier uit de doeken gedaan.

Voordelen ECDSA

ECDSA (Elliptic Curve Digital Signature Algorithm) is een algoritme voor de implementatie van het public-key protocol, net zoals de traditionele DSA- en RSA-algoritmen dat zijn. Zoals de naam al aangeeft is ECDSA gebaseerd op Elliptic Curve Cryptografie (ECC), dat belangrijke voordelen biedt bij de toepassing voor DNSSEC.

Specifiek van belang voor DNSSEC is dat de digitale handtekeningen voor ECDSA ongeveer even lang zijn als die voor DSA, maar dat de publieke sleutels veel korter zijn. Ter illustratie: een veiligheidsniveau van 128 bits – dat wil zeggen dat er 2^128 'brute force'-operaties nodig zijn om een versleuteling te kraken – wordt op dit moment als een veilig minimum beschouwd. Om dat veiligheidsniveau te halen is bij ECDSA een publieke sleutel van 256 bits nodig (2 keer de gewenste veiligheid), terwijl dit voor DSA en RSA minstens 2.048 bits is. De lengte van de handtekeningen is voor ECDSA en DSA allebei ongeveer viermaal de lengte van de gewenste veiligheid, in dit voorbeeld dus 512 bits, terwijl die voor RSA op meer dan 2.048 bits zit.

Voor 128 bits security:

Bovendien zijn de handtekeningen voor ECDSA veel sneller te berekenen dan die voor RSA (een orde grootte) en DSA (een veelvoud). Alleen voor het controleren (valideren) van de handtekeningen is RSA veel sneller dan de andere 2 algoritmen, zelfs een orde grootte ten opzichte ECDSA. Dat laatste is het enige, maar wel een aanzienlijk nadeel van de toepassing van ECDSA voor DNSSEC.

Beste keuze

De zojuist besproken verschillen in algoritmische eigenschappen maken ECDSA op dit moment de beste keuze voor DNSSEC. Ten eerste kunnen niet alleen de digitale handtekeningen handtekeningen (de RRSIG-records) maar ook de publieke sleutels (de DNSKEY-records) onder de 512 bytes in lengte blijven. Daarmee hoeft voor het transport van deze records niet te worden overgeschakeld van traditionele DNS-pakketten naar (langere) EDNS-pakketten.

Ten tweede blijft bij ECDSA het verschil in grootte tussen de DNS-vraag (de lookup query) en het antwoord (de response) beperkt. Juist deze "opblaasfactor" van DNSSEC wordt immers regelmatig misbruikt voor het uitvoeren van DDoS/amplificatie-aanvallen.

Tenslotte vraagt het uitrekenen van een digitale handtekening (de ondertekening) bij ECDSA veel minder verwerkingskracht dan bij RSA. Dat is een groot voordeel voor registrars en andere DNS-operators die in bulk de domeinen voor hun klanten ondertekenen. Nadeel aan client-zijde is dat de validatie van een ECDSA-handtekening door de resolver langer duurt, en dat is vooral van belang voor het gebruik van DNSSEC op mobiele apparaten, die in het algemeen maar beperkte rekenkracht en batterijcapaciteit aan boord hebben.

ECDSA-gebaseerde algoritmen in de .nl-zone

Sinds maart 2016 kunnen registrars ook DNSKEY-records gebaseerd op algoritmen nummer 13 en 14 bij SIDN aanleveren voor publicatie in de .nl-zone (in de vorm van een hash-waarde in een DS-record). Daarmee werd het voor registrars mogelijk om de domeinen van hun klanten met ECDSA te ondertekenen.

Vanaf dat moment konden dus ook .nl-domeinnamen ondergebracht bij CloudFlare– zo'n 20.000 stuks – van DNSSEC worden voorzien. Deze CDN-aanbieder ondertekent de domeinnamen van zijn klanten namelijk al vanaf de start standaard met algoritme nummer 13.

Inmiddels worden algoritmen nummer 13 en 14 ook breed ondersteund aan zowel client- (resolver) als serverzijde. In de grafiek hieronder kun je zien dat algoritme nummer 7 inmiddels nagenoeg verdwenen is uit de .nl-zone, en dat algoritme nummer 8 langzaam verdrongen wordt door nummer 13. Op dit moment (februari 2023) gebruikt 57 procent van de .nl-domeinnamen algoritme nummer 13 en 43 procent nummer 8.

https://images.ctfassets.net/yj8364fopk6s/UfHHqBQoapqMtaaGmzGvq/8676191f12a5af4852e497713a6491f7/stats.sidnlabs.nl-DNSSECalgoritmen-20240826.png

Voor het .nl-topleveldomein zelf gebruiken we op dit moment (februari 2023) ook nog algoritme nummer 8. Het is de bedoeling om later dit jaar over te stappen naar algoritme nummer 13.

ECDSA-algoritme nummer 14

DNSSEC-algoritme nummer 14 is net als nummer 13 gebaseerd op ECDSA, maar heeft een sleutellengte (384 in plaats van 256 bits) die deze beveiliging geschikt maakt voor de allerzwaarste toepassingen.

Omdat een sterkere beveiliging langere sleutels en handtekeningen vereist en dus meer verwerkingskracht en verkeer kost, komen we algoritme nummer 14 zelden tegen. Op dit moment (februari 2023) gebruikt slechts een minuscule 0,05 procent van de .nl-domeinnamen algoritme nummer 14. De verwachting is bovendien dat niet nummer 14 maar een EdDSA-gebaseerd algoritme (nummer 15, Ed25519; zie verderop) de opvolger van nummer 13 gaat worden.

ECDSA en de toekomst van DNSSEC

Het grote snelheidsverschil in ondertekenen tussen ECDSA en RSA maakt het in de toekomst waarschijnlijk mogelijk om de digitale handtekening onder een denial-of-existence on-the-fly te genereren – dat wil zeggen als onderdeel van het samenstellen van de DNS-response. Daarmee ontstaat een dynamisch alternatief voor NSEC(3) waarmee het 'zone walking'-veiligheidsprobleem definitief opgelost zou zijn.

Deze 'DNSSEC white lies'-technologie (zie RFC 4470 en 4471) wordt met name gepropageerd door CDN-aanbieder CloudFlare.

EdDSA-gebaseerde algoritmen

Relatieve nieuwkomer in de DNSSEC-wereld is het EdDSA-algoritme (Edwards-curve Digital Signature Algorithm). De techniek lijkt erg op die van ECDSA, maar zoals de naam al aangeeft gebruikt EdDSA 'twisted Edwards curves', een specifieke variant van de onderliggende wiskunde gebruikt in de Elliptic-Curve Cryptography (ECC).

DNSSEC-algoritmen nummer 15 en 16 (gedefinieerd in RFC 8080) maken gebruik van de cryptografische constructies Ed25519 en Ed448 (beschreven in RFC's 8032 en 7748). De eerste constructie combineert de elliptische curve Curve25519 met de SHA-512 hash-functie tot een razendsnel public-key algoritme. Ed448 doet hetzelfde met Curve448 en SHA-3 (in dit geval de SHAKE256-variant).

Net als algoritme nummer 13 (ECDSA Curve P-256 with SHA-256) biedt Ed25519 (algoritme nummer 15) een veiligheidsniveau van 128-bits (wat op dit moment de norm is) op basis van een 256-bits private sleutel, met daarbij een 512-bits publieke sleutel en 512-bits handtekeningen. Met een sleutellengte van 448 bits en een veiligheidsniveau van 224 bits is Ed448 (algoritme nummer 16) de EdDSA-gebaseerde evenknie van algoritme nummer 14 (ECDSA Curve P-384 with SHA-384).

De EdDSA-gebaseerde cryptografie biedt voor DNSSEC dezelfde voordelen als ECDSA ten opzichte van DSA- en RSA, maar is eenvoudiger, iets sneller, en minder gevoelig voor (side-channel) aanvallen dan ECDSA.

EdDSA-gebaseerde algoritmen in de .nl-zone

Hoewel het voor grootschalig operationeel gebruik van algoritmen nummer 15 (Ed25519) en nummer 16 (Ed448) op dit moment (februari 2023) nog te vroeg is, kun je deze 2 algoritmen wel al in de .nl-zone gebruiken.

Registrars kunnen DNSKEY-records gebaseerd op algoritmen nummer 15 en 16 zonder meer bij SIDN aanleveren voor publicatie in de nl-zone (in de vorm van een hash-waarde in een DS-record). Daarmee is het voor registrars in principe ook mogelijk om de domeinen van hun klanten met EdDSA te ondertekenen.

RFC 8624 (gepubliceerd in juni 2019) specificeert de implementatie van algoritmen nummer 15 en 16 in resolvers als 'recommended', net als de implementatie van nummer 15 in nameservers. Dat betekent dat de ondersteuning voor EdDSA-gebaseerde algoritmen deze jaren in de DNS-software ingebouwd wordt. Daarom is het voor grootschalig operationeel gebruik nu nog te vroeg. De DNSThought-statistieken laten zien dat 85 procent van de validerende resolvers op dit moment ook algoritme 15 ondersteund. Kijken we naar de .nl-zone, dan zien we dat op dit moment slechts een verwaarloosbare 0,01 procent van de domeinnamen algoritme nummer 15 gebruikt.

Hash-functies voor de DS/CDS-records

Rest ons tenslotte nog om iets te zeggen over de hash-functie te gebruiken voor de DS/CDS-records, waar RFC 8524 ook aanbevelingen voor geeft:

• op dit moment is slechts een handvol algoritmen gedefinieerd; het complete overzicht vind je op de website van IANA: https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

• hash-algoritme nummer 2 (SHA-256) wordt aanbevolen;

• nummer 1 (SHA-1) wordt nog wel veel gebruikt, maar moet je inmiddels vervangen door nummer 2;

• nummer 4 (SHA-384) is een sterkere versie van nummer 2, maar is op dit moment nog niet nodig.

Kortom: Ga je nu met DNSSEC aan de slag, dan kies je voor hash-algoritme nummer 2. Gebruik je al DNSSEC maar dan gebaseerd op hash-algoritme nummer 1, stap dan over naar nummer 2.