DKIM und Post-Quanten-Kryptografie: Ruhe bewahren und die Grundlagen fixen

Post-Quanten-Kryptografie ist ein reales Thema, aber nicht jeder Teil des E-Mail-Sicherheits-Stacks ist auf die gleiche Weise gefährdet. Viele Kommentare fassen das gesamte Thema unter „store now, decrypt later“ zusammen: Angreifer sammeln heute verschlüsselten Datenverkehr, warten auf einen kryptografisch relevanten Quantencomputer und entschlüsseln ihn später. Das ist eine ernsthafte Sorge bei verschlüsselten Inhalten (PGP, S/MIME, TLS, VPNs, Backups, Archive), aber es ist nicht das richtige Modell für DKIM.

DKIM ist kein Vertraulichkeitsmechanismus. Es verschlüsselt die Nachricht nicht. Es ist ein Authentifizierungssignal, das bewertet wird, wenn ein Empfänger die E-Mail verarbeitet. Der Empfänger prüft den DKIM-Signature-Header gegen einen öffentlichen Schlüssel, der unter einem Selector in DNS veröffentlicht ist, und dieses Ergebnis fließt sowohl in lokale Richtlinien als auch in DMARC ein. Die Post-Quanten-Sorge bei DKIM besteht nicht darin, dass heute signierte E-Mails später entschlüsselt werden. Die Sorge betrifft künftige Fälschungen. Sollten RSA-basierte Signaturen knackbar werden, könnte ein Angreifer scheinbar gültige DKIM-Signaturen für gefälschte E-Mails erstellen – es sei denn, das Ökosystem ist bereits auf quantenresistente Signaturverfahren umgestiegen.

Das ist wichtig, aber die Dringlichkeit ist anders. NIST hat Post-Quanten-Algorithmen für digitale Signaturen wie ML-DSA standardisiert, und Standardisierungsgremien diskutieren Algorithmus-Agilität und zukünftige Erweiterbarkeit bei der E-Mail-Authentifizierung. Es gibt jedoch noch kein breit eingesetztes, interoperables Produktionsprofil für Post-Quanten-DKIM, das man vorschnell in seine Domains einbauen sollte.

Es gibt auch eine praktische Umsetzungsrealität. Eine hybride DKIM-Migration könnte letztlich bedeuten, klassisches und Post-Quanten-Signaturmaterial parallel zu betreiben. Das klingt in der Theorie sinnvoll, aber bei DKIM liegen Signaturen in Nachrichten-Headern, während DNS selector-gebundene öffentliche Schlüssel veröffentlicht. Die eigentliche Arbeit besteht nicht nur darin, „Post-Quanten-Signaturen in DNS zu hinterlegen“. Es geht darum, sich auf Algorithmen, Schlüsselformate, Selectors, DNS-Record-Handling, Verifier-Verhalten, Fehlersemantik und die Behandlung der DMARC-Alignment zu einigen.

DKIM ist in einer Hinsicht einfacher als Verschlüsselung, weil es Nachrichteninhalte nicht über die Zeit schützen muss, aber es ist auch schwer, es im Internet-Maßstab zu ändern. DNS muss die öffentlichen Schlüssel tragen, und der DNS-Transport hat praktische Größen- und Zuverlässigkeitsgrenzen, die noch wichtiger werden, wenn Post-Quanten-Public-Keys deutlich größer sind als heutige RSA-Schlüssel. Empfänger verarbeiten riesige Mengen an E-Mails und bewerten Signaturen fortlaufend, sodass auch die Verifier-Performance eine Rolle spielt. Das bedeutet, die Branche muss nicht nur die kryptografische Designfrage lösen, sondern auch technische Fragen zu Schlüsselgröße in DNS, Signaturgröße in Headern, Lookup-Verhalten, Caching, Durchsatz und Abwärtskompatibilität.

Im Moment liegt der richtige Fokus darauf, die Grundlagen der E-Mail-Authentifizierung richtig umzusetzen. Das bedeutet: starke DKIM-Schlüssel, wo unterstützt, diszipliniertes Selector-Management, authentifizierte und ausgerichtete Versandquellen, DMARC über das reine Monitoring hinaus in Richtung Enforcement bewegen sowie kontinuierliche Sichtbarkeit auf Fehler und unautorisierte Absender. Genau hier hilft OnDMARC: Verwaltung von SPF, DKIM, DMARC, BIMI und MTA-STS, Identifizierung von Fehlkonfigurationen und die Teams auf einem klaren Kurs zum Enforcement halten, statt E-Mail-Authentifizierung als einmaliges DNS-Projekt zu behandeln.

Die dringendere Post-Quanten-Arbeit liegt woanders. Erfassen Sie, wo Sie Public-Key-Kryptografie einsetzen, besonders dort, wo Vertraulichkeit eine lange Haltbarkeit hat. TLS-Zertifikate, VPNs, verschlüsselte Backups, Langzeitarchive, Code-Signing, S/MIME, private PKI und Maschinenidentitäten verdienen alle Aufmerksamkeit, bevor spekulative DKIM-Änderungen angegangen werden. Diese Arbeit beginnt mit Sichtbarkeit: welche Zertifikate existieren, wo sie eingesetzt werden, welche Algorithmen und Schlüsselaustauschverfahren sie verwenden, wer sie besitzt und wie schnell sie rotiert werden können.

Red Sift Certificates kümmert sich um diese Seite. Es umfasst die Erkennung und Überwachung öffentlicher kryptografischer Assets über Domains, Subdomains, Zertifikate und exponierte Dienste hinweg, einschließlich TLS-Konfiguration und Zertifikatsdetails. Das gibt Teams einen praktischen Ausgangspunkt für Post-Quanten-Bereitschaft. Bauen Sie das Inventar auf, verstehen Sie die Exposition, priorisieren Sie langfristige Vertraulichkeitsrisiken und verbessern Sie die kryptografische Agilität, bevor eine erzwungene Migration ansteht.

Unsere Empfehlung? Ruhe bewahren und weitermachen. Nutzen Sie OnDMARC, um DKIM und DMARC mit den heutigen Standards zu härten. Fragen Sie ESPs und Mail-Anbieter nach ihrer Roadmap zur DKIM-Algorithmus-Agilität und zukünftiger Post-Quanten-Unterstützung. Kunden sollten außerdem die IETF DKIM2-Arbeit im Auge behalten, die Teil der breiteren Entwicklung hin zu DKIM-Algorithmus-Agilität und stärkerer Nachrichtenverarbeitungssemantik ist – dabei sollte man sie jedoch als laufende Standardisierungsarbeit betrachten und nicht als heute einsetzbare Post-Quanten-Kontrolle. Nutzen Sie Red Sift Certificates, um schon jetzt mit der umfassenderen kryptografischen Bestandsaufnahme und Zertifikats-Bereitschaftsarbeit zu beginnen.