DNSSEC voorbereiden op kwantumcomputers

Het DNS vormgeven voor de komende decennia

Auteurs: Moritz Müller (SIDN Labs), Jins de Jong (TNO), Maran van Heesch (TNO), Benno Overeinder (NLnet Labs), Roland van Rijswijk-Deij (NLnet Labs en Universiteit Twente)

Kwantumcomputers hebben de potentie om een groot aantal cryptografische algoritmen te kraken. Hoewel de experts van mening zijn dat het nog zeker 10 tot 20 jaar duurt voordat er kwantumcomputers bestaan die daar krachtig genoeg voor zijn, is het van belang om nu al na te denken over hoe we bestaande systemen kunnen laten overschakelen op kwantumveilige algoritmen. In dit artikel richten we ons op DNSSEC, de beveiligingsuitbreiding op het DNS. We stellen dat we DNSSEC met enige aanpassingen klaar kunnen maken voor het tijdperk van de kwantumcomputer.

Deze blogpost is gebaseerd op een peerreviewed artikel dat wordt gepubliceerd in Computer Communication Review. Onze auteursversie vind je op deze website.

Waarom zijn kwantumcomputers relevant voor DNSSEC?

Kwantumcomputers werken anders dan de computers die we nu hebben. In plaats van te rekenen met bits, die de toestand van één of nul kunnen aannemen, werken kwantumcomputers met qubits, die zich in meerdere toestanden tegelijk kunnen bevinden. Hierdoor kunnen kwantumcomputers bepaalde computationele problemen efficiënter oplossen dan de huidige computers. Dergelijke computationele problemen vormen de basis voor de cryptografische algoritmen die we vandaag de dag gebruiken om DNS-berichten te signeren, zoals Elliptic Curve en RSA. Dankzij het gebruik van die algoritmen in DNSSEC is iedereen op het internet in staat om te verifiëren of een inkomend DNS-bericht het oorspronkelijke bericht is en of er onderweg niet mee is geknoeid. Kwantumcomputers hebben in potentie de capaciteit om dergelijke cryptografische algoritmen met behulp van het algoritme van Shor binnen een paar uur of dagen te kraken, in plaats van honderden jaren, die huidige computers nodig hebben. Voor DNSSEC betekent dit dat een aanvaller een man-in-the-middle-aanval zou kunnen uitvoeren: een DNSSEC-gesigneerd antwoord (met bijvoorbeeld het IP-adres van een site als www.rivm.nl) onderscheppen, het IP-adres in het DNS-antwoord wijzigen en het antwoord vervolgens opnieuw signeren. Het slachtoffer zou dan geen verschil kunnen zien tussen de handtekening op het oorspronkelijke bericht en de handtekening die de aanvaller aan het gemanipuleerde bericht heeft toegevoegd. Als gevolg daarvan zou het slachtoffer (bijvoorbeeld een bezoeker van www.rivm.nl) kunnen worden omgeleid naar een schadelijke site. Gelukkig bestaan er computationele problemen die ook voor kwantumcomputers niet zomaar even op te lossen zijn. Als zodanig zijn ze goed te gebruiken voor de cryptografische algoritmen die nodig zijn voor DNSSEC. Het Amerikaanse National Institute of Standards and Technology (NIST) heeft een wedstrijd uitgeschreven die moet leiden tot de standaardisering van ‘kwantumveilige’ algoritmen, dat wil zeggen, algoritmen die ook in het tijdperk van de kwantumcomputer nog voldoende beveiliging bieden.

Vereisten voor DNSSEC-algoritmen

Samen met onderzoekers van TNO, NLnet Labs en Universiteit Twente onderzochten we of de signeeralgoritmen die aan de NIST-wedstrijd meedoen, geschikt zijn voor DNSSEC-gebruik. Om het onderzoek te structureren, definieerden we eerst 4 vereisten waaraan kwantumveilige algoritmen moeten voldoen om voor DNSSEC in aanmerking te komen. In aflopende volgorde van prioriteit zijn dit:

Handtekeninggrootte

