SIDN ondersteunt ook cryptografische DNSSEC-algoritmen 13 en 14

De DNSKEY records worden door SIDN gebruikt om de DS records te genereren. Deze laatste bevatten een hash-waarde (een digitaal uittreksel) die de publieke (KSK) sleutels voor het betreffende .nl-domein koppelen aan de .nl-zone. Daarmee wordt de cryptografische vertrouwensketen (de chain of trust) naar de root zone gesloten.

Public key algoritmen

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.

De veiligheid van alle drie public key algoritmen 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 twee 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.

Korter

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 2128brute 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 (twee keer de gewenste veiligheid), terwijl dit voor DSA en RSA minstens 2048 bits is. De lengte van de handtekeningen is voor ECDSA en DSA allebei ongeveer vier maal de lengte van de gewenste veiligheid, in dit voorbeeld dus 512 bits, terwijl die voor RSA op meer dan 2048 bits zit.

Voor 128-bitssecurity:

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

Belang

Deze verschillen in algoritmische eigenschappen zijn op meerdere manieren belangrijk voor DNSSEC. Ten eerste kunnen bij gebruik van ECDSA niet alleen de 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 opgeschakeld 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-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.

Aanbevelingen

RFC 6944 geeft een aantal aanbevelingen voor de keuze en toepassing van de verschillende DNSSEC-algoritmen. Nummer 1 (RSA/MD5) moet in ieder geval _niet_ meer gebruikt worden vanwege de bewezen onveiligheid van de MD5 hash-functie. En algoritmen nummer 13 (ECDSA Curve P-256 with SHA-256) en 14 (ECDSA Curve P-384 with SHA-384) worden in de RFC aanbevolen, naast nummer 8 (RSA/SHA-256) en 10 (RSA/SHA-512).

Geen van de algoritmen gebaseerd op de SHA-1 hash wordt op dit moment afgeraden voor implementatie. Nummer 3 (DSA/SHA1) en 6 (DSA-NSEC3-SHA1) zijn optioneel, nummer 5 (RSA/SHA-1) is verplicht, en nummer 7 (RSASHA1-NSEC3-SHA1) is zelfs aanbevolen. Deze vier zouden inmiddels echter niet meer gebruikt moeten worden. "SHA-1 is te zwak", zegt Marc Stevens, cryptograaf bij CWI en bekend als kraker van MD5 en SHA-1. "Dit protocol is niet voor niets al in 2011 door NIST afgekeurd voor gebruik in digitale handtekeningen. Het is dus zeer belangrijk dat er zo snel mogelijk ook voor DNSSEC een roadmap voor de uitfasering van SHA-1 komt."

SHA-1

De auteurs van RFC 6944 erkennen dat SHA-1 eigenlijk niet meer gebruikt zou moeten worden, maar de verplichting om algoritme nummer 5 (RSA/SHA-1) te implementeren is onderdeel van de DNSSEC-standaard zoals gedefinieerd in RFC 4034. Nummer 5 is cryptografisch hetzelfde als nummer 7 (RSASHA1-NSEC3-SHA1) — net zoals nummer 3 (DSA/SHA1) en 6 (DSA-NSEC3-SHA1) dat zijn — maar deze bevat geen NSEC3 records: een ondertekende denial-of-existence.

Onderstaande tabel laat zien dat algoritmen 5 en 7 tezamen voor maar liefst een half miljoen sleutels, 20 procent van het totaal, gebruikt worden. Deze domeinnaamhouders zouden eigenlijk zo snel mogelijk naar een veiliger alternatief moeten overstappen.

'White lies'

