1. Introduzione (Introduction)
1.1. Contesto e motivazione (Background and Motivation)
Le applicazioni che comunicano su Internet spesso devono prevenire l'intercettazione, la manomissione o la falsificazione delle loro comunicazioni. Il protocollo Transport Layer Security (TLS) fornisce questo tipo di sicurezza delle comunicazioni su Internet, utilizzando la crittografia del canale.
Le proprietà di sicurezza dei sistemi di crittografia dipendono fortemente dalle chiavi che utilizzano. Se le chiavi segrete vengono rivelate, o se le chiavi pubbliche possono essere sostituite con chiavi false (cioè una chiave che non corrisponde all'entità identificata nel certificato), questi sistemi forniscono poca o nessuna sicurezza.
TLS utilizza i certificati per legare chiavi e nomi. Un certificato combina una chiave pubblicata con altre informazioni come il nome del servizio che utilizza la chiave, e questa combinazione è firmata digitalmente da un'altra chiave. Avere una chiave in un certificato è utile solo se si ha fiducia nell'altra chiave che ha firmato il certificato. Se quell'altra chiave è stata essa stessa rivelata o sostituita, allora la sua firma non ha valore nel dimostrare nulla sulla prima chiave.
Su Internet, questo problema è stato risolto per anni da entità chiamate "Autorità di Certificazione" (CA). Le CA proteggono vigorosamente la loro chiave segreta, fornendo al contempo la loro chiave pubblica ai fornitori di software che costruiscono client TLS. Quindi firmano i certificati e li forniscono ai server TLS. Il software client TLS utilizza un insieme di queste chiavi CA come "ancore di fiducia" per convalidare le firme sui certificati che il client riceve dai server TLS. Il software client in genere consente a qualsiasi CA di firmare utilmente qualsiasi altro certificato.
Il modello di CA pubblica su cui TLS ha fatto affidamento è fondamentalmente vulnerabile perché consente a una qualsiasi di queste CA di emettere un certificato per qualsiasi nome di dominio. Una singola CA fidata che tradisce la sua fiducia, sia volontariamente sia fornendo una protezione meno che vigorosa dei suoi segreti e capacità, può minare la sicurezza offerta da qualsiasi certificato impiegato con TLS. Questo problema sorge perché una CA compromessa può emettere un certificato sostitutivo che contiene una chiave falsa. Le recenti esperienze con compromissioni di CA o dei loro partner fidati hanno portato a problemi di sicurezza molto gravi, come i governi di più paesi che tentano di intercettare e/o sovvertire importanti siti web protetti da TLS fidati da milioni di utenti.
Le estensioni di sicurezza DNS (DNSSEC) forniscono un modello simile che coinvolge chiavi fidate che firmano le informazioni per chiavi non fidate. Tuttavia, DNSSEC fornisce tre miglioramenti significativi. Le chiavi sono legate ai nomi nel Domain Name System (DNS), piuttosto che a stringhe identificative arbitrarie; questo è più conveniente per i protocolli Internet. Le chiavi firmate per qualsiasi dominio sono accessibili online tramite una query diretta utilizzando il protocollo DNSSEC standard, quindi non c'è alcun problema nella distribuzione delle chiavi firmate. Più significativamente, le chiavi associate a un nome di dominio possono essere firmate solo da una chiave associata al genitore di quel nome di dominio; ad esempio, le chiavi per "example.com" possono essere firmate solo dalle chiavi per "com", e le chiavi per "com" possono essere firmate solo dalla radice DNS. Questo impedisce a un firmatario non affidabile di compromettere le chiavi di chiunque tranne quelle nei propri sottodomini. Come TLS, DNSSEC si basa su chiavi pubbliche integrate nel software client DNSSEC, ma queste chiavi provengono solo da un singolo dominio radice piuttosto che da una molteplicità di CA.
L'autenticazione basata su DNS di entità nominate (DANE) offre l'opzione di utilizzare l'infrastruttura DNSSEC per memorizzare e firmare chiavi e certificati utilizzati da TLS. DANE è concepito come una base preferibile per legare le chiavi pubbliche ai nomi DNS, perché le entità che garantiscono il legame dei dati delle chiavi pubbliche ai nomi DNS sono le stesse entità responsabili della gestione dei nomi DNS in questione. Sebbene il sistema risultante abbia ancora vulnerabilità di sicurezza residue, limita l'ambito delle asserzioni che possono essere fatte da qualsiasi entità, coerentemente con l'ambito di denominazione imposto dalla gerarchia DNS. Di conseguenza, DANE incarna il "principio del privilegio minimo" di sicurezza che manca nell'attuale modello di CA pubblica.
1.2. Protezione dell'associazione di un nome di dominio con il certificato di un server (Securing the Association of a Domain Name with a Server's Certificate)
Un client TLS inizia una connessione scambiando messaggi con un server TLS. Per molti protocolli applicativi, cerca il nome del server utilizzando il DNS per ottenere un indirizzo Internet Protocol (IP) associato al nome. Quindi inizia una connessione a una porta particolare a quell'indirizzo e invia lì un messaggio iniziale. Tuttavia, il client non sa ancora se un avversario sta intercettando e/o alterando la sua comunicazione prima che raggiunga il server TLS. Non sa nemmeno se il vero server TLS associato a quel nome di dominio ha mai ricevuto i suoi messaggi iniziali.
La prima risposta dal server in TLS può contenere un certificato. Affinché il client TLS possa autenticare che sta parlando con il server TLS previsto, il client deve convalidare che questo certificato è associato al nome di dominio utilizzato dal client per raggiungere il server. Attualmente, il client deve estrarre il nome di dominio dal certificato e deve convalidare con successo il certificato, incluso il concatenamento a un'ancora di fiducia.
Esiste un modo diverso per autenticare l'associazione del certificato del server con il nome di dominio previsto senza fidarsi di una CA esterna. Dato che l'amministratore DNS di un nome di dominio è autorizzato a fornire informazioni identificative sulla zona, ha senso consentire a quell'amministratore di creare anche un legame autorevole tra il nome di dominio e un certificato che potrebbe essere utilizzato da un host con quel nome di dominio. Il modo più semplice per farlo è utilizzare il DNS, proteggendo il legame con DNSSEC.
Esistono molti casi d'uso per tale funzionalità. [RFC6394] elenca quelli a cui si applica il tipo RR DNS di questo documento. [RFC6394] elenca anche molti requisiti, la maggior parte dei quali si ritiene che questo documento soddisfi. La sezione 5 copre in dettaglio l'applicabilità di questo documento ai casi d'uso. Il protocollo in questo documento può essere generalmente indicato come protocollo "DANE TLSA". ("TLSA" non sta per nulla; è solo il nome del tipo RR.)
Questo documento si applica sia a TLS [RFC5246] che a Datagram TLS (DTLS) [RFC6347]. Per rendere il documento più leggibile, parla principalmente solo di "TLS", ma in tutti i casi significa "TLS o DTLS". Sebbene i riferimenti in questo paragrafo riguardino TLS e DTLS versione 1.2, il protocollo DANE TLSA può essere utilizzato anche con versioni precedenti di TLS e DTLS.
Questo documento riguarda solo l'associazione sicura di certificati per TLS e DTLS con nomi host; il recupero di certificati da DNS per altri protocolli è gestito in altri documenti. Ad esempio, le chiavi per IPsec sono coperte in [RFC4025] e le chiavi per Secure SHell (SSH) sono coperte in [RFC4255].
1.3. Metodo per proteggere le associazioni di certificati (Method for Securing Certificate Associations)
Un'associazione di certificato è formata da un'informazione che identifica un certificato e il nome di dominio in cui viene eseguita l'applicazione server. Anche la combinazione di un'ancora di fiducia e un nome di dominio può essere un'associazione di certificato.
Una query DNS può restituire più associazioni di certificati, come nel caso di un server che sta passando da un certificato a un altro (descritto più in dettaglio nell'appendice A.4).
Questo documento si applica solo ai certificati PKIX [RFC5280], non ai certificati di altri formati.
Questo documento definisce un metodo sicuro per associare il certificato ottenuto dal server TLS con un nome di dominio utilizzando DNS; le informazioni DNS devono essere protette da DNSSEC. Poiché l'associazione del certificato è stata recuperata in base a una query DNS, il nome di dominio nella query è per definizione associato al certificato. Si noti che questo documento non copre come associare i certificati con i nomi di dominio per i protocolli applicativi che dipendono da SRV, NAPTR e record di risorse DNS simili. Si prevede che futuri documenti copriranno metodi per effettuare tali associazioni, e tali documenti potrebbero o meno dover aggiornare questo.
DNSSEC, definito in [RFC4033], [RFC4034] e [RFC4035], utilizza chiavi crittografiche e firme digitali per fornire l'autenticazione dei dati DNS. Le informazioni recuperate dal DNS e convalidate utilizzando DNSSEC sono quindi dimostrate essere i dati autorevoli. La firma DNSSEC deve essere convalidata su tutte le risposte che utilizzano DNSSEC per assicurare la prova dell'origine dei dati.
Questo documento non specifica come avviene la convalida DNSSEC perché ci sono molte proposte diverse su come un client potrebbe ottenere risultati DNSSEC convalidati, come da un resolver consapevole di DNSSEC codificato nell'applicazione, da un resolver DNSSEC fidato sulla macchina su cui viene eseguita l'applicazione, o da un resolver DNSSEC fidato con cui l'applicazione sta comunicando su un canale o rete autenticato e protetto dall'integrità. Questo è descritto più in dettaglio nella sezione 7 di [RFC4033].
Questo documento riguarda solo l'ottenimento delle informazioni DNS per l'associazione del certificato in modo sicuro utilizzando DNSSEC; altri meccanismi DNS sicuri sono fuori dall'ambito.
1.4. Terminologia (Terminology)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in RFC 2119 [RFC2119].
Questo documento utilizza anche la terminologia standard PKIX, DNSSEC, TLS e DNS. Vedere [RFC5280], [RFC4033], [RFC5246] e STD 13 [RFC1034] [RFC1035], rispettivamente, per questi termini. Inoltre, i termini relativi ai servizi applicativi protetti da TLS e ai nomi DNS sono tratti da [RFC6125].