English Nederlands Español Italiano 日本語 Français
Log in

DKIM|strategie

DKIM-ondertekening werkend krijgen is maar de helft van het werk. De andere helft is bepalen hoe je de sleutelparen erachter beheert: krijgt elk domein een eigen sleutelpaar, mag een externe partij er één delen over al haar klanten, en hoe vaak roteer je. Doe je dit verkeerd, dan kan één gelekte sleutel veel meer dan één domein raken. (Nieuw met DKIM? Begin bij DKIM | richtlijnen voor de basis.)

Zie het als een huissleutel

Een gedeeld DKIM-sleutelpaar is als dezelfde huissleutel aan alle huurders van een pand geven: makkelijk te beheren, maar verliest één huurder hem, dan moet elk slot vervangen worden. Een uniek sleutelpaar per domein is een apart slot per deur: meer sleutels om bij te houden, maar het verlies van één raakt alleen die deur.

Waarom dit belangrijk is

DKIM gebruikt een publiek/privaat sleutelpaar, en hoe dat paar wel of niet gedeeld wordt, heeft directe gevolgen voor de beveiliging. Een sleutelpaar dat over veel domeinen of klanten wordt gedeeld, is operationeel handig, maar als het ooit gecompromitteerd raakt (of simpelweg wordt teruggerekend, want sleutelsterkte neemt af naarmate rekenkracht toeneemt), staat elk domein dat het gebruikt in één keer bloot. Een uniek sleutelpaar per domein beperkt dat risico tot één domein, ten koste van meer paren om bij te houden en te roteren.

Uniek versus gedeeld sleutelpaar

Uniek sleutelpaar

Het grote voordeel van een uniek sleutelpaar per domein is inperking: raakt één domein gecompromitteerd, dan hoeft alleen dat sleutelpaar vervangen te worden. Dit is vanuit beveiligingsoogpunt de sterkere keuze, maar betekent meer operationele inspanning: meer sleutelparen om te genereren, te publiceren en volgens schema te roteren.

Gedeeld sleutelpaar

Eén sleutelpaar dat over meerdere domeinen wordt gebruikt (of over een hele domeinportefeuille) is operationeel veel makkelijker te beheren. Het nadeel zit in de beveiliging: één gecompromitteerde of teruggerekende private key stelt elk domein bloot dat hem deelt. Dit is geen aanbevolen praktijk vanuit beveiligingsoogpunt, ook al komt het regelmatig voor bij externe verzenders.

Gedeelde sleutels betekenen gedeeld risico

Sommige externe partijen gebruiken hetzelfde DKIM-sleutelpaar voor al hun klanten. Raakt die sleutel ooit gecompromitteerd, dan worden alle domeinen die erop vertrouwen tegelijk geraakt, niet alleen die van jou.

Ik wil meer weten

De uitleg hierboven dekt de kernafweging. De rest van dit artikel gaat over best practices voor het dagelijks beheren van sleutelparen, en waar je op moet letten als een externe partij DKIM-ondertekening namens jou uitvoert.

Best practices

  • Vermijd gedeelde sleutelparen waar mogelijk: een gecompromitteerde gedeelde sleutel stelt in één keer elk domein bloot dat hem gebruikt.
  • Selectornamen moeten uniek zijn per ondertekenend domein: hergebruik van een selectornaam voor verschillende verzenders bij hetzelfde domein leidt tot DKIM-fouten.
  • Roteer sleutelparen volgens een vast schema; zie DKIM | richtlijnen voor de aanbevolen frequentie en overlapperiode.
  • Houd een overzicht bij van elke verzender en de DKIM- die daarbij hoort, zodat dezelfde nooit per ongeluk hergebruikt wordt.
  • Laat waar mogelijk de verzendende externe partij het DKIM-sleutelbeheer volledig voor haar rekening nemen; zie DKIM | externe leveranciers voor hoe je dit via een delegeert terwijl je zelf de controle over de verwijzing behoudt.

Werken met externe partijen

Niet elke provider gaat op dezelfde manier om met DKIM-sleutelbeheer. Sommige, zoals Amazon SES, laten je kiezen: beheer je eigen sleutelpaar zelf, of geef de verantwoordelijkheid aan de provider (Amazon noemt die beheerde optie “Easy DKIM”). Andere providers geven je helemaal geen keuze. Het loont om vóór je met een verzender in zee gaat te controleren welk model ze hanteren, en of ze je een uniek sleutelpaar geven of er één delen over hun hele klantenbestand.

Of een externe partij al namens meerdere domeinen ondertekent, de jouwe inbegrepen, is het waard om direct tegen je eigen verzendinfrastructuur te controleren, aangezien dat rechtstreeks bepaalt hoeveel risico één gecompromitteerde sleutel vertegenwoordigt.

Bronnen & verder lezen