Evaluatie van post-kwantumcryptografie in DNSSEC-ondertekening voor TLD-operators
De impact op de prestaties bij zowel ondertekening als validatie is minimaal
De oorspronkelijke blogpost is Engelstalig. Dit is de Nederlandse vertaling ervan.
De mogelijke komst van kwantumcomputers vormt een bedreiging voor tal van cryptografische toepassingen, waaronder DNSSEC. Omdat algoritmen voor post-kwantumcryptografie (PQC) fundamenteel andere eigenschappen hebben dan de algoritmen die vandaag de dag in DNSSEC worden gebruikt, zal de transitie naar PQC operationele gevolgen hebben. Daarom onderzochten we de impact van het gebruik van PQC in DNSSEC-ondertekening voor operators van topleveldomeinen (TLD's).
Deze blogpost is gebaseerd op een peer-reviewed artikel dat werd gepubliceerd en gepresenteerd op de Network Traffic Measurement and Analysis Conference TMA2025.
Waarom is post-kwantumcryptografie relevant?
Als kwantumcomputers voldoende ontwikkeld zijn, wat overigens nog vele jaren kan duren, zullen ze in staat zijn om huidige vormen van cryptografie te kraken. Dat geldt ook voor de cryptografie die in DNS wordt toegepast, met name in DNSSEC. Het is daarom noodzakelijk om te onderzoeken hoe DNSSEC kan worden overgezet naar het gebruik van post-kwantumcryptografie, die is ontworpen met de capaciteit van een kwantumcomputer in gedachten. PQC-algoritmen hebben andere eigenschappen dan de algoritmen die vandaag de dag in DNSSEC worden gebruikt (zoals RSA of ECDSA), bijvoorbeeld wat handtekeninggrootte en verificatietijd betreft. De transitie naar PQC zal dan ook operationele gevolgen hebben. In een eerdere blogpost gingen we al in op de achtergrond van de relevantie van PQC voor SIDN.
In het vervolg van deze blogpost bespreken we ons onderzoek ter evaluatie van PQC voor gebruik in DNSSEC-ondertekening door TLD-operators.
Wat willen we weten?
Als operator van .nl zijn we geïnteresseerd in de gevolgen van het gebruik van post-kwantumcryptografie voor onze operationele processen. Om de impact van PQC te meten, hebben we de eigenschappen en prestaties van cryptografische algoritmen in DNSSEC geanalyseerd door zonefiles te ondertekenen en te verifiëren. Voor een TLD-operator behoren het ondertekenen en verifiëren van een zonefile tot de standaardactiviteiten. Het ondertekenen van de volledige zone is een goede maatstaf voor het vergelijken van algoritmen, zelfs al worden in de praktijk alleen de wijzigingen (delta's) van een zonefile elk half uur ondertekend. Daarnaast maten we de grootte van de zonefile, wat inzicht geeft in de omvang van de publieke sleutels en handtekeningen van de algoritmen.
Bij het evalueren van de opties voor DNSSEC-ondertekening bekeken we 3 vormen van niet-bestaan: NSEC, NSEC3, NSEC3 Opt-Out. Meer informatie over deze modi is te vinden in RFC 7129.
We testten de volgende algoritmen: RSA-1280 (DNSSEC-algoritme 8), ECDSA-P256 (DNSSEC-algoritme 13), Falcon-512 en MAYO-2. RSA en ECDSA zijn algoritmen die verplicht geïmplementeerd moeten worden voor DNSSEC-ondertekening en -validatie. Beide worden binnen alle TLD's op grote schaal gebruikt, waarbij ECDSA aan populariteit wint ten opzichte van RSA. Falcon, een post-kwantumalgoritme, is door NIST geselecteerd voor standaardisatie. MAYO is tot slot een veelbelovende kandidaat in de NIST-procedure voor de selectie van nieuwe post-kwantum-handtekeningenschema's.
We gebruikten 3 zonefiles als input voor onze analyse: .nl, .se en .nu, die we respectievelijk als groot, gemiddeld en klein classificeren. De zonefiles van zowel .se als .nu zijn openbaar toegankelijk, maar die van .nl is dat niet.
Ten slotte hielden we rekening met hardwareversnelling op basis van CPU-eigenschappen, door gebruik te maken van verschillende functieniveaus binnen de x86-64-architectuur. We maakten onderscheid tussen x86-64-v2 en x86-64-v3. Anders dan v2 biedt v3 ondersteuning voor AVX en AVX2, 2 functievlaggen waarvan we weten dat ze worden gebruikt door PQC-algoritmen.
Vervolgens voerden we 16 testreeksen uit, zodat alle mogelijke combinaties van variabelen werden meegenomen.
Acceptabele impact op DNSSEC-ondertekening
We constateerden dat de operationele impact van PQC-algoritmen op de DNSSEC-ondertekening voor TLD-operators beperkt is. Laten we enkele resultaten voor de .nl-zonefile nader bekijken.
Voor het ondertekenen van de volledige zonefile geven we de resultaten weer als een waarde ten opzichte van het uitgangsalgoritme ECDSA-P256 (algoritme 13). Deze resultaten zijn te zien in figuur 1. Een waarde van '2.0x' betekent dat het geteste algoritme 2 keer zoveel tijd nodig heeft als het uitgangsalgoritme. We zien dat zowel Falcon als MAYO duidelijk baat hebben bij hardwareversnelling. Wanneer dat wordt toegepast, is de prestatie van Falcon ongeveer vergelijkbaar met die van RSA, terwijl MAYO weinig onderdoet voor ECDSA-P256.
Figuur 1: Toename in ondertekeningstijd voor de .nl-zone vergeleken met het uitgangsalgoritme (algoritme 13, ECDSA-P256). Zonder (links) en met (rechts) hardwareversnelling.
Figuur 2: Toename in validatietijd voor de .nl-zone vergeleken met het uitgangsalgoritme (algoritme 13, ECDSA-P256). Zonder (links) en met (rechts) hardwareversnelling.
Bij de validatie van de volledige zonefile blijkt dat MAYO het meest profiteert van hardwareversnelling. Als dat wordt toegepast, is de prestatie van Falcon vergelijkbaar met ECDSA-P256 (algoritme 13), terwijl de prestatie van MAYO vergelijkbaar is met RSA (algoritme 8). Dit wijst erop dat de prestaties van de geteste PQC-algoritmen bij de validatie van zonefiles vergelijkbaar zijn met die van algoritmen die momenteel worden toegepast.
Figuur 3: De grootte van de .nl-zonefile als de zone niet is ondertekend, is ondertekend met klassieke algoritmen, of is ondertekend met PQC-algoritmen. Let op: de y-as is logaritmisch.
Tot slot laat de zonegrootte bij beide PQC-algoritmen een relatief grote toename zien, als gevolg van hun grotere handtekeningen en publieke sleutels. Vooral Falcon valt op, met handtekeningen van 666 bytes tegenover de 64 bytes van algoritme 13. Dit heeft gevolgen voor TLD-operators, niet alleen wat betreft de benodigde schijfruimte op hun autoritatieve servers, maar ook qua geheugengebruik (bij het laden van de volledige zone in het geheugen) en bandbreedte.
De resultaten laten zien dat de impact op de prestaties bij zowel ondertekening als validatie minimaal is. Dat komt doordat de prestaties van beide PQC-algoritmen vergelijkbaar zijn met die van de algoritmen die momenteel het meest worden toegepast, mits er gebruik wordt gemaakt van hardwareversnelling (x86-64-v3).
Volgende stappen in ons onderzoek
Sinds het uitvoeren van de hier beschreven studie zijn we begonnen met het meten van de impact van PQC DNSSEC op DNS-resolvers. We zijn van plan geanonimiseerde netwerkdata van een resolver uit de praktijk te gebruiken om het verkeer opnieuw af te spelen in onze testomgeving. Zo kunnen we de impact van PQC DNSSEC op de resolver bestuderen. In sommige gevallen zijn DNS-berichten bijvoorbeeld te groot voor een UDP-pakket, waardoor DNS terugvalt op TCP. We willen onderzoeken wat de gevolgen zijn wanneer resolvers overschakelen op TCP, zowel voor de ervaring van de eindgebruiker als voor de autoritatieve servers.
Voor een uitgebreidere analyse kun je het volledige onderzoeksrapport lezen.
Heb je feedback of opmerkingen? Dan horen we die graag.
