13. Considérations de sécurité

Toute expansion de caractères autorisés et de formulaires de codage dans les adresses e-mail soulève certains risques. Il y a eu des discussions sur ce que l'on appelle " IDN-spoofing " ou " IDN homograph attacks ". Ces attaques permettent à un attaquant (ou " phisher ") de falsifier le domaine ou les URL des entreprises ou d'autres entités. Le même type d'attaque est également possible sur la partie locale des adresses e-mail internationalizées. Il convient de noter que la correction proposée implique de forcer tous les éléments affichés dans des petits caractères normalisés fonctionne pour les noms de domaine dans les URL, mais pas pour les parties locales de l'e-mail puisque ces derniers sont sensibles aux cas.

Comme les adresses e-mail sont souvent transcrites à partir de cartes de visite et de notes sur papier, elles sont soumises à des problèmes résultant de caractères confus (voir [RFC4690]). Ces problèmes sont quelque peu réduits si le domaine associé à la boîte aux lettres est sans ambiguïté et prend en charge un nombre relativement faible de boîtes aux lettres dont les noms suivent les conventions du système local.

L'internationalisation des adresses e-mail et des en-têtes de messages ne doit pas laisser Internet moins sûr qu'il ne l'est sans les extensions requises.

Ils nécessitent un examen des problèmes associés aux caractères confus - un sujet qui est en cours d'exploration en profondeur ailleurs (voir, par exemple, RFC 4690 [RFC4690]) - et, potentiellement, certains problèmes avec la normalisation UTF-8, discutés dans RFC 3629 [RFC3629], et d'autres transformations. La normalisation et d'autres problèmes associés aux transformations et aux formes standard font également partie du sujet du travail décrit ailleurs [RFC5198] [RFC5893] [RFC6055].

Certains problèmes spécifiques liés aux adresses internationalizées et aux en-têtes de message sont discutés plus en détail dans les autres documents de ce jeu. Cependant, il convient de faire attention à ce que tout mécanisme de " dégradation " ou d'utilisation d'adresses dégradées n'assume pas inappropriément des liaisons authentifiées entre les adresses internationalizées et ASCII. Ce problème potentiel peut être atténué en attendant que la plupart ou toutes ces transformations soient effectuées avant la livraison finale par des systèmes qui sont présumés être sous le contrôle administratif de l'utilisateur expéditeur (par opposition à être effectuées en transit par des entités qui ne sont pas sous le contrôle administratif de l'utilisateur expéditeur).

Le nouveau format d'en-tête et de message UTF-8 pourrait également soulever ou aggraver un autre problème connu. Si le modèle crée de nouvelles formes d'un message "invalide" ou "malformé", alors une nouvelle attaque par e-mail est créée: dans un effort pour être robuste, certains ou la plupart des agents accepteront ces messages et les interpréteront comme s'ils étaient bien formés. Si un filtre interprète un tel message différemment de la MUA utilisée par le destinataire, il peut être possible de créer un message qui semble acceptable selon l'interprétation du filtre, mais qui devrait être rejeté selon l'interprétation qui lui est donnée par ce MUA. De tels attaques ont déjà eu lieu pour les messages existants et les couches de codage, par exemple, la syntaxe MIME invalide, le marquage HTML invalide et le codage invalide de certains types d'images.

En outre, les adresses e-mail sont utilisées dans de nombreux contextes autres que l'envoi de courrier, comme pour les identifiants dans diverses circonstances (voir rubrique 11.2). Chacun de ces contextes devra être évalué, à son tour, pour déterminer si l'utilisation de formulaires non ASCII est appropriée et quelles questions particulières ils soulèvent.

Ce travail affectera clairement tous les systèmes ou mécanismes qui dépendent de signatures numériques ou de protection d'intégrité similaire pour les en-têtes de messages de messagerie (voir aussi la discussion dans la section 11.3). De nombreuses utilisations conventionnelles de PGP et S/MIME ne sont pas affectées car elles sont utilisées pour signer des parties du corps mais pas des en-têtes de message. D'autre part, le travail en cours de développement sur DomainKeys Identified Mail (DKIM) [RFC5863] devra éventuellement prendre en compte ce travail, et vice versa: alors que cette spécification ne traite pas ou ne résolve pas les problèmes soulevés par DKIM et d'autres mécanismes de en-tête signés, les problèmes devront être coordonnés et résolus éventuellement si les deux ensembles de protocoles doivent coexister. En outre, dans la mesure où les adresses e-mail figurent dans les certificats PKI (Infrastructure de clés publiques) [RFC5280], les normes qui traitent de tels certificats devront être mises à jour pour répondre à ces adresses internationalement mises à jour.