DKIM-Signatur

1. Allgemeines

DKIM ist ein Signatur-Verfahren für E-Mails. Die Signierung des Mailinhaltes erfolgt hierbei durch den versendenden Mailserver bzw. einem Mailserver, durch den die Mail unterwegs weitergeleitet wurde (Mailprovider, Mailinglistenserver). Der empfangende Mailserver kann dann diese Signatur mit Hilfe des DNS verifizieren. Hierfür ist in der Signatur eine Domain angegeben, für die man im DNS DKIM-TXT-Records abfragen kann. Mit Hilfe der Angaben in diesem Record (u.a. ein Publickey) und dem RSA-Verfahren kann die Signatur verifiziert werden.
 

Der empfangende Mailserver kann also feststellen, ob diese Mail durch eine bestimmte Domain signiert wurde und ob die Mail danach unterwegs inhaltlich verändert wurde.

1.a. Vorteile

•  Modifikationen von Mails auf dem Weg werden erkennbar.
   
• Spam-Whitelisten werden zuverlässiger und einfacher pflegbar, da der Header-From signiert ist und unterwegs nicht gefälscht werden kann.

1.b. DKIM ist aber keine Lösung für:

•  Vertraulichkeit
  Die Vertrauensbasis bildet die DKIM-Signatur-Domain, nicht der einzelne Absender. Eine Signatur/Verschlüsselung seitens des Absenders ist für die Vertraulichkeit daher trotzdem notwendig.
   
• Spam-/Malware-Abwehr
  Spammer können für ihre eigenen Domains DKIM-Records im DNS veröffentlichen.
   
• Phishing-Abwehr
  Gekaperte Mailboxen können signierte Phishing-Mails versenden.

1.c. DKIM muss mit vielen Faktoren umgehen können:

• Signatur-Domain ungleich Absender
  Die signierende Domain muss nicht mit einer der Domains des Absenders aus dem Header-From oder Envelope-From übereinstimmen, z.B. wenn man die Signierung an einen Mailprovider delegiert.
  
  Lösung: keine, wird von DMARC angegangen
   
• Mailheader dürfen unterwegs legal verändert werden
  Bestimmte fehlende Header (From, Date) sowie Received-Header dürfen von den Mailservern unterwegs hinzugefügt werden.
  
  Lösung: Header werden gesondert vom Body signiert, eine Liste der signierten Header wird der Signatur hinzugefügt.
   
• Mails werden unterwegs inhaltlich geändert
  Mailinglisten ändern gerne den Inhalt der Mails, sie fügen Footer an oder schreiben den From-Header um. Damit einher gehen Umkodierungen, Einfügen oder Entfernen von Leerzeichen, Tabulatoren oder Leerzeilen.
  
  Lösung: Der Inhalt wird mittels einer Canonicalization umgeschrieben, die Differenzen in Leerzeichen, Leerzeilen und Tabulatoren ignoriert. Weiterhin werden Mehrfachsignierungen erlaubt, d.h. der verändernde Mailserver darf danach seine eigene Signatur hinzufügen.
   
• Mehrfachsignierung
  Ein Mailserver (z.B. Mailinglisten) kann eine weitere Signatur hinzufügen, welche der Signaturen ist nun zu beachten?
  
  Lösung: Nur eine der Signaturen muss valide sein, die ungültigen werden ignoriert.
   
• Böswilliges Einfügen zusätzlicher Header (From, To, Subject)
  Angreifer versuchen durch Einfügen verschiedener Versionen derselben Header schlecht programmierte Mailprogramme der Empfänger z.B. dazu zu bringen, falsche Absenderangaben anzuzeigen.
  
  Lösung: Liste der signierten Header enthält die zu schützenden Header mehrfach.
   
• Zertifikatstausch sowie Revocation
  
  Lösung:  Zusätzlich zur Domain wird ein Selektor eingefügt, der bei den DNS-Abfragen verwendet wird. Damit kann man parallel mehrere DKIM-TXT-Records im DNS verbreiten. Die Revocation wird durch einen Record mit leerem Publickey erreicht.
   
