13. Considerazioni sulla sicurezza

Qualsiasi ampliamento dei caratteri e delle forme di codifica consentiti negli indirizzi email comporta alcuni rischi. Vi sono state discussioni sul cosiddetto "IDN-spoofing" o "attacco omografo IDN". Questi attacchi consentono a un aggressore (o "phisher") di falsificare il dominio o gli URL di aziende o altre entità. Lo stesso tipo di attacco è possibile anche sulla parte locale degli indirizzi email internazionalizzati. Va notato che la correzione proposta, che consiste nel forzare tutti gli elementi visualizzati in minuscolo normalizzato, funziona per i nomi di dominio negli URL, ma non per le parti locali degli indirizzi email, poiché queste distinguono tra maiuscole e minuscole.

Poiché gli indirizzi email sono spesso trascritti da biglietti da visita e appunti su carta, essi sono soggetti a problemi derivanti da caratteri confondibili (si veda [RFC4690]). Questi problemi sono in qualche misura ridotti se il dominio associato alla casella postale è inequivocabile e supporta un numero relativamente piccolo di caselle postali i cui nomi seguono le convenzioni del sistema locale. Essi aumentano con sistemi di posta molto grandi in cui gli utenti possono scegliere liberamente i propri indirizzi.

L'internazionalizzazione degli indirizzi email e delle intestazioni dei messaggi non deve rendere Internet meno sicura di quanto sia senza le estensioni richieste. I requisiti e i meccanismi documentati in questo insieme di specifiche non sollevano, in generale, alcun nuovo problema di sicurezza.

Essi richiedono però una revisione dei problemi associati ai caratteri confondibili — argomento che viene esplorato a fondo altrove (si veda, ad es., l'RFC 4690 [RFC4690]) — e, potenzialmente, di alcuni problemi con la normalizzazione UTF-8, discussi nell'RFC 3629 [RFC3629], e altre trasformazioni. La normalizzazione e altri problemi associati alle trasformazioni e alle forme standard fanno anche parte dell'oggetto del lavoro descritto altrove [RFC5198] [RFC5893] [RFC6055].

Alcuni problemi specificamente legati agli indirizzi internazionalizzati e alle intestazioni dei messaggi sono discussi in maggiore dettaglio negli altri documenti di questo insieme. In particolare, tuttavia, occorre prestare attenzione affinché qualsiasi meccanismo di "downgrading", o l'uso di indirizzi sottoposti a downgrading, non presuma in modo inappropriato associazioni autenticate tra gli indirizzi internazionalizzati e quelli ASCII. Questo potenziale problema può essere in qualche misura mitigato imponendo l'aspettativa che la maggior parte o tutte tali trasformazioni siano eseguite prima della consegna finale da sistemi che si presume siano sotto il controllo amministrativo dell'utente mittente (anziché essere eseguite in transito da entità che non sono sotto il controllo amministrativo dell'utente mittente).

I nuovi formati di intestazione e di messaggio UTF-8 potrebbero anche sollevare, o aggravare, un altro problema noto. Se il modello crea nuove forme di un messaggio "non valido" o "malformato", allora si crea un nuovo attacco email: nel tentativo di essere robusti, alcuni o la maggior parte degli agenti accetteranno tali messaggi e li interpreteranno come se fossero ben formati. Se un filtro interpreta un tale messaggio in modo diverso dal MUA usato dal destinatario, allora può essere possibile creare un messaggio che appare accettabile secondo l'interpretazione del filtro ma che dovrebbe essere rifiutato secondo l'interpretazione data dal MUA. Tali attacchi si sono già verificati per messaggi e livelli di codifica esistenti, ad es. sintassi MIME non valida, markup HTML non valido e codifica non valida di particolari tipi di immagine.

Inoltre, gli indirizzi email sono usati in molti contesti diversi dall'invio di posta, come per gli identificatori in varie circostanze (si veda la Sezione 11.2). Ciascuno di tali contesti dovrà essere valutato, a sua volta, per determinare se l'uso di forme non-ASCII sia appropriato e quali problemi particolari sollevi.

Questo lavoro influenzerà chiaramente qualsiasi sistema o meccanismo dipendente da firme digitali o da una simile protezione dell'integrità per le intestazioni dei messaggi email (si veda anche la discussione nella Sezione 11.3). Molti usi convenzionali di PGP e S/MIME non sono interessati, poiché sono usati per firmare parti di corpo ma non intestazioni di messaggio. D'altro canto, il lavoro in sviluppo su DomainKeys Identified Mail (DKIM) [RFC5863] dovrà prima o poi considerare questo lavoro, e viceversa: sebbene questa specifica non affronti né risolva i problemi sollevati da DKIM e da altri meccanismi di intestazione firmata, i problemi dovranno essere coordinati e risolti prima o poi, se i due insiemi di protocolli devono coesistere. Inoltre, nella misura in cui gli indirizzi email compaiono nei certificati PKI (Public Key Infrastructure) [RFC5280], gli standard che disciplinano tali certificati dovranno essere aggiornati per affrontare questi indirizzi internazionalizzati. Tali aggiornamenti dovranno affrontare le questioni di falsificazione tramite sosia degli indirizzi stessi.