older publication: 2001

Door⌗

R. Gieben, miek@nlnetlabs.nl or miek@miek.nl

Voorwoord In dit introductie artikel behandel ik DNSSEC en de beloftes en problemen die het met zich mee brengt. Daarbij wil ik uit leggen wat de bijdrage van NLnet Labs is geweest in het analyseren en oplossen van enkele van die problemen. Verder ga ik in op de plannen voor de uitrol van DNSSEC in Nederland in de nabije toekomst.

NLnet Labs is opgericht door [Stichting NLnet] 1 om nieuwe protocollen en applicaties te promoten en te ontwikkelen voor het Internet. Er is een budget voor 15 jaar ontwikkeling door 6 developers.

DNSSEC⌗

In de eerste dagen van het Internet was het een plek waar voornamelijk ontwikkelaars vanuit de wetenschap en het bedrijfsleven in een vriendschappelijke omgeven met elkaar konden communiceren. Het werd gebruikt als een medium om ideeen en informatie uit te wisselen. Beveiliging was hier geen issue. Vandaag de dag nu het Internet miljoenen gebruiker herbergt, zijn de risico’s groter geworden. De risico’s varieren van ongewenst tot ronduit gevaarlijk: van spam (grootschalig verspreiden van ongevraagde reclame) via virusssen en denial of service attacks, tot fraude met creditcard nummers. In al deze zaken speelt het ontbreken van een waterdichte indentificatie en authenticatie een hoofdrol.

Een van de systemen die goed werken in een vriendelijke omgeving, maar tegenwoordig kwetsbaar blijken te zijn, is het domain name system (DNS). De belangrijkste taak van het DNS is het verzorgen van een conversie tussen een domein name (bijvoorbeeld www.example.com) en een IP nummer (bijvoorbeeld 192.168.1.1). Mede dankzij de schaalbaarheid van het DNS is het Internet zo snel, zo groot geworden.

Echter, door het ontbreken van beveiliging kan men in een onvriendelijke omgeving de DNS informatie manipuleren en daarmee zowel de eigen identiteit verhullen als anderen de verkeerde kant op sturen. Dankzij het eerste kan men ongestraft SPAM en virussen verspreiden, het tweede vormt een directe bedreiging voor ieder vorm van e-commerce.

Als snel na de invoering van DNS realiseerde men zich deze kwetsbaarheid van het DNS (1990: Steven M. Belovin 2). Het rapport daarover is vervolgens 5 jaar geheim gehouden uit angst voor grootschalige verlammingen van het toenmalige Internet. Ook was de groei van het Internet dusdanig dat niemand tijd had om na te denken over beveiliging. Alle prioriteit werd gegeven aan het draaiende houden van het systeem en aan het werk om de groei op te vangen (met groei percentages van 20 to 30% per maand geen sinecure). Pas in 1995 is er, om iets aan de problemen te doen, een extensie voor DNS voorgesteld: het secure domain name system (DNSSEC). DNSSEC gebruikt digitale handtekeningen (signatures) om antwoorden te authenticeren en misbruik te detecteren. Als een signature niet klopt, wordt de informatie die hierbij hoort weggegooid. Zodoende zorgt DNSSEC ervoor dat bovengenoemde security issues worden opgelost, maar het introduceert tegelijkertijd weer nieuwe problemen, DNSSEC

• is CPU intensie

• zorgt voor toename in de grootte van zonefiles (met een factor 3-5)

• zorgt voor toename van de communicatie tussen registries en registrars (zogenaamde “key management”)

  CPU intensief NLnet Labs heeft onderzoek gedaan naar de deployment van DNSSEC. Hoewel DNSSEC een veel CPU intensiever is dan DNS zal dit waarschijnlijk niet veel problemen op gaan leveren. Computers worden immers steeds sneller en de thuisgebruiker hoeft alleen digitale handtekeningen te valideren (iets dat minder moeite kost dan het creeren van digitale handtekeningen). De zonefiles worden van te voren voorzien van hun signatures. Zoals bijvoorbeeld de .nl zone, bestaande uit 600.000 domeinen. Als heel .nl DNSSEC zou gebruiken zouden er 600.000 publieke sleutels (public keys) moeten worden gemaakt, alsmede de 600.000 bijbehorende signatures. Dit proces is vrij intensief, maar NLnet Labs heeft aangetoond dat dit voor de meeste zones op het Internet haalbaar is. Zelf .com (met 30 miljoen domeinen veruit de grootste zones van het Internet) heeft laten zien dat het signen van hun zone haalbaar is.

Zeer grote zonefiles Ten gevolge van DNSSEC worden zonefiles groter, een factor 3 tot 5. Hele grote zonefiles zouden hierdoor tot onhandelbare proporties kunnen groeien. Bijkomend probleem is dat een DNSSEC zonefile gesorteerd moet worden, wat ook weer tot onoplosbare computercapaciteits problemen zou kunnen leiden. Maar, ook hier is vastgesteld dat dit zelfs voor de allergrootste zones met de hedendaagse (64-bit) systemen opgelost kan worden. DNSSEC zones zullen bovendien regelmatig van hernieuwde signatures moeten worden voorzien, aangezien deze signatures een gelimiteerde levensduur hebben. Dit zogenaamde resignen blijkt te kunnen in 5% van de originele signtijd en zal naar verwachting dus veel minder problemen opleveren. Het is met de standaard tools, op een desktop PC al mogelijk om de .nl zone twee keer per dag te resignen.