• Behandlung von signierten versus unsignierten Mails derselben Domain
  Man kann als Absender keine DKIM-Policy festlegen. Z.B. kann man nicht deklarieren, dass ausnahmslos alle Mails signiert werden und somit unsignierte Mails als gefälscht abgewiesen werden dürfen.
  
  Lösung: DMARC. Ein früherer Versuch war ADSP, der aber von DMARC ersetzt wurde.

1.d. DKIM-DNS-Records

Der Betreiber der Domain, unter deren Namen die Mails signiert werden sollen, muss im DNS DKIM-Records veröffentlichen. Hierbei handelt es sich um TXT-Records in einem bestimmten Format. Hier folgt ein Beispiel für die Domain dfn.de und den Selektor s1:

dig +short txt s1._domainkey.dfn.de

"v=DKIM1; p="
"MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5tjEwjdy5Xynwaub38d3Lk1e8"
"7O2W0qNp69swt85//ZjXNckUDm1dMK8/Aj8DIyASgDDOHjUrBzSx7a/EchjqgN0S"
"+JFs+DPy+FQsGuNZReVaaBgB3OjqJ25R1CZwDoKK2cD3f4RNhYLctuboB14AZSLt"
"Mx6hJ0w0XhJKZ3kyrwIDAQAB"

Es muss zumindest die Version (v=) und der Publickey (p=) enthalten sein, weitere Einträge sind optional.
Weiterhin ist es nicht empfehlenswert, eine DKIM-Keylänge von mehr als 2048 Bit zu wählen, da es sonst zu Übertragungsproblemen im DNS kommen kann, siehe https://datatracker.ietf.org/doc/html/draft-ietf-dkim-base-08#section-3.3.3 .

2. DKIM-Signaturen im MailSupport

Wir können auf Wunsch alle ausgehenden Mails mit Hilfe des Amavis mit DKIM-Signaturen versehen.
Hierbei gelten folgende Rahmenbedingungen:

2.a. Rahmenbedingungen                                                                                          

• Es gibt pro Instanz nur ein RSA-Keypaar.
• Das Keypaar wird von uns erzeugt, Sie bekommen von uns eine Vorlage für ihre DNS-Records. Die Keylänge beträgt aktuell 1024 Bit.
• Die Selektoren sind frei wählbar.
• Das Einfügen einer Signatur in die Mails ist pro Absender-Domain individuell aktivierbar.
• Als Canonicalization wird relaxed/simple eingesetzt (relaxed für Header, simple für Body).
• Die Liste der zu signierenden Header entspricht dem Amavis-Default und kann nicht modifiziert werden.
• Der Signatur-Algorithmus ist stets rsa-sha256.

2.b. Amavis-Header-Liste

Es folgt die Liste der Header, die Amavis für die Signatur heranzieht:

# Nach RFC 6376

From Sender Reply-To Subject Date Message-ID To Cc
In-Reply-To References MIME-Version Content-Type Content-Transfer-Encoding
Content-ID Content-Description Resent-Date Resent-From Resent-Sender
Resent-To Resent-Cc Resent-Message-ID List-Id List-Post List-Owner
List-Subscribe List-Unsubscribe List-Help List-Archive

Von diesen werden folgende NICHT signiert, weil Mailinglisten bzw. manche Mailer-Implementierungen diese oft modifizieren:

Sender To Cc Resent-To Resent-Cc

Zusätzlich kommen nach RFC 4021, 3834, RFC 5518 und IANA registry Permanent Message Header Field Names folgende hinzu, Note that we are signing Received despite the advise in RFC 6376:

Received Precedence
Original-Message-ID Message-Context PICS-Label Sensitivity Solicitation
Content-Location Content-Features Content-Disposition Content-Language
Content-Alternative Content-Base Content-MD5 Content-Duration Content-Class
Accept-Language Auto-Submitted Archived-At VBR-Info

Some additional nonstandard header fields:

Organisation User-Agent X-Mailer

Folgende Header werden doppelt eingefügt, d.h. böswilliges Hinzufügen solcher Header durch Angreifer wird erkannt:

From Date Subject Content-Type