Gezien het feit dat bij elk gesigneerd DNS-bericht een DNSSEC-handtekening wordt verzonden, is ons eerste vereiste: kwantumveilige algoritmen moeten handtekeningen genereren die kleiner zijn dan 1.232 bytes. Het DNS maakt voor het overbrengen van berichten tussen resolvers en autoritatieve nameservers voornamelijk gebruik van UDP. Een DNS-bericht moet dus in één UDP-datagram passen. Doet het dat niet, dan lopen we het risico dat het bericht als gevolg van fragmentatie niet goed wordt verzonden. In het DNS werkt dat als volgt: als een recursieve resolver een query naar een autoritatieve nameserver stuurt, wordt aangegeven wat de maximale ondersteunde antwoordgrootte is. Als het antwoord groter is, vraagt de autoritatieve nameserver de resolver om het opnieuw te proberen, maar dan met TCP in plaats van UDP. Dit proces is echter gevoelig voor fouten. Het is bijvoorbeeld mogelijk dat de resolver of de autoritatieve nameserver TCP niet ondersteunt of dat een middlebox alleen DNS-berichten toestaat die worden verstuurd met UDP. Ook kan het zijn dat zelfs als de resolver aangeeft een bepaalde datagramgrootte te ondersteunen, de onderliggende netwerklaag dat niet doet. In dat geval deelt de netwerklaag het antwoord op in kleinere fragmenten, die een grotere kans lopen dat ze niet goed aankomen, bijvoorbeeld door firewalls die gefragmenteerde pakketten droppen. Na verloop van tijd zou de resolver het opnieuw proberen via TCP, maar, zoals hierboven al vermeld, lukt dat vaak ook niet. DNS-berichten kunnen dus maar beter niet worden gefragmenteerd. Metingen hebben aangetoond dat DNS-berichten die groter zijn dan 1.232 bytes, een grotere kans lopen om niet goed te worden verzonden.

Validatiesnelheid

Resolvers moeten kwantumveilige algoritmen net zo efficiënt kunnen valideren als de huidige algoritmen. Aangezien bij elk DNS-antwoord een handtekening wordt verzonden, moet een resolver voor elk bericht dat van een autoritatieve nameserver wordt ontvangen, ook de handtekening valideren. Dat betekent dat drukke resolvers (bijvoorbeeld van een ISP of een dienst als Google Public DNS) duizenden antwoorden per seconde moeten valideren. Bovendien verwachten we dat dat aantal in de toekomst toeneemt, omdat de adoptie van DNSSEC nog steeds toeneemt.

Signeersnelheid

Ook de snelheid waarmee records worden gesigneerd, mag niet onderdoen voor de huidige algoritmen. In DNSSEC hoeft de operator van een zone records alleen te ondertekenen als de inhoud van de zone is gewijzigd. Voor .nl moeten we bijvoorbeeld elk half uur gemiddeld zo'n 11.000 nieuwe handtekeningen genereren. In sommige gevallen moeten records on-the-fly worden gesigneerd en dan kunnen hogere signeersnelheden nodig zijn.

Sleutelgrootte

Publieke sleutels mogen groter zijn dan 1.232 bytes. Met DNSSEC worden publieke sleutels slechts af en toe verzonden om de handtekeningen op afzonderlijke antwoorden te valideren. Een resolver vraagt doorgaans bijvoorbeeld slechts één keer per uur om de publieke sleutels voor de miljoen meest populaire domeinnamen. We zijn daarom van mening dat publieke sleutels groter kunnen zijn dan 1.232 bytes. Verderop in dit artikel leggen we uit hoe grotere sleutels betrouwbaar kunnen worden overgedragen.

Beoordeling van kwantumveilige algoritmen

Dus, voldoen de algoritmen die meedoen aan de NIST-wedstrijd aan onze vereisten? Van de kwantumveilige algoritmen die een vergelijkbare mate van beveiliging bieden als de huidige algoritmen, genereren er 3 handtekeningen die kleiner zijn dan 1.232 bytes: Falcon-512, Rainbow-Ia, en RedGeMSS128. De onderstaande tabel geeft een overzicht van deze algoritmen en hun relevante kenmerken. Ter vergelijking hebben we onderaan de tabel 2 algoritmen toegevoegd die momenteel vaak in DNSSEC worden gebruikt.

Algoritme

Publieke sleutel

Handtekening

Handtekeningen/sec

Validaties/sec

Falcon-512

0,9 kB

0,7 kB

~3.300

~20.000

Rainbow-Ia

158 kB

66 B

~8.300

~11.000

RedGeMSS128

375 kB

35 B

~500

~10.000

EdDSA-Ed22519

32 B

64 B

~26.000

~8.000

RSA-2048

0,3 kB

0,3 kB

~1.500

~50.000

Tabel 1. Metingen van kwantumveilige algoritmen.

