DNSSEC: De lange, hobbelige weg van algoritme-implementatie

DNSSEC ondersteunt een heel scala aan cryptografische signeeralgoritmen, van moderne op Edwards Curve gebaseerde algoritmen als Ed25519 tot DSA/SHA1 uit de jaren negentig. Tegenwoordig worden domeinnamen meestal gesigneerd met RSA/SHA-256 of ECDSA en de domeinnamen onder .nl zijn daarop geen uitzondering, zoals te zien is in Figuur 1.

Figuur 1: Algoritmen gebruikt door domeinnamen onder .nl. Zie stats.sidnlabs.nl voor de meest recente cijfers.

Deze algoritmen moeten af en toe worden vervangen. Verbeterde cryptoanalyse zou er bijvoorbeeld toe kunnen leiden dat een algoritme onveilig wordt. Erger nog, een kwantumcomputer zou door toepassing van het algoritme van Shor alle voor DNSSEC gestandaardiseerde algoritmen in polynomiale tijd kunnen kraken. Het vervangingsproces kan veel tijd in beslag nemen: eerst moet het standaardisatieproces binnen de IETF worden doorlopen en daarna het ondersteuningsproces in de DNS-software, registry's en registrars. In deze blogpost nemen mijn co-auteurs en ik van SIDN Labs, NLnet Labs en Virginia Tech deze lange weg onder de loep om inzicht te krijgen in de barrières en erachter te komen hoe we in de toekomst sneller op veiligere algoritmen kunnen overstappen.

Cryptografische signeeralgoritmen

Stap 1: Een nieuw algoritme standaardiseren

Voordat een algoritme in DNSSEC kan worden gebruikt, moet dit binnen de IETF worden gestandaardiseerd als RFC (bijvoorbeeld RFC 8080 voor Ed25519). In het verleden duurde het een tot 4 jaar om nieuwe algoritmen te standaardiseren. Na bestudering van de mailinglistarchieven van de IETF constateerden we dat algoritmen in het algemeen meer kans hebben om gestandaardiseerd te worden als ze een verbetering vormen. Dat kan betere veiligheid zijn, maar ook betere prestaties of kleinere handtekeningen.

Stap 2: Het algoritme integreren in de software

Uiteindelijk moet de DNS-software een nieuw algoritme (bijvoorbeeld OpenDNSSEC) kunnen gebruiken voor het signeren, terwijl resolvers (zoals Unbound of Knot) de handtekeningen moeten kunnen valideren. Voor de uitvoering van deze cryptografische functies maakt de DNS-software gebruik van bibliotheken, meestal OpenSSL en GnuTLS. De DNS-software zal deze bibliotheken alleen kunnen gebruiken als ze het nieuwe algoritme ondersteunen. De bibliotheken kunnen de implementatie van een nieuw algoritme dus in de weg staan.

Stap 3: Het algoritme in gebruik nemen

Helaas zijn de bibliotheken niet het enige obstakel. DNS-operators, registrars en registry's moeten het nieuwe algoritme ondersteunen: ze moeten stuk voor stuk de publieke sleutel of een hash daarvan publiceren om het resolvers mogelijk te maken de handtekening te valideren. In het geval van de algoritmen die het meest recent aan DNSSEC werden toegevoegd, Ed25519 en Ed448, schiet het vooralsnog niet erg op met die ondersteuning. Ruim 3 jaar na hun standaardisatie zijn ze beschikbaar via de meest gebruikte cryptobibliotheken, maar worden ze nog steeds niet ondersteund door veel van de meest populaire DNS-operators en registrars, met inbegrip van registry's die verantwoordelijk zijn voor topleveldomeinen (TLD’s). Dit betekent dat hun klanten niet kunnen upgraden naar Ed25519 of Ed448, ook al wordt Ed25519 naar verwachting het aanbevolen standaardalgoritme. .nl-domeinnaamhouders kunnen Ed25519 wel nu al implementeren, mits hun registrars het algoritme ook ondersteunen.

Hoe lang duurt dat allemaal?

Als al die hindernissen zijn overwonnen, is het de vraag hoeveel tijd eroverheen gaat voordat domeinen een nieuw algoritme ook echt gebruiken en hoelang het duurt voordat resolvers in staat zijn om het algoritme te valideren. Om dat te kunnen beantwoorden, keken we naar het aantal domeinnamen onder de TLD's .com, .net, .org, .nl en .se dat wordt gesigneerd met ECDSAP256. Daarvoor maakten we gebruik van gegevens verzameld door het meetplatform OpenINTEL. In Figuur 1 is te zien dat het na de standaardisatie in 2012 nog ruim 4½ jaar duurde voordat de eerste 100.000 domeinnamen met dit algoritme werden gesigneerd.

