DNSSEC als fundament onder andere beveiligingsprotocollen
DNSSEC is geen op zichzelf staande beveiligingsstandaard. Het fungeert ook als fundament onder nieuwe protocollen die bijvoorbeeld de veiligheid van server-certificaten voor web en mail versterken. Daarnaast worden allerlei bestaande beveiligingsprotocollen met de toepassing van DNSSEC automatisch van een cryptografische basis voorzien.
DNSSEC heeft op dit moment als op zichzelf staande beveiliging nog maar beperkte waarde. De kans op een Kaminsky-aanval is immers nog maar klein. Hoewel de op DNSSEC gebaseerde DANE-standaard om te beginnen als aanvullende beveiliging op de TSL/SSL server-certificaten kan worden ingezet, zal een deel daarvan ook kunnen worden vervangen door self-signed certificaten. Veel certificaten worden nu immers alleen bij een officiële CA (Certificate Authority) aangeschaft om bezoekers die irritante popup-up bij gebruik van een self-signed certificaat te besparen. In eerste instantie zullen certificaten voor websites kunnen worden vervangen, later ook die voor mail (S/MIME en SMTP-STARTLS) en andere beveiligde protocollen. Dat biedt hosters en houders uitzicht op forse besparingen.
Maar DNSSEC kan ook gebruikt worden om andere security-gerelateerde protocollen te beveiligingen. Daarmee wordt immers een cryptografisch fundament gelegd onder alle informatie die middels DNS records beschikbaar gemaakt wordt. Eerder vertelde Paul Wouters, senior software engineer bij Red Hat en auteur van de ExtVal-plugin voor Firefox, erover te denken om een IETF Draft te schrijven voor GPGFP en OTRFP. Daarmee kunnen dan ook PGP/GPG fingerprints en OTR fingerprints (Off-the-Record Messaging) veilig via DNSSEC worden opgevraagd.
Hieronder bespreken we kort twee al bestaande beveiligingsprotocollen die met DNSSEC van een extra bescherming kunnen worden voorzien: DKIM (voor mail gateways) en SSHFP (voor SSH servers).
DKIM
DKIM, kort voor DomainKeys Identified Mail, is een protocol waarmee verzenders van mail kunnen laten zien dat zij inderdaad degene zijn die een bericht hebben verstuurd, en dat zij daartoe ook bevoegd zijn. Deze beveiliging koppelt het bericht aan de mail gateway, en die gateway weer aan het afzender-domein. Op die manier kan de ontvanger er redelijkerwijs van uitgaan dat het niet om spam gaat.
Het mechanisme is niet ingewikkeld: de versturende MTA (Message Transfer Agent) voegt voor het verzenden een extra header field toe aan het bericht. Dat 'DKIM-Signature:' veld bevat een ondertekende hash (een uittreksel) van de body en de header. Omdat de publieke sleutel van het cryptografische sleutelpaar waarmee die digitale handtekening is gezet via DNS opgevraagd kan worden, kan een ontvanger verifiëren dat het mail-bericht inderdaad door een gateway horende bij het betreffende domein is verstuurd.
Configuratie
Het opzetten van een DKIM-beveiligde mail gateway is relatief eenvoudig. Er wordt om te beginnen een sleutelpaar gegenereerd. Daarvan wordt de private sleutel in de gateway geïnstalleerd en gebruikt om doorgaande berichten van een DKIM header field te voorzien. De publieke sleutel wordt met wat extra informatie in een TXT record voor de naam _domainkey.example.com. gezet. Eventueel kunnen nog aanvullende administratieve records (ADSP, SPF en DMARC) worden toegevoegd.
IN TXT "v=spf1 mx a ip4:198.51.100.0/24 ip6:2001:db8::/32 a:senders.example.com -all"
IN SPF "v=spf1 mx a ip4:198.51.100.0/24 ip6:2001:db8::/32 a:senders.example.com -all"
_domainkey IN TXT "t=y; o=~;"
_adsp._domainkey IN TXT "dkim=unknown"
sel20130501._domainkey IN TXT "t=y; v=DKIM1; p=MIGfDCBiQKBgEP7KpcI2255Z0vP2PUz7/HJ9TvMe4CG/Brw0V3o5Yt+FAv5bfmNQIDAQAB;"
_dmarc IN TXT "v=DMARC1; p=none; sp=reject; adkim=s; aspf=s; rua=mailto:postmaster@example.com; ruf=mailto:postmaster@example.com"
Daarna is het zaak om de mail clients van de gebruikers zo te configureren dat voor al hun uitgaande berichten de zojuist geprepareerde SMTP gateway wordt gebruikt (en bijvoorbeeld niet die van hun internet-provider). Dat kan het gemakkelijkst door voor de eigen medewerkers een afgeschermde SMTP-ingang te creëren op poort 587 van de gateway. Alle mail die naar buiten moet worden doorgestuurd kan dan automatisch van een DKIM-handtekening worden voorzien.
Andersom moet voor een volledige implementatie op poort 25 van de mail exchange (MX) de verificatie van DKIM-velden worden aangezet. Ook virus- en spam-scanners kunnen die informatie weer gebruiken om de binnenkomende berichten te beoordelen.
Inmiddels wordt DKIM ondersteund door alle bekende MTA software: Exim, Postfix, qmail (IndiMail) en sendmail.
SSHFP
Waar DKIM een protocol is dat voor alle gebruikers automatisch ingezet kan worden zonder dat zij daar ooit iets van zien, is SSHFP een bescherming die met name van belang is voor beheerders. In eerste instantie gaat het natuurlijk om SSH (Secure Shell) en aanpalende diensten als SFTP en zijn voorloper SCP. Maar ook andere protocollen en programma's die via SSH getunneld worden krijgen met DNSSEC een extra bescherming. Denk aan VNC (Virtual Network Computing, desktop sharing), SSHFS (SSH Filesystem) en VPN (Virtual Private Network).
In tegenstelling tot DKIM dat gebruik maakt van de generieke TXT records heeft SSHFP zijn eigen record type. In RFC 4255 staat beschreven wat dit SSHFP record precies moet bevatten: de finger print (een hash) van de publieke sleutel van de host. Daarmee hebben gebruikers een vertrouwd kanaal om die publieke sleutel te verifiëren, alvorens zij hun vertrouwelijke data naar de betreffende host sturen. Wat dat betreft doet SSHFP hetzelfde voor SSH als DANE doet voor webservers.
hostname IN SSHFP 1 1 5341B8BD6795B73321CC91F2CB1687B0BB0B280B
