De ontvanger wil binnenkomende mail zo snel mogelijk kunnen classificeren
Een interview met Tim Draegen, mede-bedenker van de DMARC-standaard
Het Platform Internetstandaarden organiseerde onlangs in Den Haag een DMARC-masterclass. De hoofdspreker was Tim Draegen, een van de bedenkers van de DMARC-standaard en mede-oprichter van dmarcian.com. In dit interview vertelt hij over de keuzen die zijn gemaakt om DMARC — een van de eerste use cases voor DNSSEC — zo snel mogelijk doorgevoerd te krijgen, voor welke partijen deze standaard het meest interessant is en welke problemen er nog liggen.
In de huidige SMTP-standaard (zoals gedefinieerd in RFC 5321) is niets geregeld om de afzender van een bericht te verifiëren. In principe kan iedereen berichten voorzien van een willekeurige afzender samenstellen en versturen (mail spoofing). Dagelijks worden dan ook enorme hoeveelheden berichten voorzien van spam, virussen, phishing en andere ellende het net op gepompt.
Authenticatie
DKIM, SPF en DMARC zijn drie gerelateerde standaarden voor de authenticatie van de afzender (een persoon) en de verzender (een mail-server) van mail-berichten:
- DKIM (DomainKeys Identified Mail):
Deze standaard voorziet de inhoud en de header van mail-berichten van een digitale handtekening. Deze kan gevalideerd worden met behulp van de publieke sleutel voor het afzender-domein die via DNS gepubliceerd wordt. - SPF (Sender Policy Framework):
Deze standaard laat eigenaren van mail-domeinen in de DNS aangeven welke mail-servers berichten voor het betreffende domein mogen versturen. Dat zijn typisch de SMTP-servers die eindgebruikers instellen voor uitgaande berichten, maar bijvoorbeeld ook de adressen van een externe dienstverlener die namens een organisatie marketing-mail verstuurd. Ontvangende mail-servers (MX) kunnen op die manier controleren of een mail-server überhaupt wel berichten voor het betreffende domein mag versturen alvorens deze aan te pakken. - DMARC (Domain-based Message Authentication, Reporting and Conformance):
Deze standaard laat eigenaren van een mail-domein een policy in hun DNS publiceren waarin staat aangegeven wat er met berichten moet gebeuren die niet door de DKIM- en/of SPF-controle komen. Bovendien kan een mail-adres worden gespecificeerd waarop ontvangende mail-servers kunnen terugrapporteren wat er aangeboden is en hoe die berichten zijn verwerkt. Op die manier kan een beheerder inzicht krijgen in hoe zijn mail-domein in de buitenwereld wordt gezien.
Hoewel deze drie standaarden meestal gezamenlijk worden ingezet, hoeft dat niet persé. Je kunt ook alleen DKIM of SPF inzetten, of DMARC weglaten. De portal dmarcian.com biedt op dit moment (tegen betaling) de mogelijkheid om de binnenkomende DMARC-rapportages te verwerken tot keurige statistieken en diagrammen.
Classificatie
Bij de afweging wat wel en niet te implementeren, is het goed om vanuit het perspectief van de ontvanger te kijken,
vertelt Draegen. Die is op zoek naar een positief signaal om een bericht als authentiek te kunnen classificeren. En of dat nou op basis van DKIM of SPF gebeurt, dat maakt hem eigenlijk niet uit. Doe je allebei, des te beter, maar in principe is een van de twee voldoende.
Aan de integriteit die de digitale handtekeningen van DKIM aan de berichten toevoegen hecht Draegen weinig waarde. Een ontvangende mail-server is niet in eerste instantie geïnteresseerd in de integriteit van de berichten. Waar het om gaat is dat zowel met DKIM als met SPF duidelijk is wie de afzender van een bericht is. Wordt er vanuit die infrastructuur ineens spam verstuurd, dan heb je een aanspreekpunt. Maar zonder kun je helemaal niemand aanspreken die vanaf een willekeurige infrastructuur vervalste berichten de wereld in stuurt.
Efficiënter verwerking
Belangrijkste doel van deze drie standaarden is om de verwerking van mail efficiënter te maken,
aldus Draegen. Veel organisaties maken gebruik van twee grote bakken: mail van ongeauthenticeerde domeinen of van wel geauthenticeerde domeinen die nog niet eerder gezien zijn enerzijds en bewezen gewenste mail-domeinen anderzijds. Voor die laatste categorie is het simpel: die berichten kunnen gelijk afgeleverd worden. Berichten van onbeveiligde en nog onbekende domeinen moeten uitvoerig gecontroleerd worden. Daarvoor zet je dan meer resources in. Bovendien loont het om even te wachten met de beslissing: een zero-day staat nog op geen enkele lijst. Grote kans dat de classificatie van zo'n bericht even later veel eenvoudiger is.
SpamAssassin ondersteunt deze manier van werken nog niet out-of-the-box. Maar het Trusted Domain Project biedt wel al de tooling om zoiets zelf op te zetten.
RFC 7489
Hoewel RFC 7489 waarin de DMARC-standaard beschreven staat lang en lastig leesbaar is, is de standaard zelf volgens Draegen juist zo eenvoudig mogelijk gehouden. De DMARC-specificatie was een stuk zwaarder dan wat er normaal gesproken vanuit de IETF komt, maar dat komt omdat we zo veel mogelijk van de verantwoording en beredenering van de gemaakte keuzen wilden toevoegen.
Deelnemers wilden in eerste instantie erg ingewikkelde opties kunnen gebruiken, bijvoorbeeld de mogelijkheid om berichten drie dagen in quarantaine te zetten als SPF wel maar DKIM niet valideerde. Gelukkig hebben we uiteindelijk kunnen afspreken om het juist zo simpel mogelijk te houden, anders gaan mensen de standaard sowieso niet gebruiken. Uiteindelijk is het een behoorlijk goede technische specificatie geworden, maar ga 'm vooral niet van begin tot eind doorlezen, behalve als je een ingenieur bent die 'm moet implementeren natuurlijk.
DNSSEC
Om dezelfde reden is DNSSEC voor alle drie beveiligingsstandaarden wel aan te raden maar niet verplicht. Dat betekent dat met name DKIM niet noodzakelijk van een trust anchor wordt voorzien. Dat is een belangrijk verschil met bijvoorbeeld DANE, waar DNSSEC wel een verplicht onderdeel van de standaard is. We hebben de afweging om DMARC en DNSSEC te ontkoppelen al vanaf het begin gemaakt,
aldus Draegen. Je kunt de ene standaard niet voor de ander plaatsen. DNSSEC bestaat al heel lang, maar net als de transitie naar IPv6 heeft het lange tijd nodig om voldoende massa te bereiken. Het enige dat je kunt doen is om alles tegelijk te pushen.
In de 'DNS Security'-sectie (12.3) onderkennen we wel het belang van DNS voor deze standaard — maar dat geldt voor vrijwel het hele Internet — en raden we ten zeerste aan om DMARC samen met DNSSEC te gebruiken. Maar we wilden niet dat mensen zouden wachten met de implementatie van DMARC totdat ze DNSSEC hadden uitgerold, want ook die standaard moet nog volwassen worden. Wat we van DMARC hebben geleerd is dat er een heleboel makkelijk bruikbare tools moeten zijn willen mensen een technologie daadwerkelijk implementeren. En voor DNSSEC moet er nog een heleboel gebeuren om die technologie veel makkelijker inzetbaar te maken. Zolang een domeinnaamhouder nog steeds niet op een knop kan drukken om DNSSEC aan te zetten is het niet goed genoeg.
Phishing
De drijvende kracht achter de adoptie van DMARC waren grote mail-verwerkers die veel last van hadden van phishing,
zegt Draegen. Die social-media-bedrijven — Facebook is verreweg de grootste mail-verwerker ter wereld — bestaan nog niet zo lang, dus die hebben nog een goed geconsolideerde mail-infrastructuur. Zij zetten DMARC binnen een week op.
Dat is heel anders voor een bank die te maken heeft met een dertigjarige historie van fusies en acquisities. Als zo'n bedrijf deze beveiligingsstandaarden wil implementeren moeten zij misschien systemen onder handen nemen die al tien jaar niet aangeraakt zijn. Dat krijg je intern natuurlijk niet verkocht. Alleen voor jonge bedrijven die veel last hebben van spam valt de RoI-berekening goed uit.
Oudere bedrijven hebben waarschijnlijk meer tijd en betere gereedschappen nodig. Dan wordt een probleem van 50 miljoen euro misschien 40 of 20 miljoen. Totdat een kantelpunt is bereikt en men besluit om zijn infrastructuur onder handen te nemen.
Kostenbesparingen
Andere grote gebruikers zijn de mail-marketeers,
vervolgt Draegen. Je kunt ze legitieme spammers noemen. Zij hebben er groot belang bij dat hun berichten aankomen en waren dus makkelijk over te halen om deze beveiligingsstandaarden te implementeren. Bovendien is het inherent aan hun business dat zij een goed gedefinieerde en moderne mail-infrastructuur hebben.
De volgende stap zijn de internet providers. Zij kunnen hun mail filtering sterk vereenvoudigen. Door een apart subdomein voorzien van DMARC te gebruiken kunnen bedrijven als Amazon en AliExpress de 'bezorgbaarheid' van hun berichten verbeteren. Voor providers is het verwerken van een mail-domein als receipts.amazon.com een fluitje van een cent. Zij hoeven alleen te controleren of zij dit domein al eerder hebben gezien en of die mail gewenst was. Dat levert belangrijke besparingen op.
Hetzelfde geldt voor de DMARC-rapportages die ontvangers terugsturen naar de domein-eigenaren. Klanten waarvan de binnenkomende mail ten onrechte in de spambox is verdwenen kunnen nu immers naar de verzender worden verwezen. Dat verlaagt de support-kosten; die verplaatsen zich nu voor het eerst naar de verzender. Veiligheid en anti-phishing waren geen argumenten voor deze partijen; de kostenbesparingen wel.
Inzicht
Naarmate meer mail-verwerkers DKIM, SPF en DMARC implementeren, wordt het voor domeinnaamhouders belangrijker om DMARC records te publiceren. Niet meedoen betekent immers dat berichten misschien niet aankomen. We zien allerlei gebruikers op dmarcian.com, ook makelaars en autowasseretten,
vertelt Draegen. De afgelopen veertig jaar hebben we mail zonder al te veel problemen gewoon kunnen gebruiken. Nu hebben zij discussies met hun klanten omdat de mail niet altijd afgeleverd wordt en omdat er valse berichten uit hun naam worden verstuurd. Dat levert een heleboel communicatieproblemen en ergernis op. Pas als zij DMARC gaan gebruiken krijgen zij inzicht in wat er met hun domein gebeurt.
Met name kleine en middelgrote domeinen worden vaak misbruikt in een roterende lijst van afzender-adressen. De enige manier om daar grip op te krijgen is door jezelf te identificeren met behulp van een DMARC record. Heb je dat eenmaal gedaan, dan verdwijn je vanzelf van die lijsten. Bovendien krijg je nu rapportages terug van de ontvangers, waar je voorheen alleen een piek in je DNS-verkeer zag en een hoop gebouncte berichten.
'Bad bank'
Hoewel DMARC relatief snel wordt ingevoerd — vergeleken met DNSSEC en IPv6 — zijn nog niet alle problemen met de beveiligingsstandaarden opgelost. Met name het automatisch forwarden van berichten en het gebruik van mailing lists werkt niet goed in combinatie met SPF. Daarbij blijft immers het oude afzender-domein staan terwijl de mail van een vreemde server af komt. Er zijn wel allerlei deeloplossingen in de maak,
zegt Draegen, maar we zijn er nog niet uit. Op dit moment is de beste 'oplossing' om voor deze toepassingen een apart subdomein aan te maken — een beetje als een 'bad bank' — om zo de problemen te isoleren. Ondertussen werken ontwikkelaars aan de ondersteuning van deze beveiligingsstandaarden in hun mailing list software.
Maar er zijn een heleboel verschillende manieren waarop het mis kan gaan. Zeker verschillende combinaties — eerst forwarding en dan naar een mailing list, of andersom — maken dit een heel ingewikkeld probleem waar geen eenduidige oplossing voor is.
Puntoplossingen
E-mail is altijd een open protocol geweest,
aldus Draegen, waarbij iedereen vrij was om er zijn eigen toepassingen bovenop te bouwen. DKIM, SPF en DMARC hebben consequenties voor die toepassingen. Maar voorheen kon je op nieuwssites ook een willekeurig afzender-adres invullen als je iemand op een interessant artikel wilde wijzen. Dat bericht werd dan bijvoorbeeld vanaf het domein van de New York Times verstuurd. Daar wilde men van af, dus nu zijn zij zelf de afzender van die alert.
De IETF onderzoekt op dit moment of er een min-of-meer generiek raamwerk voor deze problematiek ontwikkeld kan worden. Maar sommige deeloplossingen zijn zo zwaar dat we nu eigenlijk al weten dat ze niet geïmplementeerd zullen worden. Voorlopig blijft het dus bij een spectrum van puntoplossingen die in verschillende software-pakketten geïmplementeerd worden. De rol van de IETF is om die oplossingen te documenteren.
