19 november 2013
Eerste beveiligde verhuizing van een ondertekend domein succesvol uitgevoerd
De eerste beveiligde verhuizing van een ondertekend domein is deze zomer succesvol uitgevoerd, nog op dezelfde dag dat SIDN het 'key relay' commando voor zijn registrars beschikbaar maakte. Een goede implementatie zou niet langer dan een paar dagen hoeven duren. Eigenlijk zou iedereen die nu DNSSEC aanbiedt op zijn minst als latende partij het verhuisprotocol moeten ondersteunen.
Dat het verhuizen van een ondertekend domein naar een nieuwe registrar in principe mogelijk was zonder de beveiliging te verbreken, was al langer bekend. Het afgelopen jaar hebben de technici bij SIDN, de beheerder van het .nl top-level domein, dit verhuisprotocol verder uitgewerkt. Het grootste obstakel om daadwerkelijk tot implementatie over te kunnen gaan, was dat er tot voor kort geen mogelijkheid bestond voor de registrars om sleutelmateriaal uit te wisselen, een vereiste om deze transacties af te kunnen wikkelen.
Door de EPP-interface (Extensible Provisioning Protocol) uit te breiden met het 'key relay' commando maakt SIDN het niet alleen mogelijk om de verhuizing van een ondertekend domein uit te voeren zonder dat daarbij de DNSSEC-beveiliging wordt onderbroken, maar kan die hele transactie door de betrokken registrars ook volledig worden geautomatiseerd. Op dit moment wordt gewerkt aan de officiële standaardisatie van het nieuwe commando. Dat wil zeggen dat deze zal worden opgenomen in een IETF RFC document. Daarmee is een belangrijk obstakel voor verdere adoptie van DNSSEC uit de weg geruimd.
'key relay' commando
De eerste beveiligde verhuizing van een ondertekend domein is deze zomer succesvol uitgevoerd, nog op dezelfde dag dat SIDN het 'key relay' commando voor zijn registrars beschikbaar maakte. De ISP's Monshouwer en Mijndomein waren de eerste registrars die het nieuwe commando gebruikten om het verhuisprotocol in zijn geheel te testen.
De ontvangende partij moet het meeste werk verzetten,
vertelt Kees Monshouwer, eigenaar en oprichter van het gelijknamige internet-bedrijf. Ewout de Graaf [tot voor kort werkzaam als BU manager bij Mijndomein] en ik zitten beiden in de technische commissie van de VvR (Vereniging van Registrars). Wij waren dus al vroeg op de hoogte van het nieuwe 'key relay' commando en vonden dat we daar wat mee moesten doen.
Initialisatie
Als de ontvangende registrar de opdracht krijgt om een bepaald domein naar zich toe te verhuizen, maakt hij eerst een nieuwe zone aan en de bijbehorende DNSSEC-sleutels. Via de nieuwe 'key relay' postbus draagt hij zijn publieke ZSK-sleutel vervolgens over aan de latende registrar. Voor die laatste is het proces heel eenvoudig: hij ontvangt via EPP de publieke sleutel van de verkrijgende registrar, die hij dan ondertekent en publiceert in zijn eigen zone file. Daarvoor hoeft hij alleen het call-bericht in EPP af te vangen en wat checks uit te voeren.
Zo moet de latende registrar zich ervan vergewissen dat de sleutel die hij via EPP aangeleverd krijgt niet al in zijn zone is opgenomen, om te voorkomen dat er dubbel sleutelmateriaal in zijn DNS records terecht komt. Dat zou kunnen gebeuren als dezelfde sleutel al eerder is aangeleverd of als hij zijn eigen sleutel toegestopt krijgt. Dat is een manier waarop kwaadwillenden misbruik zouden kunnen maken van dit systeem. Maar dan moeten ze natuurlijk wel eerst het verhuis-token bemachtigen.
Aandachtspunten
De ontvangende registrar heeft het een stuk drukker,
vervolgt Monshouwer. Het versturen van zijn sleutelmateriaal via EPP is makkelijk. Maar daarna wordt het lastig, met name vanwege de timing-aspecten. Alles bij elkaar bevat het verhuisproces 14 stappen. Dat gaat bovendien uit van een schone situatie. In een productie-omgeving is het lang niet altijd zo duidelijk. Zo kan de latende registrar net bezig zijn om zijn sleutels te rollen. Dat betekent dat hij op dat moment twee ZSK's in zijn zone file heeft staan. Dat geldt sowieso voor de meeste PowerDNS-installaties, want deze DNS-server genereert standaard nog steeds twee ZSK-sleutelparen. Die sleutels moeten dan allebei worden overgenomen. Bovendien moet de ontvangende registrar in de wachtperiode (totdat zijn nieuwe sleutels overal bekend zijn) controleren of er in die situatie iets verandert.
Een ander probleem is dat de latende registrar een ander encryptie-algoritme kan gebruiken dan de ontvangende registrar. Alles bij elkaar zijn er wel een stuk of acht verschillende. De verkrijgende partij zal de latende partij hierin moeten volgen. Dat betekent waarschijnlijk dat iedereen straks alle veelgebruikte algoritmen zal moeten ondersteunen. Na het voltooien van de verhuizing, als de laatste TTL is verstreken, kan de verkrijgende registrar het algoritme eventueel aanpassen aan zijn eigen standaard algoritme door een rollover uit te voeren. Zelf zou ik dat inderdaad doen, omdat je anders na verloop van tijd een hele batterij aan verschillende algoritmen in je bestand hebt zitten.
Als je het algoritme van de latende partij niet kunt matchen, dan kan je het domein niet veilig verhuizen en dan zal je dat aan je klant moeten uitleggen. Hoewel er geen standaard algoritme is, valt de diversiteit hier in Nederland gelukkig erg mee; de meeste .nl domeinen worden beheerd met PowerDNS.
Voor de overdracht
Voordat hij nu de daadwerkelijke transfer uitvoert, moet de ontvangende registrar wel controleren of de overgedragen sleutels inderdaad op alle DNS-servers gepubliceerd zijn,
aldus Monshouwer. Het moment dat de sleutels op de laatste server verschijnen is hierbij bepalend, omdat vanaf dat moment, plus het verstijken van de TTL, de chain-of-trust aan beide zijden klaar is voor de verhuizing. Het enige dat nog ontbreekt in de keten voor de ontvangende kant is de registratie van het nieuwe DS record bij de registry.
Voor de overdracht moet de ontvangende registrar ook nog verifiëren dat "het vinkje" aanstaat waarmee hij aangeeft dat het DNSSEC-sleutelmateriaal opgeslagen en gepubliceerd bij SIDN bij verhuizing bewaard moet blijven. Als dat verloren gaat, wordt op dat moment ook de vertrouwensketen verbroken. Na dit alles kan de daadwerkelijke overdracht plaatsvinden en kan de nieuwe registrar zijn eigen sleutelmateriaal voor het betreffende domein bij SIDN publiceren.
Wachten
Vervolgens is het weer wachten geblazen,
legt Monshouwer uit. SIDN publiceert elke twee uur een nieuwe zone file. Het genereren daarvan duurt op dit moment ongeveer 40 minuten. Pas daarna begint weer de tijd (TTL) te lopen waarbij de oude NSset en DSset records verlopen en de nieuwe records overal op internet bekend worden gemaakt. Daarna kan de latende registrar zijn zone verwijderen en de nieuwe registrar het oude sleutelmateriaal weghalen. Na het verstijken van de TTL van de records bij de latende registrar kan zijn sleutelmateriaal uit de nieuwe zone gehaald worden en is de verhuizing voltooid.
Belangrijk aandachtspunt hier is dat de ontvangende registrar er niet van uit mag gaan dat hij na 2 uur en 40 minuten kan beginnen met aftellen. Als SIDN net in een onderhouds-window zit of als er iets anders misgaat met de publicatie van de .nl zone, dan moet hij wachten.
Langdurig proces
Je zou in de verleiding kunnen komen om maar één zone update te wachten,
vervolgt Monshouwer. De TTL en het interval tussen de zone updates zijn immers allebei twee uur. Als je je nieuwe sleutelmateriaal voor 10:00 uur publiceert, dan zou dat normaal gesproken zichtbaar moeten zijn om 10:45. Je zou de volgende stap al om 12:00 in plaats van 14:00 uur kunnen zetten. Die informatie wordt immers pas om 12:45 zichtbaar. Helaas varieert de tijd voor de updates zodanig dat deze aanpak onmogelijk is. Als de zone van 12:00 al om 12:35 beschikbaar is, dan zit je tien minuten met een kapotte DNSSEC-configuratie.
Onderstaand diagram laat zien dat de publicatietijd de afgelopen maanden tussen de 40 en 70 minuten lag.
Dat maakt dat bij elke vervolgstap minimaal twee zone updates nodig zijn, waardoor veilig verhuizen niet alleen een langdradig maar ook een langdurig proces is. Van de negen uur die een veilige verhuizing nu duurt, zijn er zes waarin je zinloos zit te wachten. Omdat dat langer is dan een werkdag, verlies je het zicht op de transactie. Gaat er wat mis, dan ontdek je pas 's ochtends dat er de halve nacht geen mail afgeleverd is. Door de TTL op anderhalf uur te zetten, zou je het verhuisproces terug kunnen brengen tot vier à vijf uur. Maar SIDN zegt die twee uur nodig te hebben voor eventualiteiten. Ook als de .nl zone met een grotere regelmaat gepubliceerd zou worden — bijvoorbeeld elk uur — dan zou dat al meer dan vier uur winst opleveren in het verhuisproces. Wil je dat nog verder stroomlijnen, dan moet SIDN overstappen naar real-time zone updates, iets dat de meeste andere registries nu al doen. Als ik nu een wijziging invoer voor een .com domein, dan is die binnen vijf minuten verwerkt.
Nu DNSSEC nog maar beperkt gevalideerd wordt, willen mensen liever snel dan veilig verhuizen. Op dit moment kun je daarbij ook nog fouten maken. Straks is het speelkwartier voor DNSSEC over: dan komen klanten en hun bezoekers in de problemen als een verhuizing niet goed uitgevoerd wordt.
Goed te doen
Volgens Monshouwer is de implementatie van het nieuwe verhuisprotocol desondanks goed te doen. We hebben nu een quick-and-dirty aanpak gevolgd, maar een goede implementatie zou niet langer dan een paar dagen hoeven duren. Uit onze test blijkt wel dat er nog de nodige ruimte voor interpretatie in het protocol zit en dat er toch behoorlijk wat aandachtspunten zijn. Het zou individuele registrars enorm helpen als SIDN een volledige procesbeschrijving zou aanleveren waarin alle aspecten van het veilige verhuisproces zijn opgenomen. Deze zou dan als handvat kunnen dienen voor praktische implementatie.
Eigenlijk zou iedereen die nu DNSSEC aanbiedt op zijn minst als latende partij het veilige verhuisprotocol moeten ondersteunen. Die ondersteuning hoeft dan niet eens via EPP te lopen. Zolang er maar een mogelijkheid is om, op de een of andere manier, ZSK DNSKEY records aan een zone toe te voegen. Misschien zou deze minimale ondersteuning zelfs verplicht moeten worden.