Key management Een derde en minder eenvoudig oplosbaar probleem van DNSSEC is het key management. Hieronder vallen private key procedures en de procedures die beschrijven hoe public keys met de registry uitgewisseld dienen te worden. Zoals met alle public/private key crypto systemen is het van het uiterste belang, dat een private key geheim blijft. Aan de andere kant moet een private key ook beschikbaar zijn om signatures te creeeren. Deze situatie zorgt voor een spanningsveld waarvoor nog geen adequate oplossing is gevonden.

Verder bestaat key management ook uit procedures die vastleggen hoe een public key gesignd moet worden door de registry. Om duidelijk te maken waarom dat een moeilijk probleem is zal ik eerst wat dieper ingaan op de structuur van DNSSEC.

In DNS (en dus ook in DNSSEC) bestaat er een parent/child relatie tussen domeinen (zie Figuur 1); simpel gezegd is .nl de parent van ieder .nl domain (bijvoorbeeld miek.nl). En miek.nl is dan een child van .nl. Ook .nl is zelf weer een child en wel van '.' (root). In DNSSEC creeert elke zone een eigen public key, de zogenaamde zone signing key. Met deze zone signing key worden de signatures gemaakt over alle informatie van die zone. Dus wordt alle informatie in die zone beschermd door deze zone key (zie ook Figuur 2).

Natuurlijk moet ook die zone signing key zelf weer beveiligd zijn. Dit wordt normaliter in DNSSEC gedaan door de parent deze key te laten signeren. (er zijn ook andere methoden, zoals bv het in de Staats Courant publiceren en vervolgens hard configureren van de public key bij de resolver).

De zone key van miek.nl wordt dus gesignd door de zone key van .nl. Om alle DNSSEC zones van .nl te verifieren is slecht de zone key van .nl nodig. Wanneer deze zone key nu buiten het DNS om en op een veilige manier bij de thuisgebruiker kan worden afgeleverd, zal men instaat zijn een secure view te hebben op .nl.

In het ideale geval zal men de public key van de “root” zone thuis hebben en is er een secure view op het gehele Internet mogelijk. Na de invoer van DNSSEC signt “root” de zone key van .nl en .nl signt op haar beurt de public key van miek.nl. Dit process heet de “chain of trust” en kan gezien worden het grote voordeel van DNSSEC: 1 zone key is genoeg om alle signatures te kunnen verfivieren.

In de originele DNSSEC specificatie (RFC 2535 4) waren er 4 stappen nodig om de public key van een child bij de parent te krijgen (Figuur 3). Dit leverde te veel interactie op tussen de parent en child. De hoeveelheid administratie die nodig is om dit op een veilige manier te doen is ongekend en zal voor vrijwel alle TLDs (Top Level Domain, hieronder vallen .com, .org, .net, .etc.) tot onoverkomenlijke problemen leiden. NLnet Labs heeft heeft een voorstel gedaan om de key interactie efficienter te laten verlopen. Alleen bleek dit vast te lopen op bepaalde details in het DNS. Een van die details was dat er signatures ontstonden die er weliswaar identiek uitzagen, maar verschillende semantische betekenissen hadden. Later is dit voorstel in een andere vorm opnieuw ter stemming gebracht. Dit zogenaamde Delegation Signer (DS) model van Olufar Gudmanson heeft de goede punten van het NLnet Labs proposal in zich, maar omzeilt de problemen (Zie figuur 4). Deze DS draft is nu in last call bij de IETF en zal heel waarschijnlijk binnenkort geaccepteerd worden als een RFC. Dankzij DS zal het administratief mogelijk worden om DNSSEC uit te rollen in grote zones.

DNSSEC in .nl (.nl.nl experiment)⌗

Uiteindelijk heeft het tot 2000 geduurd voordat de tools die DNSSEC protocol implementeren beschikbaar kwamen. En ook nu moet er weer gewacht worden voordat de tools die DS aankunnen klaar zijn. Ondertussen is NLnet Labs bezig met het opzetten van een schaduw registry voor DNSSEC in .nl [5]. In deze registry kunnen .nl domein houders hun domein laten registeren om deze secure te laten maken. De opzet is van dien aard dat er straks naast de DNS-view op .nl er ook een (secure) DNSSEC-view bestaat. Het is de bedoeling dat deze registry eind juni geheel operationeel zal zijn. (Mits de DNSSEC+DS software tijdig beschikbaar komt (1)). Het eerdere .nl.nl experiment waar al secure .nl.nl domeinen konden worden geregistreerd wordt dan afgesloten. Dankzij dit .nl.nl experiment is overigens duidelijk geworden dat DNSSEC RFC2535-style nooit gerealiseerd zou kunnen worden op TLD niveau: de communicatie overhead was gewoon te groot.

In de loop van 2002 zal duidelijk worden of dit schaduw experiment een succes wordt. Mocht dit zo zijn dan is de verwachting dat het SIDN (de officiële .nl registry) niet al te lange tijd daarna DNSSEC gaat aanbieden in .nl. Nederland zou met deze registry het eerste land ter wereld zijn die DNSSEC aan het invoeren is. Wanneer DNSSEC wordt uitgerold, zal het een infrastructuur bieden waarin allerlei cryptografisch materiaal kan worden gepubliceerd. Dit biedt ongekende mogelijkheden voor IPsec, PGP en elke andere service die cryptografie gebruikt en zal hopelijk het begin zijn van een veiliger Internet.

Voetnoten

• Dit hangt af van (administratieve) procedures in het Department of Justice en/of het Pentagon. De software is af, er moet alleen nog maar een handtekening gezet worden om de betaling goed te keuren.