DKIM2 ist die Weiterentwicklung von DKIM, welches 2007 von der IETF mit RFC 4871 eingef\u00fchrt und 2011 mit RFC 6376 zuletzt aktualisiert wurde.<\/p>\n
Inhalt<\/strong><\/p>\n DKIM steht f\u00fcr \u201eDomainKeys Identified Mail\u201c und ist eine kryptografische Signatur zur Sicherstellung der Integrit\u00e4t einer E-Mail w\u00e4hrend der \u00dcbertragung.<\/p>\n Beim Versand erzeugt der Absender mithilfe des privaten Schl\u00fcssels, Private Key, eine kryptografische Signatur f\u00fcr die E-Mail. Der \u00f6ffentliche Schl\u00fcssel, Public Key, wird als TXT-Eintrag im DNS einer Domain hinterlegt. Damit kann der Empf\u00e4nger beim Eingang der E-Mail die Integrit\u00e4t pr\u00fcfen und sicherstellen, dass die E-Mail w\u00e4hrend der \u00dcbertragung nicht manipuliert wurde. Beispielsweise k\u00f6nnen dadurch \u00c4nderungen wie das nachtr\u00e4gliche Einf\u00fcgen von Phishing-Links erkannt werden.<\/p>\n DKIM allein reicht als Authentifizierungsmechanismus dennoch nicht aus, denn auch Spammer k\u00f6nnen diese Methode fehlerfrei anwenden. DKIM best\u00e4tigt zun\u00e4chst lediglich, dass eine E-Mail von einer Domain signiert wurde und w\u00e4hrend der \u00dcbertragung unver\u00e4ndert geblieben ist. Ob die signierende Domain tats\u00e4chlich mit dem sichtbaren Absender \u00fcbereinstimmt und vertrauensw\u00fcrdig ist, wird erst durch zus\u00e4tzliche Mechanismen wie DMARC bewertet.<\/p>\n Im Verlauf der letzten Jahre seit 2007 wurden verschiedene Missbrauchsm\u00f6glichkeiten und Schw\u00e4chen sichtbar \u2013 DKIM Replay oder Probleme durch Mailinglisten und Weiterleitungen, um nur einige zu nennen.<\/p>\n Bei der direkten \u00dcbertragung einer E-Mail zwischen einem Versender und einem Empf\u00e4nger erf\u00fcllt DKIM seinen Zweck. Bei fehlerhafter Integrit\u00e4t kann von einer missbr\u00e4uchlichen Manipulation auf dem \u00dcbertragungsweg ausgegangen werden.<\/p>\n Bei Weiterleitungen, also mindestens drei beteiligten Stationen, die legitim und eine zentrale Funktion von E-Mail sind, kommt es jedoch sehr h\u00e4ufig zum ungewollten Bruch von DKIM. Die Zwischenstelle nimmt kleinere \u00c4nderungen vor, die gewollt sind, aber die Integrit\u00e4t der urspr\u00fcnglichen Nachricht ver\u00e4ndern. Beim Weitersenden der E-Mail an den finalen Empf\u00e4nger kommt es dann bei der Validierung der DKIM-Signatur mit dem Public Key zum Fehler.<\/p>\n In einer l\u00e4ngeren Kette von Absendern und Empf\u00e4ngern f\u00fchrt dies zu Unsicherheiten, weil man vielleicht eine Zwischenstation nicht kennt und nicht validieren kann, ob die zwischenzeitlich vorgenommenen \u00c4nderungen valide waren und genau welche dies waren.<\/p>\n Wie bekommt man es nun aber hin, eine E-Mail, welche zwischenzeitlich noch mehrfach weitergeleitet und gegebenenfalls bearbeitet wird, beim endg\u00fcltigen Empf\u00e4nger integer und sicher empfangen zu k\u00f6nnen und die Vorteile von DKIM weiterhin zu nutzen?<\/p>\n Genau da setzt DKIM2 als Weiterentwicklung an \u2013 notwendige Neuerungen auf altbew\u00e4hrten Mechanismen, um den Implementierungsaufwand zu verringern.<\/p>\n Beim Setup im DNS und dem Grundprinzip zur Funktionsweise von DKIM2 \u00e4ndert sich nichts. Es wird weiterhin mit einem Schl\u00fcsselpaar gearbeitet und das bestehende Setup kann weiter genutzt werden. Somit m\u00fcssen keine \u00c4nderungen am DNS vorgenommen werden.<\/p>\n DKIM2 versucht also die notwendigen \u00c4nderungen so gering wie m\u00f6glich zu halten, aber dennoch durch kleine Anpassungen die Herausforderungen zu l\u00f6sen, die man zwischenzeitlich mit Standards wie ARC oder DMARC versuchte zu l\u00f6sen.<\/p>\n Beim Signaturprozess von DKIM2 bietet es sich an, von RSA auf ML-DSA umzustellen.<\/p>\n Die anwachsende Leistungsf\u00e4higkeit von Computern und Servern erm\u00f6glicht es, bew\u00e4hrte Signaturalgorithmen zu entschl\u00fcsseln. Um dies zu verhindern, w\u00e4re eine Umstellung auf weiterentwickelte Algorithmen sinnvoll.<\/p>\n Allerdings muss man auch sagen, dass es innerhalb des \u00d6kosystems zu gro\u00dfen Kompatibilit\u00e4tsproblemen kommen k\u00f6nnte.<\/p>\n N\u00e4heres dazu gibt es in RFC 9882, das die Verwendung von ML-DSA in der Cryptographic Message Syntax beschreibt.<\/p>\n DKIM2 besteht zuk\u00fcnftig aus zwei E-Mail-Headern:<\/p>\n Der Message-Instance Header dokumentiert und liefert die Details \u00fcber die Ver\u00e4nderungen der E-Mail auf ihrem Weg durch mehrere Empfangs- und Absenderstationen.<\/p>\n Kernbestandteile des Message-Instance Headers sind die Hashes, welche \u00fcber die Header, header-hash, und den Body, body-hash, gebildet werden, und das Recipe.<\/p>\n Das Recipe folgt der JSON-Syntax und legt mit eigenen Tags die eindeutige Interpretation der Ver\u00e4nderungen und deren Umgang damit fest. Das Recipe ist im \u201er=\u201c-Tag hinterlegt und im E-Mail-Header in Base64 kodiert.<\/p>\n Dies ist die eigentliche kryptografische Signatur, die, wie eingangs schon erw\u00e4hnt, mit dem bekannten RSA-Algorithmus erstellt wird.<\/p>\n Alle DKIM2-Signaturen sind durch entsprechende Sequenznummerierungen, \u201ci=#\u201d, nacheinander aufsteigend erkennbar.<\/p>\n Hier ein einfaches Beispiel zur Veranschaulichung:<\/p>\n Stimmen alle Hashes \u00fcberein und sind beide Signaturen g\u00fcltig, gilt die E-Mail als integer, da s\u00e4mtliche \u00c4nderungen auf dem Weg nachvollziehbar und jeweils durch eine eigene Signatur abgesichert sind.<\/p>\n Diese Kette l\u00e4sst sich theoretisch unendlich fortsetzen. Jeder Empf\u00e4nger kann \u00c4nderungen und Signaturen des direkten Vorg\u00e4ngers sowie alle vorherigen Signaturen nachvollziehen, \u00fcberpr\u00fcfen und validieren.<\/p>\n Zusammengefasst werden nicht nur \u00c4nderungen an einer E-Mail vorgenommen und neu signiert, sondern es wird transparent gemacht, was die \u00c4nderungen beinhalteten. Kein R\u00e4tselraten auf Seiten des Empf\u00e4ngers, sondern R\u00fcckversicherung durch eindeutige Nachverfolgbarkeit und mithilfe individueller kryptografischer Signaturen.<\/p>\n F\u00fcr jeden Empf\u00e4nger entsteht eine l\u00fcckenlose Nachweiskette, Chain of Custody. Wirft die Validierung an irgendeiner Stelle Fragen auf, muss die E-Mail abgelehnt werden.<\/p>\n Mit dem Recipe und den dokumentierten \u00c4nderungen entsteht eine indirekte Kommunikation zwischen Sender und Empf\u00e4nger und schafft Vertrauen zu jeder Zeit und an jeder Stelle in der Kette der Beteiligten.<\/p>\n Es werden dar\u00fcber hinaus auch die Ans\u00e4tze von ARC, siehe auch RFC 8617, \u00fcbernommen. Mit der Authenticated Received Chain hat man bereits versucht, in einer Kette von Empf\u00e4ngern die Vertrauensw\u00fcrdigkeit von einer Stelle zur n\u00e4chsten zu \u00fcbertragen. Dies setzte aber voraus, dass man seinem Vorg\u00e4nger vertraut, dass er wiederum seinem Vorg\u00e4nger vertraut. Empf\u00e4nger 3 einer Kette kann also bei ARC nicht direkt die Vertrauensw\u00fcrdigkeit von Versender 1 pr\u00fcfen.<\/p>\n Bei DKIM2 verh\u00e4lt es sich etwas anders. Wenn ein Empf\u00e4nger die DKIM2-Signaturen nicht validieren kann und die \u00c4nderungen aller Zwischenstellen nicht nachvollziehen kann, hei\u00dft dies letztlich: \u201eLehne diese E-Mail ab!\u201c<\/p>\n Aktuell ist DKIM2 noch kein offizielles RFC der IETF, sondern ein Entwurf, an dem intensiv gearbeitet wird und in dem es noch stetig Anpassungen geben kann. Dennoch ist es in meinen Augen eine der schnellsten Entwicklungen eines neuen Sicherheitsstandards f\u00fcr E-Mail, die ich in den letzten 20 Jahren beobachtet habe.<\/p>\n Seitens der Mailbox Provider nimmt die Implementierung sehr schnell Fahrt auf. Erste ESPs berichten von erfolgreichen Versendungen und Empf\u00e4ngen von E-Mails mit DKIM2.<\/p>\n DKIM2 ist endlich eine erreichte Konsolidierung von Anforderungen, siehe DMARC und ARC, und wird langj\u00e4hrige Sicherheitsprobleme l\u00f6sen.<\/p>\n Aus meiner Sicht wird DKIM2 einen nachhaltigen Einfluss auf die Reputation von Versendern haben.<\/p>\n Versender, die schnell auf DKIM2 setzen, demonstrieren damit automatisch Transparenz und das grundlegende Verst\u00e4ndnis f\u00fcr die sichtbar gewordenen Probleme der letzten 15 bis 20 Jahre.<\/p>\n","protected":false},"author":4,"featured_media":10086,"template":"","categories":[],"tags":[77,254],"yoast_head":"\n\n
1. Einleitung<\/h2>\n
2. Schw\u00e4chen von DKIM<\/h2>\n
3. Zielproblem und Motivation<\/h2>\n
4. Exkurs: M\u00f6gliche Optimierung des Signaturalgorithmus<\/h2>\n
5. DKIM2 kommt mit zwei Headern<\/h2>\n
\n
Message-Instance<\/h3>\n
DKIM2-Signatur<\/h3>\n
Message-Instance: v=1;\r\nm=1;\r\nh=sha256:aG9UNGVhZGVySGFzaFYx==:Ym9keUhhc2hWMQ==\r\n\r\nMessage-Instance: v=2;\r\nm=2;\r\nr=eyJoIjp7InN1YmplY3QiOlt7ImQiOlsiUHJvamVrdHN0YXR1cyBVcGR\r\nhdGUiXX1dfSwiYiI6W3siYyI6WzEsNl19XX0=;\r\nh=sha256:bmV3SGVhZGVySGFzaFYy==:bmV3Qm9keUhhc2hWMg==\r\n\r\nDKIM2-Signature: i=1; d=original.domain.example; t=1780329600;\r\nmf=seb@original.domain.example; rt=liste@mailingliste.example;\r\ns=sel1:ed25519-sha256:MEUCIQD3xK...FAKE...==\r\n\r\nDKIM2-Signature: i=2; d=mailingliste.example; t=1780329650;\r\nmf=bounce@mailingliste.example;\r\nrt=bob@mailboxprovider.example;\r\nf=exploded;\r\ns=sel-liste:ed25519-sha256:AnotherFAKEsigValue...==<\/code><\/pre>\n6. Prozessablauf<\/h2>\n
\n
Message-Instance<\/code> Header mit seinem Hash hinzu und signiert sie mit DKIM. Zu diesem Zeitpunkt gibt es noch kein Recipe, denn es handelt sich um die originale Version.\n <\/li>\n\n
\n
Message-Instance<\/code> sowie der zugeh\u00f6rigen DKIM2-Signatur<\/li>\nMessage-Instance<\/code> und Validierung der ersten DKIM2-Signatur<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n\n
\n
7. Nutzen und Effekte<\/h2>\n
8. Einordnung und Vergleich<\/h2>\n
9. Fazit<\/h2>\n