Met 'DNSSEC white lies' (RFC 4470 en 4471 propageert CDN-aanbieder CloudFlare een dynamische opvolger van NSEC3, waarbij deze antwoorden on-the-fly worden ondertekend. Daarmee zou het probleem van name walking definitief zijn opgelost. Het grote snelheidsverschil in ondertekening tussen ECDSA en RSA zou dit volgens hen ook praktisch mogelijk maken.

CloudFlare

Volgens Marco Davids, research engineer bij SIDN, is met name de korte sleutellengte van ECDSA reden geweest voor CloudFlare om gelijk vanaf de introductie van DNSSEC eind vorig jaar voor algoritme nummer 13 te kiezen. Juist omdat zij de facto standaard onderdeel zijn van een DDoS-bestendige infrastructuur, speelt dit argument voor hen een belangrijke rol. Of om met CloudFlare's DNS-specialist Olafur Gudmundsson te spreken: "We are fanatical about keeping DNS answers as small as possible."

"Toen wij als SIDN vier jaar geleden DNSSEC als dienst gingen aanbieden, waren algoritmen 13 en 14 nog maar net beschikbaar, vertelt Davids. "Vandaar dat wij hier pas later mee zijn gekomen. CloudFlare heeft hiermee nu een hele goede keuze gemaakt. Zo kunnen zij de grootte van hun DNSSEC-netwerkpakketjes onder de 512 bytes houden. En uit onderzoek van Geoff Huston, chief scientist bij APNIC, blijkt dat deze relatief nieuwe algoritmen inmiddels door de clients redelijk goed ondersteund worden. Daarmee loopt CloudFlare voorop ten opzichte van de meeste registries and registars."

CloudFlare heeft zich actief ingezet voor de ondersteuning van algoritmen nummer 13 en 14 door validerende resolvers. Hun belangrijkste overwinning daarin was dat ze Google zo ver kregen validatie van ECDSA toe te voegen aan hun publieke DNS-dienst.

20 duizend domeinen

Volgens Davids zitten er naar schatting zo'n 20 duizend .nl-domeinen bij CloudFlare waarvoor DNSSEC nu ook aangezet kan worden. "Dat is het aantal domeinen bij CloudFlare dat wel is ondertekend maar waarvoor het ECDSA-gebaseerde sleutelmateriaal eerder niet bij SIDN kon worden geregistreerd. Gebruikers van CloudFlare leiden hun verkeer om door hun NS records naar de nameservers van CloudFlare te laten verwijzen. CloudFlare heeft deze domeinnamen vervolgens wel ondertekend, maar hun klanten konden de door CloudFlare gegenereerde DNSKEY (gebaseerd op algoritme 13) tot nu toe niet naar SIDN uploaden."

"Nu dat geen probleem meer is, is het voor CloudFlare-gebruikers (of hun registrars) slechts een kwestie van het registreren van hun sleutelmateriaal om direct DNSSEC aan te zetten. In de eerste dagen na de aankondiging van SIDN zagen we dat dit voor zo'n 200 .nl-domeinen al uit eigen beweging was gedaan. Inmiddels zijn dat er al bijna 300."

PowerDNS

Ook de makers van PowerDNS gaan met ECDSA aan de slag. Vanaf versie 4 is algoritme 13 de standaard op deze veelgebruikte DNS-server. "Gebruikers kunnen als zij willen nog wel van deze default-instelling afwijken, vertelt senior engineer Peter van Dijk. "Daarnaast stappen we van de KSK/ZSK-splitsing af en genereren we standaard nog maar één sleutelpaar, de 'Combined Signed Key'. Deze heeft de SEP-vlag gezet en lijkt daarmee op een KSK-sleutel, maar het is de enige sleutel die we nog gebruiken."

"Deze twee ontwikkelingen zijn met elkaar verbonden, aldus Van Dijk. "Een korte ECDSA-sleutel is sterker dan 2048-bits RSA (algoritme 8), zodat we deze overstap kunnen doen zonder daarbij de veiligheid te verlagen. Bovendien worden de response-pakketten hier ook een stuk kleiner van."

Crypto Suite B

DNSSEC-algoritme 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, zullen we algoritme 14 naar verwachting voorlopig zelden tegenkomen.

Tenslotte is het goed om te weten dat ECDSA onderdeel is van de door de NSA ontwikkelde en door de NIST gestandaardiseerde Suite B verzameling van crypto-protocollen. Afgezien van de vraag of dat een aanbeveling is — deze twee Amerikaanse organisaties worden regelmatig beschuldigd van het inbouwen van backdoors — staat deze protocol suite sowieso op de nominatie om te worden vervangen. De NSA acht deze algoritmen in toenemende mate onveilig voor quantum-aanvallen en werkt op dit moment aan de opvolger van Suite B.

Lopende discussie

Binnen de DNSSEC-gemeenschap loopt op dit moment de discussie over het gebruik van ECC om het protocol verder te verbeteren. Hier vind je een overzicht van de bijeenkomsten in de komende weken.