13. Sicherheitsüberlegungen

Jede Erweiterung der erlaubten Zeichen und Kodierungsformen in E-Mail-Adressen birgt einige Risiken. Es gab Diskussionen über sogenanntes "IDN-spoofing" oder "IDN homograph attacks". Diese Angriffe ermöglichen es einem Angreifer (oder "Phisher"), die Domäne oder URLs von Unternehmen oder anderen Entitäten zu fälschen. Dieselbe Art von Angriff ist auch auf den lokalen Teil internationalisierter E-Mail-Adressen möglich. Es sollte beachtet werden, dass der vorgeschlagene Fix, alle angezeigten Elemente in normalisierte Kleinbuchstaben zu zwingen, für Domänennamen in URLs funktioniert, aber nicht für lokale E-Mail-Teile, da diese Groß-/Kleinschreibung unterscheiden.

Da E-Mail-Adressen oft von Visitenkarten und Notizen auf Papier übertragen werden, unterliegen sie Problemen, die sich aus verwechselbaren Zeichen ergeben (siehe [RFC4690]). Diese Probleme sind etwas geringer, wenn die mit dem Postfach verbundene Domäne eindeutig ist und eine relativ kleine Anzahl von Postfächern unterstützt, deren Namen lokalen Systemkonventionen folgen. Sie sind größer bei sehr großen Mailsystemen, in denen Benutzer ihre eigenen Adressen frei wählen können.

Die Internationalisierung von E-Mail-Adressen und Nachrichtenheadern darf das Internet nicht weniger sicher machen, als es ohne die erforderlichen Erweiterungen ist. Die in dieser Spezifikationsgruppe dokumentierten Anforderungen und Mechanismen werfen im Allgemeinen keine neuen Sicherheitsprobleme auf.

Sie erfordern jedoch eine Überprüfung von Problemen im Zusammenhang mit verwechselbaren Zeichen -- ein Thema, das andernorts gründlich untersucht wird (siehe z. B. RFC 4690 [RFC4690]) -- und möglicherweise einige Probleme mit der UTF-8-Normalisierung, diskutiert in RFC 3629 [RFC3629], und anderen Transformationen. Normalisierung und andere Probleme im Zusammenhang mit Transformationen und Standardformen sind ebenfalls Teil des Themas von andernorts beschriebener Arbeit [RFC5198] [RFC5893] [RFC6055].

Einige Probleme, die speziell mit internationalisierten Adressen und Nachrichtenheadern zusammenhängen, werden in den anderen Dokumenten dieser Gruppe ausführlicher diskutiert. Insbesondere sollte jedoch Vorsicht walten, dass kein "Downgrading"-Mechanismus oder die Verwendung herabgestufter Adressen unangemessen authentifizierte Bindungen zwischen den internationalisierten und den ASCII-Adressen annimmt. Dieses potenzielle Problem kann etwas abgemildert werden, indem die Erwartung durchgesetzt wird, dass die meisten oder alle solchen Transformationen vor der endgültigen Zustellung durch Systeme durchgeführt werden, von denen angenommen wird, dass sie unter der administrativen Kontrolle des sendenden Benutzers stehen (im Gegensatz zu einer Durchführung während der Übertragung durch Entitäten, die nicht unter der administrativen Kontrolle des sendenden Benutzers stehen).

Die neuen UTF-8-Header- und Nachrichtenformate könnten auch ein weiteres bekanntes Problem aufwerfen oder verschärfen. Wenn das Modell neue Formen einer "ungültigen" oder "fehlerhaften" Nachricht erzeugt, dann wird ein neuer E-Mail-Angriff geschaffen: In dem Bestreben, robust zu sein, werden einige oder die meisten Agenten solche Nachrichten akzeptieren und sie so interpretieren, als wären sie wohlgeformt. Wenn ein Filter eine solche Nachricht anders interpretiert als der vom Empfänger verwendete MUA, dann kann es möglich sein, eine Nachricht zu erstellen, die unter der Interpretation des Filters akzeptabel erscheint, aber unter der ihr von diesem MUA gegebenen Interpretation abgelehnt werden sollte. Solche Angriffe sind bereits für bestehende Nachrichten und Kodierungsschichten aufgetreten, z. B. ungültige MIME-Syntax, ungültiges HTML-Markup und ungültige Kodierung bestimmter Bildtypen.

Darüber hinaus werden E-Mail-Adressen in vielen anderen Kontexten als dem Senden von Mail verwendet, etwa als Identifikatoren unter verschiedenen Umständen (siehe Abschnitt 11.2). Jeder dieser Kontexte muss wiederum bewertet werden, um festzustellen, ob die Verwendung von non-ASCII-Formen angemessen ist und welche besonderen Probleme sie aufwerfen.

Diese Arbeit wird eindeutig alle Systeme oder Mechanismen betreffen, die von digitalen Signaturen oder einem ähnlichen Integritätsschutz für E-Mail-Nachrichtenheader abhängen (siehe auch die Diskussion in Abschnitt 11.3). Viele konventionelle Verwendungen von PGP und S/MIME sind nicht betroffen, da sie zum Signieren von Body-Teilen, aber nicht von Nachrichtenheadern verwendet werden. Andererseits wird die in Entwicklung befindliche Arbeit an DomainKeys Identified Mail (DKIM) [RFC5863] schließlich diese Arbeit berücksichtigen müssen, und umgekehrt: Während diese Spezifikation die von DKIM und anderen Mechanismen für signierte Header aufgeworfenen Probleme nicht behandelt oder löst, werden die Probleme schließlich koordiniert und gelöst werden müssen, wenn die beiden Protokollgruppen koexistieren sollen. Darüber hinaus müssen, soweit E-Mail-Adressen in PKI-Zertifikaten (Public Key Infrastructure) [RFC5280] erscheinen, Standards, die solche Zertifikate behandeln, aufgerüstet werden, um diese internationalisierten Adressen zu behandeln. Diese Upgrades müssen Fragen des Spoofings durch Look-alikes der Adressen selbst behandeln.