Figuur 2 — Aantal domeinnamen getekend met ECDSAP256 sinds in 2011 met het ontwerp ervan werd begonnen.

De belangrijke aandrijvers waren grote DNS-operators die al hun domeinnamen gingen signeren met ECDSAP256, waardoor de adoptie met sprongen toenam, hoewel de early adopters van dit algoritme kleine providers waren.

Figuur 3 — Aandeel van resolvers die ED25519 en ED448 kunnen valideren. De ondersteuning wordt gemeten met RIPE Atlas en de meest recente cijfers zijn hier te vinden.

Verder zijn de meeste resolvers niet onmiddellijk in staat om nieuwe algoritmen te valideren, omdat het upgraden ook tijd in beslag neemt (zie Figuur 3). De gegevens in de grafiek werden verzameld met meer dan 10.000 RIPE Atlas Probes. Ed25519 wordt door 72% van de validerende resolvers in onze dataset ondersteund, 3½ jaar nadat dit nieuwe algoritme in april 2017 werd gestandaardiseerd. En dit terwijl alle grote leveranciers van DNS-resolvers het algoritme al sinds ten minste begin 2018 ondersteunen. Domeinnaambeheerders die Ed25519 willen implementeren, kunnen daar dus beter nog even mee wachten totdat de resolverondersteuning dichter bij 100% ligt, aangezien hun domeinnamen anders niet optimaal beschermd zijn. En als je zelf wilt testen, welke algoritmen jouw resolver ondersteunen, kan dat met hulp van de website rootcanary.org.

Signeeralgoritmen vervangen

Over het algemeen bleek dat overschakelen op een ander algoritme door domeinbeheerders nog steeds wordt gezien als een obstakel. ‘Algoritme-rollovers’, zoals ze genoemd worden, kunnen storingen veroorzaken als ze niet met beleid worden uitgevoerd. We zagen bijvoorbeeld domeinnamen waarbij DNSSEC-signering eerst helemaal werd uitgeschakeld voordat er met ECDSAP256 werd gesigneerd. Sommige domeinnamen worden nog steeds gesigneerd met algoritmen die SHA-1 gebruiken, wat al geruime tijd als onveilig wordt beschouwd. We denken dat sommige beheerders overschakelen op een ander algoritme te lastig vinden, terwijl andere de overstap naar veiligere algoritmen nog niet noodzakelijk achten. De meeste resolvers zien de huidige algoritmen nog steeds als veilig, maar daar zou in de nabije toekomst verandering in kunnen komen.

Hoe krijg je een nieuw algoritme geïmplementeerd?

Wat zijn gezien de bovenstaande bevindingen de belangrijkste succesfactoren voor het geïmplementeerd krijgen van een algoritme? Ten eerste moet de internetgemeenschap het nieuwe algoritme vertrouwen. Het helpt bijvoorbeeld als een algoritme al wordt gebruikt in andere protocollen, zoals TLS, omdat daardoor de kans toeneemt dat de standaardisatie van DNSSEC soepel verloopt.

Ten tweede moeten DNS-operators, registrars en registry's door de gemeenschap worden aangemoedigd om het nieuwe algoritme ook te ondersteunen. Als ze zien dat er vraag naar is, vergroot dat de kans dat ze ondersteuning toevoegen. Aan de andere kant moeten DNS-operators streven naar optimale veiligheid en dus hun systemen en domeinnamen up-to-date houden.

Ten derde moet het zo gemakkelijk mogelijk worden gemaakt om het algoritme voor een domeinnaam te vervangen door een ander. Gelukkig is de DNS-software inmiddels zo geavanceerd dat het mogelijk is om een algoritme-rollover grotendeels te automatiseren. Mechanismen zoals CDS/CDNSKEY zouden dit proces verder kunnen vereenvoudigen, maar worden nog niet voldoende ondersteund.

Implicaties voor kwantumveilige algoritmen

Standaardisatieorganisatie NIST is momenteel bezig met de beoordeling van nieuwe algoritmen die niet te kraken zijn door huidige computers, maar ook niet door kwantumcomputers. Al onze bevindingen gelden ook voor deze zogeheten kwantumveilige algoritmen, met daarbij één aanvullende kanttekening: de kwantumveilige algoritmen die op dit moment de meeste kans maken om door NIST te worden gestandaardiseerd, hebben aanzienlijk grotere sleutels en/of handtekeningen dan de huidige algoritmen. We moeten nog uitzoeken hoe we deze algoritmen kunnen toepassen in DNSSEC. Daartoe hebben we een eerste analyse uitgevoerd in een ander onderzoek. In 2021 werken we dit verder uitwerken aan de hand van een operationeel testbed. Lees meer over ons onderzoek in onze paper voor de Internet Measurement Conference 2020. Een bewerkte versie van dit artikel is ook gepubliceerd op apnic.net en ripe.net.