De macht aan de Domeinnaam -houders
DNSSEC -gebaseerd DANE biedt aanvulling of vervanging van X.509 PKI
Hoewel DNSSEC de houders van domeinnamen in staat stelt hun DNS -informatie cryptografisch te beveiligen, is de directe meerwaarde daarvan nu nog beperkt. Met DNSSEC wordt echter een basis-infrastructuur aangelegd waarop weer verder gebouwd kan worden. DANE is de eerste uitbreiding. Daarmee kunnen eerst server-certificaten en later ook mailberichten worden beveiligd. Deze technologie had bijvoorbeeld het DigiNotar-debacle kunnen voorkomen. Direct voordeel voor domeinnaam-houders is dat zij voor de garantie van hun server-certificaten niet meer afhankelijk zijn van de commerciële diensten van een CA.
Met DNSSEC wordt DNS nu als een van de laatste internet-protocollen van een cryptografische beveiliging voorzien. Waar TCP-protocollen als HTTP (web), FTP (file transfer) en SMTP (mail delivery) simpelweg over TLS/SSL worden getransporteerd om versleutelde verbindingen te creëren (respectievelijk HTTP Secure, FTPS en Secure SMTP), heeft de beveiliging van DNS aanzienlijk meer voeten in de aarde gehad. Dat heeft te maken met de gedistribueerde opzet van het domeinnamen-systeem. De inhoudelijke uitbreidingen en de voorwaartse compatibiliteit maken DNSSEC dan ook een stuk complexer dan de TLS-beveiliging van de relatief eenvoudige transport-protocollen.
Met DNSSEC wordt echter een infrastructuur aangelegd die ook voor andere toepassingen gebruikt kan worden. Op dezelfde wijze waarop nu cryptografische sleutels en certificaten voor DNSSEC zelf worden georganiseerd, gegarandeerd en uitgewisseld, kunnen straks immers ook de credentials voor andere protocollen worden beheerd.
DNS-based Authentication of Named Entities
DANE, kort voor DNS-based Authentication of Named Entities, is op zijn beurt weer een uitbreiding van DNSSEC. Daarmee kunnen straks ook sleutels en certificaten voor beveiligde websites in het DNS-systeem worden opgenomen. Dit protocol-in-ontwikkeling heeft belangrijke voordelen van opzichte van het bestaande certificaten-systeem.
In de huidige X.509 Public Key Infrastructure (PKI; PKIX) worden de server-certificaten direct geverifieerd door de client. Alle daarvoor benodigde root-certificaten worden met de web-browsers meegeleverd. Zo zijn op dit moment ruim 150 Certificate Authorities (CA's) verantwoordelijk voor de authenticiteit van alle server-certificaten.
Het DigiNotar-debacle, waarbij een digitale inbreker meer dan 500 gewaarmerkte certificaten wist te genereren, heeft ons echter geleerd dat dergelijke concentraties van vertrouwen onze infrastructuur kwetsbaar maken. Deze hack, tezamen met andere, minder grote kraken (Comodo, en Flame) maken dat het hele CA-systeem inmiddels zijn langste tijd lijkt te hebben gehad.
Parallelle veiligheidsinfrastructuur
DANE biedt een parallelle veiligheidsinfrastructuur voor X.509 (paper, presentatie en video) die niet alleen als aanvulling maar voor veel toepassingen ook als volledige vervanging kan fungeren. Daartoe wordt het DNS-protocol uitgebreid met het TLSA record. Dat kan worden gebruikt om sleutelinformatie — bijvoorbeeld een hash code, een digitaal uittreksel — aan een adres/protocol/poort-combinatie te koppelen. Op die manier kan van elke internet-service het server-certificaat via DNS worden geverifieerd.
Met deze aanpak wordt het hele systeem van sleutels en certificaten veel robuuster. De huidige opzet is slechts zo veilig als de zwakste CA. Het server-certificaat fungeert immers als startpunt voor verdere verificatie via de root-certificaten. Als een man-in-the-middle onderweg het server-certificaat vervangt door een eigen certificaat dat hij via een van de CA's heeft weten te vervalsen, dan is dat voor een client nu voldoende om een beveiligde verbinding naar de server op te zetten. Omdat lokaal alles in orde lijkt, zal de browser ook zonder klagen het slotje laten zien.
Kwetsbaar
Behalve dat je die kwetsbaarheid van een gecentraliseerd systeem eruit wilt halen, wil je ook niet afhankelijk zijn van een server-certificaat dat over hetzelfde kanaal (in-line) wordt verzonden. Nu is aan client-zijde immers niet bekend door welke CA een server-certificaat ondertekend zou moeten zijn. Dat kun je alleen zien (maar niet verifiëren!) aan het certificaat zelf op het moment dat je verbinding maakt met de betreffende dienst.
Het Diginotar-debacle heeft laten zien dat een dergelijke gecentraliseerde manier van werken niet alleen kwetsbaar maar ook onhandig is. Want is een CA eenmaal gekraakt, dan moeten gelijk alle bijbehorende server-certificaten ingetrokken en vervangen worden. Voor DigiNotar ging het om vele tienduizenden certificaten die in een keer ongeldig werden.
Wanneer het server-certificaat straks ook met de — met DNSSEC beveiligde — DNS-informatie wordt vergeleken (out-of-band), ziet de client direct dat het aangeboden server-certificaat niet overeenkomt met het TLSA record. En daarmee is deze verbinding dan ongeschikt voor het doen van veilige transacties.
Geen kosten
Omdat de client voor zijn name resolving via DNSSEC al op het DNS-systeem steunt, lijkt dat ook een veel natuurlijker plaats om de verificatie van het server-certificaat onder te brengen. Bovendien worden zo de kwetsbaarheid en de afhankelijkheid van de gecentraliseerde roots bij de CA's weggehaald. DANE isoleert dus veiligheidsproblemen; deze blijven beperkt tot het aangedane domein. Aandachtspunt is dat het zo wel gemakkelijker wordt om beveiligde webservers op te zetten voor valse domeinen. De houder van paypa1.com (let op het cijfer 1 als vervanger voor de letter l) kan gewoon zijn eigen server-certificaat op zijn eigen name-server valideren.
Ander belangrijk argument voor houders om zo snel mogelijk met DNSSEC en daarna DANE aan de slag te gaan, zijn de kosten. Nu moet betaald worden voor de validering van elk server-certificaat. Straks kan men die direct opnemen in zijn eigen DNS-configuratie. Daarmee biedt DANE op veiligheidstechnisch gebied in ieder geval een volwaardig (en beter) alternatief, met name voor self-signed certificaten. Wordt het vertrouwen volledig gebaseerd op de DNSSEC-infrastructuur, dan vindt dat zijn basis voortaan in de root keys van DNSSEC. Daarmee is het trust anchor van de gecentraliseerde CA-certificaten verplaatst naar de lokale TLSA records. Clients hebben hiervoor niets anders nodig dan een kopie van de root keys.
Alleen voor aanvullende diensten hoeft men nog bij een CA aan te kloppen. Denk dan aan adressen en andere informatie zoals die in EV-certificaten (Extended Validation) kan worden opgenomen. Of de aanvullende diensten en garanties van een CA dan nog voldoende meerwaarde bieden om de prijs voor de validering van een server-certificaat te rechtvaardigen, moet per geval afgewogen worden. Niet voor niets zijn CA's helemaal niet blij met de ontwikkeling van DANE als alternatief voor X.509. Omdat het TLSA record niet alleen informatie over het server-certificaat zelf kan bevatten maar ook een verwijzing naar een CA-certificaat, is DANE backward compatible met het bestaande X.509-systeem. Voorlopig zullen beide dus nog naast elkaar blijven bestaan.
Standaard
Onlangs zijn de laatste details van de nieuwe protocol-uitbreiding uitgewerkt door de DANE working group van de IETF (Internet Engineering Task Force). Het ging met name over de wachttijd (seconden) als gevolg van alle controle-slagen die een web-client moet uitvoeren voordat deze zijn gebruiker een veilige verbinding kan garanderen. Het idee is nu om al die informatie door de server te laten ophoesten (als een geserialiseerde vertrouwensketen), zodat de client deze alleen nog hoeft te verifiëren op basis van zijn root keys.
De DANE-specificatie wordt binnenkort als officiële internet-standaard in de vorm van een RFC gepubliceerd. Het protocol wordt al ondersteund in Chrome/Chromium. Voor Firefox is een plugin beschikbaar: de Extended DNSSEC Validator.
Toekomst
Ondertussen kijkt men binnen de DANE-werkgroep alweer verder naar de volgende toepassing van DNSSEC: de beveiliging van mailberichten. Je kunt een vergelijkbare infrastructuur als nu in de maak is voor X.509 immers ook voor S/MIME (Secure/Multipurpose Internet Mail Extensions; secure mail) opzetten. Daarmee kunnen de ondertekening, versleuteling en verificatie van mailberichten voortaan op basis van DNSSEC geschieden. Het DNS-systeem zou dan de publieke sleutels voor alle adressen bij een mail-domein (MX record) bevatten. Daarmee zou het een vervanging zijn voor het huidige web-of-trust gebaseerd op PGP.
