NederHost gaat het algoritme dat wordt gebruikt voor het genereren van DNSSEC-handtekeningen wijzigen van algoritme 8 naar 13. Dit is een wijziging waar klanten niets van merken maar die voor het internet als geheel wel van belang is. In deze blogpost een korte technische toelichting.
Het verschil tussen 8 en 13
Het tot dusver aanbevolen algoritme 8 is gebaseerd op RSA dat grote priemgetallen gebruikt om sleutels te genereren. RSA is veilig maar de gebruikte sleutels zijn wel fors. Conform de algemeen geldende richtlijnen gebruikt NederHost een langdurige sleutel van 2048 bits lang, en tijdelijke sleutels van 1024 bits die regelmatig worden vervangen door een nieuwe sleutel die al standby staat. Dit betekent dat op een willekeurig moment er drie betrekkelijk grote sleutels worden gepubliceerd. Ook zijn de met RSA gegenereerde handtekeningen vrij lang.
Het nieuwere algoritme 13 is gebaseerd op ECDSA dat punten op specifieke curves gebruikt om sleutels te genereren. Een ECDSA-sleutel is veel kleiner: algoritme 13 gebruikt een curve met sleutels die 256 bits lang zijn. Een dergelijke sleutel is ongeveer net zo veilig als een RSA-sleutel van 3072 bits. Hierdoor is het ook niet meer nodig om tijdelijke sleutels te gebruiken, en volstaat het dus om één kleine sleutel te publiceren in plaats van drie grote. Ook de met ECDSA gegenereerde handtekeningen zijn ongeveer half zo groot.
Kleinere antwoorden voor een beter internet
Het gebruik van algoritme 13 leidt dus tot kleinere DNS-antwoorden. Dit is vooral belangrijk voor de stabiliteit van het internet als geheel omdat het o.a. ‘DNS amplificiation’-aanvallen minder makkelijk maakt. Bij DNS amplification wordt een kleine vraag (bijvoorbeeld: geef mij de DNS-sleutels) gestuurd die een groot antwoord (alle DNS-sleutels) oplevert; dit kan worden misbruikt om met een kleine hoeveelheid verkeer een grote hoeveelheid verkeer te genereren dat bij iemand anders terecht komt. DNS-operators nemen tot dusver technische maatregelen om dit zoveel mogelijk tegen te gaan maar de overstap naar kleinere sleutels en handtekeningen is uiteindelijk een veel betere oplossing.
De migratie
Omdat DNS gebruik maakt van caching en er specifieke regels zijn bedacht over hoe DNSSEC-handtekeningen en sleutelmateriaal zich met elkaar moeten verhouden is het overstappen op een nieuw algoritme een delicaat proces dat bestaat uit een heel aantal stappen. Deze stappen zijn gedocumenteerd in RFC 6781. NederHost kiest voor de conservatieve procedure met dubbele handtekeningen met de volgende stappen:
Vanaf 7 juli worden DNS-records voorzien van een dubbele handtekening met zowel algoritme 8 als 13. Antwoorden op DNS-queries zijn dus tijdelijk juist iets groter dan normaal. Dit wordt gedaan om te voorkomen dat caching nameservers nog oude handtekeningsets in hun cache hebben.
Op 9 juli worden de nieuwe algoritme 13-sleutels gepubliceerd; vanaf dit moment is het mogelijk om de nieuwe handtekeningen te verifiëren. Nu wachten we tot we zeker weten dat caching nameservers de oude sleutels niet meer in hun cache hebben.
Vanaf 10 juli worden de secure delegations bij de registries aangepast; vanaf dit moment vragen we om gebruik te maken van de nieuwe sleutels bij de controle van de handtekeningen. Dit gebeurt door het vervangen van de DS-records van de domeinnamen, en nu wachten we tot we zeker weten dat caching nameserves de oude DS-records niet meer in hun cache hebben.
Op 13 juli worden de oude DNS-sleutels uit DNS gehaald; vanaf dit moment zijn de oude handtekeningen niet meer te verifiëren. We wachten nu tot caching nameservers de oude DNS-sleutels niet meer in hun cache hebben.
Op 16 juli worden de handtekeningen met de oude sleutels uitgeschakeld. Antwoorden op DNS-queries zijn vanaf dit moment korter dan voorheen. Hiermee is de migratie afgerond.
Bij iedere stap wordt gecontroleerd of alle zones nog secure zijn. We zorgen ervoor dat de TTLs van onze DNS-records nooit groter zijn dan een dag. De TTLs van de DS-records kunnen niet door NederHost worden beïnvloed maar ook deze zijn bij de door ons gebruikte registries maximaal een dag. Evengoed wachten we op sommige punten (veel) langer dan 24 uur om zeker te zijn dat alles blijft werken.
SIDN voert gelijktijdig met NederHost een soortgelijke overstap uit, maar dit heeft geen invloed op elkaar. Conform de voorlopige planning van SIDN zijn de belangrijkste stappen op 11 en 14 juli; voor de zekerheid is de planning van NederHost daar omheen gezet.