Een ondertekend bericht kan nog steeds spam zijn. Het ondertekeningsdomein kan ook afwijken van het adres dat de ontvanger te zien krijgt.
Wat dekt een DKIM-handtekening?
Een DKIM-handtekening beschermt geselecteerde headervelden en een hash van de body.
De h=-tag vermeldt de ondertekende headervelden. De bh=-tag bevat de body-hash. De verzendende server produceert de handtekening met zijn privésleutel. Ontvangers verifiëren deze met de bijbehorende publieke sleutel.
Een ontvanger herberekent de body-hash. Daarnaast verifieert hij de handtekening over de geselecteerde headers en de handtekeningheader, die die hash bevat.
RFC 6376 vereist ondertekening van de From-header. Andere headervelden kunnen onondertekend blijven. Een onondertekende Reply-To toevoegen kan DKIM daarom geldig laten.
Herhaalde headers vereisen aparte behandeling. De ondertekenaar kan een headernaam vaker vermelden dan deze voorkomt, om te voorkomen dat een extra exemplaar onopgemerkt wordt toegevoegd.
Waar vindt de ontvanger de publieke sleutel?
De ontvanger lokaliseert de publieke sleutel met het ondertekeningsdomein en de selector, de naam die die sleutel identificeert. De d=-tag geeft het domein. De s=-tag geeft de selector.
Voor d=example.com en s=foo.bar is de opzoeknaam foo.bar._domainkey.example.com. De selector maakt verschillende sleutels onder hetzelfde ondertekeningsdomein mogelijk.
Publiceer bij rotatie de vervangende sleutel voordat je ermee ondertekent. Houd de oude verificatiesleutel beschikbaar zolang berichten die ermee zijn ondertekend nog onderweg zijn. Te vroeg verwijderen voorkomt dat ontvangers die berichten kunnen verifiëren.
Waarom kunnen opmaakwijzigingen een handtekening breken?
Canonicalisatie, de normalisatie die wordt toegepast vóór ondertekening en verificatie, bepaalt welke opmaakwijzigingen DKIM tolereert.
De c=-tag kiest afzonderlijke algoritmen voor header en body. In relaxed/relaxed gebruiken beide relaxed-normalisatie.
| Algoritme | Headergedrag | Bodygedrag |
|---|---|---|
simple | Behoudt headeropmaak | Negeert lege regels aan het einde |
relaxed | Normaliseert hoofdlettergebruik, folding en witruimte van headernamen | Normaliseert witruimte en afsluitende lege regels |
Een gevouwen header gaat verder op een volgende regel. Relaxed-headerverwerking tolereert die vouwen. Simple-verwerking kan falen nadat een server dezelfde header opnieuw vouwt.
Vergelijk de ondertekende inhoud vóór en na de falende relay, want een onzichtbare opmaakwijziging kan het resultaat verklaren.
Welke ondertekeningsalgoritmen ondersteunt DKIM?
DKIM ondersteunt de ondertekeningsalgoritmen RSA en Ed25519, beide gecombineerd met SHA-256.
RSA heeft een minimale sleutelgrootte van 1024 bits onder RFC 8301. Kortere sleutels bieden onvoldoende weerstand tegen sleutelcompromittering.
De aanbevolen RSA-grootte is minimaal 2048 bits, wat meer weerstand biedt tegen sleutelcompromittering. Kies die grootte als je ondertekeningssysteem dit ondersteunt. De specificatie verbiedt rsa-sha1 voor ondertekening en verificatie.
RFC 8463 voegt ed25519-sha256 toe. Een bericht kan zowel RSA- als Ed25519-handtekeningen bevatten voor compatibiliteit met ontvangers die verschillende algoritmen ondersteunen.
Yahoo's richtlijn vereist ook een minimale DKIM-sleutel van 1024 bits.
Wat gebeurt er als een mailinglijst het bericht bewerkt?
Een bewerking kan DKIM ongeldig maken wanneer deze inhoud wijzigt die door de handtekening wordt gedekt.
Doorsturen op zich wijzigt de ondertekende inhoud niet. Een intacte handtekening kan het overleven. Een toegevoegde footer kan de body-hash wijzigen. Een herschreven ondertekend Subject kan de headerhandtekening ongeldig maken.
De optionele l=-tag beperkt de bodydekking tot een opgegeven aantal bytes. Met l=100 is inhoud na de eerste 100 genormaliseerde bytes onbeschermd. Misleidende tekst toevoegen kan de handtekening daardoor geldig laten.
Vermijd die limiet als je de volledige body beschermd wilt houden. ARC laat tussenstations ondertekend bewijs van authenticatie bewaren vóór hun bewerkingen.
Hoe configureer je DKIM met Bird?
Je publiceert het DKIM-record dat wordt teruggegeven wanneer je je verzenddomein registreert.
Het dkim.mode-veld van API staat standaard op txt. Met die modus publiceer je de publieke sleutel in een TXT-record. Het schema vermeldt ook delegated. Die waarde retourneert HTTP 422 wanneer je een verzenddomein registreert, dus gebruik txt.
Bird maakt een aparte sleutel en selector aan voor elke organisatie die een verzenddomein gebruikt. Organisaties die hetzelfde domein gebruiken hoeven geen ondertekeningssleutel te delen.
De authenticatiegids legt het teruggegeven record uit.
Bewijst een geslaagde handtekening dat het bericht veilig is?
Een geslaagde handtekening stelt verantwoordelijkheid vast voor de ondertekende inhoud. Het stelt niet vast of het bericht gewenst of betrouwbaar is.
Het vereist ook niet dat het ondertekeningsdomein overeenkomt met het zichtbare From-domein. DMARC levert die afstemmingsregel via alignment. Afzenderreputatie, de beoordeling van het verkeer van een afzender door de ontvanger, blijft een aparte overweging.
Kort gezegd
Alleen geselecteerde inhoud is beschermd.
DKIM dekt de vermelde headervelden en een body-hash. Onbeschermde inhoud kan veranderen zonder de handtekening ongeldig te maken.
Selectors lokaliseren verificatiesleutels.
De selector en het ondertekeningsdomein identificeren het DNS-record met de publieke sleutel.
Normalisatie beïnvloedt verificatie.
De simple- en relaxed-algoritmen behandelen opmaakwijzigingen verschillend.
Doorsturen garandeert geen pass.
Een intacte handtekening kan doorsturen overleven, maar wijzigingen aan ondertekende inhoud kunnen deze breken.