Voor elk algoritme testten we de prestaties van de geoptimaliseerde implementaties in ons testbed. Daar signeerden we een willekeurig bericht van 86 bytes, valideerden we de handtekening en registreerden we hoelang beide stappen duurden. Vervolgens herhaalden we dat proces een paar duizend keer, waarna we de mediane verwerkingstijden berekenden. Op basis van de metingen concluderen we dat alle 3 de algoritmen voor de meeste gebruikscases waarschijnlijk efficiënt genoeg zijn om in DNSSEC te worden gebruikt. Zo is de validatiesnelheid van de resolver bij allemaal hoog genoeg, soms zelfs sneller dan traditionele DNSSEC-signeeralgoritmen (laatste kolom). De waarden voor de sleutel- en handtekeninggrootte geven echter meer reden tot zorg. Falcon-512 genereert weliswaar handtekeningen die kleiner zijn dan 1.232 bytes, maar als een record wordt gesigneerd met 2 sleutels kunnen er alsnog problemen optreden. Dat is vaak het geval tijdens key roll-overs en verhoogt dus het risico op pakketverlies. Rainbow-Ia, en RedGeMSS128 daarentegen genereren piepkleine handtekeningen, maar hun publieke sleutels zijn weer te groot om in een DNS-bericht te passen.

Ons voorstel: verzend publieke sleutels out-of-band

Tabel 1 laat zien dat geen van de algoritmen perfect is voor DNSSEC. Theoretisch gezien voldoet Falcon-512 aan al onze eisen, maar in de praktijk zou het problemen kunnen veroorzaken. Dat zou kunnen worden voorkomen door alle DNS-berichten te verzenden via TCP, maar dat is waarschijnlijk niet handig, aangezien de nameservers voor grote TLD's of drukke resolvers mogelijk niet in staat zijn om grote aantallen TCP-verbindingen efficiënt af te handelen vanwege de vele verbindingstoestanden die erbij betrokken zijn. Wij denken dat Rainbow-Ia, en RedGeMSS128 geschikter zijn voor DNSSEC, maar alleen als we een betrouwbare andere manier vinden om publieke sleutels te versturen. Aangezien hun publieke sleutels niet in een DNS-bericht passen, zouden we ze kunnen opsplitsen in segmenten en elk segment publiceren onder een apart domeinnaamlabel. Wel moet er dan aanvullende informatie worden toegevoegd aan de berichten die de segmenten bevatten, zodat een resolver ze weer kan samenvoegen tot één sleutel. Die aanpak heeft het voordeel dat de sleutel nog steeds in-band kan worden verzonden, maar het nadeel is dat de resolver meerdere queries moet verzenden om de sleutel te verkrijgen, wat de kans op pakketverlies vergroot. Wij stellen daarom voor om de publieke sleutels out-of-band te verzenden. Resolvers zouden dan niet de sleutel zelf maar alleen een URL ontvangen, waarna ze via een ander protocol, bijvoorbeeld HTTP, de sleutel zouden ophalen. Voor deze aanpak moet echter wel aan enige voorwaarden worden voldaan. Zo moet de resolver HTTP ondersteunen om de sleutel te kunnen ophalen en moeten de beheerders van nameservers aanvullende hostingservices voor sleutels aanbieden.

Conclusies en vervolgstappen

Samenvattend, kan DNSSEC zo worden aangepast dat het opgewassen is tegen kwantumcomputers? Ons onderzoek suggereert van wel. Ten minste 2 van de algoritmen die momenteel worden beoordeeld in het kader van de NIST-wedstrijd, lijken geschikt. Wel moet er aanvullend onderzoek gedaan worden naar de manier waarop dergelijke algoritmen in DNSSEC kunnen worden geïntegreerd. Daarbij moet onder meer gekeken worden naar hoe moet worden omgegaan met de grotere publieke sleutels die door de nieuwe algoritmen worden gebruikt. De algoritmen die geschikt lijken, worden bovendien nog geëvalueerd. Het is dus mogelijk dat in de toekomst nu nog onbekende beveiligingslekken worden gevonden. Tot slot willen we erop wijzen dat het bijna 10 jaar duurde voordat eerdere signeeralgoritmen op grote schaal werden ingezet. Het is dus van belang dat we zo snel mogelijk plannen maken voor de transitie naar kwantumveilige algoritmen. We willen onze voorstellen samen met onze onderzoekspartners nader bestuderen en mogelijk indienen bij de IETF voor verdere bespreking. Ons onderzoekspaper bevat een uitgebreide analyse en achtergrondinformatie over de kwantumveilige algoritmen die we beoordeelden op hun geschiktheid voor DNSSEC.