Nieuwe kans voor DANE voor het web

DANE en DNSSEC

Hoewel DANE inmiddels meer dan 10 jaar oud is, begint deze beveiligingsstandaard nu pas door te breken, en dan ook maar voor de helft. De standaard is gedefinieerd (in RFC 6698, 7218 en 7671) voor algemeen gebruik: TLS-servercertificaten (volgens X.509) worden verankerd door de hash van een certificaat te publiceren in een TLSA-record. Omdat het gebruik van DNSSEC bij DANE verplicht is, is de authenticiteit van het betreffende certificaat via de vertrouwensketen (chain of trust) naar het DNSSEC trust anchor cryptografisch gegarandeerd.

Naast de hashwaarde zelf bevat het TLSA nog het Usage-veld, dat bepaalt hoe de hash geïnterpreteerd moet worden:

• 0) PKIX-TA: verankert een specifiek CA-certificaat in de TLS-vertrouwensketen (in aanvulling op de traditionele validatie)

• 1) PKIX-EE: verankert een specifiek servercertificaat (in aanvulling op de traditionele validatie)

• 2) DANE-TA: verankert een specifiek CA-certificaat in de TLS vertrouwensketen, dat daarmee als trust anchor fungeert

• 3) DANE-EE: verankert een specifiek servercertificaat, dat overeen moet komen met het door de server aangeboden certificaat

DANE voor web en DANE voor mail

Usage nummer 0 en 1 verankeren een certificaat van respectievelijk een CA of een server in aanvulling op de traditionele validatie met behulp van de trust anchors meegeleverd in de client (typisch: de webbrowser). Vandaar dat deze eerste 2 opties 'restrictief' worden genoemd (een extra beveiligingsvoorwaarde op het bestaande systeem). Usage 2 en 3 werken onafhankelijk van de traditionele TLS-validatie, en dat maakt ze (ook) geschikt voor self-signed certificaten. Bovendien kunnen op deze manier clients bediend worden die helemaal geen trust anchors aan boord hebben. Deze 2 opties worden 'additief' genoemd (een nieuwe mogelijkheid ten opzichte van het bestaande systeem).

Voorbeeld van een protocol waarbij clients geen trust anchors bevatten is SMTP voor het transport van e-mailberichten. RFC 7672 specificeert de details van DANE voor mailuitwisseling tussen MTA's. Omdat mailservers geen trust anchors bevatten, mogen alleen Usage nummers 2 en 3 hier gebruikt worden. Bovendien is DANE voor mail een opportunistisch protocol: een TLSA-record bevestigt voor een client een specifiek servercertificaat (en daarmee impliciet de ondersteuning van STARTTLS, maar verplicht de client niet om TLS daadwerkelijk te gebruiken om een bericht af te leveren.

Op dit moment wordt DANE voor het web eigenlijk niet toegepast [1, 2], terwijl DANE voor mail [1, 2] sterk in opkomst is (of was).

Een lange geschiedenis

De geschiedenis van de TLS-uitbreiding voor de DNSSEC-vertrouwensketen voor DANE – kortweg de ketenuitbreiding – gaat terug tot de ontwikkeling van DANE zelf meer dan 10 jaar geleden. De eerste implementatie van een DANE-achtige ketenuitbreiding voor Chrome (door Adam Langley) verdween binnen 2 jaar weer uit de browser omdat de uitbreiding ongeschikt bleek en niet gebruikt werd. Bij deze proof-of-concept werd de DNS(SEC)-keten in een uitbreiding van het certificaat zelf (een zogenaamd 'DNSSEC stapled certificate') opgenomen. Het TLSA-record bestond nog niet; daarvoor werd een TXT-record gebruikt.

Deze aanpak viel echter niet goed bij de CA's: Zij moesten een nieuw blok in hun ondertekening meenemen. Bovendien vereiste het vernieuwen van de DNSSEC-handtekeningen ook een verversing van het certificaat. Dat zou tot allerlei ongewenste en onwerkbare afhankelijkheden tussen het PKI/CA-systeem en DNSSEC leiden.

Een nieuwe aanpak

