Nieuw DNSSEC-algoritme voor .nl
Rollover van algoritme 8 naar 13
DNSSEC is een methode om internetgebruikers te beschermen tegen valse DNS-antwoorden. Om de echtheid van de DNS-antwoorden te garanderen worden de antwoorden van een digitale handtekening voorzien. Voor .nl verzorgt SIDN dit. Voor het genereren van de digitale handtekeningen maken we gebruik van een cryptografisch algoritme. Voor de .nl-zone is dat nu DNSSEC-algoritme 8 (RSA/SHA-256). Omdat er inmiddels goede ondersteuning is voor algoritme 13 (ECDSA Curve P-256 with SHA-256) en dit kleinere DNS-antwoorden oplevert, waarbij het veiligheidsniveau beter wordt, gaan we dit nieuwe algoritme gebruiken voor .nl. De kleinere DNS-antwoorden zorgen ervoor dat deze minder effectief in DDoS-aanvallen gebruikt kunnen worden. Ook is een met dit algoritme gegenereerde handtekening iets lastiger te verifiëren. Dat lijkt een nadeel maar een vervalser moet heel veel verificatiewerk doen bij een poging om een handtekening te "kraken" en zal dus veel extra moeite moeten doen.
In deze blog zetten we de verschillende stappen in de rollover naar het nieuwe algoritme uiteen. Gaandeweg vullen we de blog aan met nieuwe informatie.
SIDN schakelt .nl-zone om van DNSSEC-algoritme nummer 8 naar nummer 13De globale planning ziet er als volgt uit:
2023-07-04: fase 0 (voorbereidingen)
2023-07-05: fase 1 (OpenDNSSEC-policy’s wijzigen, zodat EC-sleutels gebruikt kunnen gaan worden en controleren of dit goed gaat)
2023-07-11: fase 2 (nieuw DS-record toevoegen aan de rootzone)
2023-07-14: fase 3* (het pad van algoritme 13-sleutels controleren en of algoritme 8-sleutels op hun retour zijn)
2023-07-17: fase 4* (het algoritme 8 DS-record uit de rootzone verwijderen)
2023-07-19: fase 5* (aan OpenDNSSEC doorgeven dat de algoritme 8-sleutels verwijderd kunnen worden)
* In deze fases zijn we afhankelijk van IANA, dus mogelijk veranderen de data nog.
Fase 0
Voorbereidingen
In de voorbereidingsfase zorgen we ervoor dat we interne en externe monitoring opzetten om de rollover goed te kunnen volgen. Vooruitlopend voerden we op 24 mei al aanpassingen door in het proces van de generatie en ondertekening om dit proces te versnellen. Uitgebreide tests in onze acceptatieomgeving lieten zien dat zonder deze aanpassingen het proces meer dan een half uur zou duren. En dat levert problemen op omdat we elk half uur een nieuwe zone maken. Onze nieuwe en snellere Hardware Security Modules hebben geen moeite met het rekenwerk voor de nieuwe digitale handtekeningen, maar de bottleneck bleek het verifiëren van de meer dan 20 miljoen handtekeningen ná het signeren te zijn.
Om het proces visueel te ondersteunen maken we gebruik van DNSviz.net. In fase 0 ziet dit er als volgt uit (klik op de afbeelding om deze te vergroten):
Fase 1
OpenDNSSEC-policy’s wijzigen, zodat EC-sleutels gebruikt kunnen gaan worden en controleren of dit goed gaat
Tijdens deze fase passen we onze OpenDNSSEC-configuratie aan, zodat deze ook de sleutels van algoritme 13 gaat maken, want in de overgangsfase moeten beide typen handtekeningen aanwezig zijn. Nadat deze configuratie actief is gemaakt, zal dit zichtbaar zijn aan de nieuwe DNSKEY-records in de zone. Hierdoor zal het genereren en publiceren van de zone ongeveer 4 minuten langer duren dan na fase 0. Hierbij worden alle records met beide algoritmes ondertekend en daardoor groeit onze zone met +/- 41%.
Natuurlijk maken we ook een back-up van de nieuwe sleutels, zodat deze veiliggesteld zijn voor een noodgeval.
Hierna moeten we wachten totdat de sleutels overal bekend worden in de wereld. Omdat DNS-gegevens wereldwijd gecached worden om snellere antwoorden te garanderen en om een buffer te vormen tegen DNS-storingen, moet er gewacht worden tot alle caches ververst zijn met de nieuwe sleutels. Dit neemt zo’n 150 uur in beslag. Als dat het geval is, kunnen we pas verder met de volgende fase.
De visualisatie na fase 1 ziet er als volgt uit (klik op de afbeelding om deze te vergroten):
Fase 2
Nieuw DS-record toevoegen aan de rootzone
Om het nieuwe algoritme actief te krijgen, moet er een DS-record toegevoegd worden aan de rootzone. Hiervoor wordt een procedure bij IANA doorlopen, waarbij er meerdere mensen goedkeuring moeten geven op de wijziging. Vanwege de afhankelijkheid van andere organisaties en personen is het niet precies bekend hoelang deze fase duurt.
Fase 3
Het pad van algoritme 13-sleutels controleren en of algoritme 8-sleutels op hun retour zijn
Nadat het nieuwe DS-record in de root gepubliceerd is kan men al gebruikmaken van het DNSSEC-pad dat algoritme 13 gebruikt. We moeten wachten om zeker te zijn dat het nieuwe DS-record in de hele wereld bekend is.
Als onze monitoring aangeeft dat het algoritme 13-pad wereldwijd volledig functioneel is, besluiten we om verder te gaan met het verwijderen van de algoritme 8-sleutels. Mocht dit onverhoopt niet lukken, dan kunnen we nog teruggaan naar alleen algoritme 8.
Fase 4
Het algoritme 8 DS-record uit de rootzone verwijderen
In deze fase doorlopen we weer een IANA-procedure om het DS-record van algoritme 8 uit de rootzone te verwijderen. Wanneer dat afgerond is, is alleen algoritme 13 nog maar actief in het DNSSEC-pad voor .nl.
Fase 5
Aan OpenDNSSEC doorgeven dat de algoritme 8-sleutels verwijderd kunnen worden
Als het DS-record van algoritme 8 verdwenen is uit de wereld, kunnen we OpenDNSSEC opdracht geven de sleutels van algoritme 8 op te ruimen. Dit zal zichtbaar zijn doordat de DNSKEY-records uit de zone verdwenen zijn. Hierdoor wordt de zone +/- 42% kleiner en ook neemt de doorlooptijd van het ondertekenen van de .nl-zone met +/- 3 minuten af.