In de jaren 2015-2018 werd gewerkt aan de voorloper van de huidige specificatie. Deze oplossing introduceerde een nieuwe optie in het TLS-protocol, waarmee de client de bijbehorende DANE/DNS(SEC)-keten kan opvragen. De server fungeert daarbij alleen als doorgeefluik: deze vraagt lokaal de benodigde records op en stuurt deze in geserialiseerde vorm naar de client via de openstaande verbinding. Op die manier wordt gebruikgemaakt van de al aanwezige resolver-functionaliteit en caching. Bovendien verkrijgt de client (op applicatie-niveau) hiermee end-to-end-validatie, ook als deze alleen een (niet-DNSSEC-validerende) stub resolver bevat.

Cruciaal onderscheid met de eerste oplossing is dat je op deze manier niet voor je DANE afhankelijk wordt van de CA's. Zowel de TLS-gemeenschap als de browser-bouwers (Richard Barnes, destijds werkzaam bij Mozilla – zijn 'DNS Security'-artikelreeks vind je hier) waren enthousiast over deze aanpak.

Ruzie

Hoewel Mozilla destijds al een implementatie voor zijn Firefox-browser gereed had, heeft ook dit voorstel het niet gered. Het ondersteunde alleen additieve DANE en de ketenuitbreiding bleef beperkt tot het doorgeven van de DANE/DNS(SEC)-records. Victor Dukhovni, nu vooral bekend van zijn DANE-adoptiemetingen, wees erop dat deze aanpak kwetsbaar was voor een downgrade-aanval door een man-in-the-middle (MITM). Als je alleen vertrouwt op het alternatieve kanaal en het DNS-systeem zelf niet checkt, weet je immers niet zeker of er echt geen DNSSEC-records aanwezig zijn als dat alternatieve kanaal dat aangeeft.

De 2 bezwaren zijn echter gerelateerd en worden ook misbruikt om de commerciële belangen van de CA's te beschermen: zolang de beschikbare DANE-functionaliteit het PKI/CA-systeem niet volledig vervangt, is er ook geen ondersteuning voor additieve DANE.

Dukhovni sprak van een ernstig veiligheidsgat en wilde dat ook certificate pinning ondersteund zou worden. De web-gemeenschap had echter zowel moeite met zijn toon alsook slechte ervaringen met pinning (denk aan HPKP, de voorloper van HSTS). Na een jaar discussie zijn dan ook zowel de TLS Working Group als Barnes afgehaakt.

Nieuwe kans

Met Dukhovni en securitysoftware engineer Paul Wouters als nieuwe leden, heeft de groep het voorstel voor de ketenuitbreiding vervolgens verder ontwikkeld als Independent Submission Stream. Met de toevoeging van pinning door Dukhovni is deze experimentele specificatie nu klaar voor implementatie.

Ondanks dat DNSSEC nauwelijks leeft bij de eindgebruiker, heeft Willem Toorop, ontwikkelaar en onderzoeker bij NLnet Labs en medeauteur van deze RFC, goede hoop op de adoptie van de ketenuitbreiding. "We moeten niet proberen om lang bestaande TLS-toepassingen als IMAPS en POPS (in de mail-client) van deze beveiliging te voorzien. Onze kansen zijn veel beter bij nieuwe technologieën als DoH en DoT. Er gebeurt nu heel veel met DoH in de webbrowser."

"Zo wordt er momenteel gewerkt aan een methode om TLS vanaf het allereerste begin te versleutelen: Encrypted Client Hello (ECH). De TLS handshake is op dit moment namelijk nog niet versleuteld, zodat de service waarnaar een verbinding wordt opgezet niet beschermd is. Bij ECH staat het publieke gedeelte van het sleutelpaar waarmee ook de handshake wordt versleuteld in een speciaal DNS-record: het SVCB- of HTTPS-record. Het idee is dat deze records beschikbaar zijn voor de browsers via de ingebouwde DoH. Om de authenticiteit van deze records (en daarmee de bescherming van de TLS handshake) te waarborgen heb je weer DNSSEC nodig."

"Zo zie je dat DNSSEC steeds weer opduikt bij dit soort nieuwe, toekomstige standaarden (bijvoorbeeld ook hier). En nu de browser-bouwers steeds meer met DNS doen in hun software, stijgen ook de kansen voor DNSSEC en DANE."