4. Uso dei record TLSA in TLS (Use of TLSA Records in TLS)

La sezione 2.1 di questo documento definisce le regole di corrispondenza obbligatorie per i dati dalle associazioni di certificati TLSA e i certificati ricevuti dal server TLS.

La sessione TLS che deve essere stabilita DEVE essere per il numero di porta e il nome di trasporto specifici che sono stati forniti nella query TLSA.

Alcune specifiche per le applicazioni che funzionano su TLS, come [RFC2818] per HTTP, richiedono che il certificato del server abbia un nome di dominio che corrisponde al nome host atteso dal client. Alcune specifiche, come [RFC6125], dettagliano come far corrispondere l'identità fornita in un certificato PKIX con quelle attese dall'utente.

Se un record TLSA ha utilizzo del certificato 2, il server TLS corrispondente DOVREBBE inviare il certificato a cui si fa riferimento proprio come attualmente invia i certificati intermedi.

4.1. Associazioni di certificati utilizzabili (Usable Certificate Associations)

Un'implementazione di questo protocollo effettua una query DNS per i record TLSA, convalida questi record utilizzando DNSSEC e utilizza i record TLSA risultanti e lo stato di convalida per modificare le sue risposte al server TLS.

La determinazione se un RRSet TLSA può essere utilizzato DEVE essere basata sullo stato di convalida DNSSEC (come definito in [RFC4033]).

• Un RRSet TLSA il cui stato di convalida DNSSEC è sicuro DEVE essere utilizzato come associazione di certificato per TLS a meno che una politica locale non proibisca l'uso dell'associazione di certificato specifica nel RRSet TLSA sicuro.

• Se lo stato di convalida DNSSEC sulla risposta alla richiesta del RRSet TLSA è falso, questo DEVE causare il mancato avvio di TLS o, se la negoziazione TLS è già in corso, DEVE causare l'interruzione della connessione.

• Un RRSet TLSA il cui stato di convalida DNSSEC è indeterminato o non sicuro non può essere utilizzato per TLS e DEVE essere considerato inutilizzabile.

I client che convalidano le firme DNSSEC da soli DEVONO utilizzare le procedure di convalida DNSSEC standard. I client che si affidano a un'altra entità per eseguire la convalida della firma DNSSEC DEVONO utilizzare un meccanismo sicuro tra loro e il validatore. Esempi di trasporti sicuri verso altri host includono TSIG [RFC2845], SIG(0) [RFC2931] e IPsec [RFC6071]. Si noti che non è sufficiente utilizzare un trasporto sicuro verso un resolver DNS che non esegue la convalida della firma DNSSEC. Vedere la sezione 8.3 per ulteriori considerazioni sulla sicurezza relative ai validatori esterni.

Se un'associazione di certificato contiene un utilizzo del certificato, un selettore o un tipo di corrispondenza che non è compreso dal client TLS, quell'associazione di certificato DEVE essere considerata inutilizzabile. Se i dati di confronto per un certificato sono malformati, l'associazione di certificato DEVE essere considerata inutilizzabile.

Se un'associazione di certificato contiene un tipo di corrispondenza o dati di associazione di certificato che utilizzano un algoritmo crittografico considerato troppo debole per la politica del client TLS, l'associazione di certificato DEVE essere considerata inutilizzabile.

Se un'applicazione riceve zero associazioni di certificati utilizzabili da una richiesta DNS o dalla sua cache, elabora TLS nel modo normale senza alcun input dai record TLSA. Se un'applicazione riceve una o più associazioni di certificati utilizzabili, tenta di far corrispondere ciascuna associazione di certificato con il certificato dell'entità finale del server TLS fino a quando non viene trovata una corrispondenza riuscita. Durante l'handshake TLS, se nessuna delle associazioni di certificati corrisponde al certificato fornito dal server TLS, il client TLS DEVE interrompere l'handshake.

Un attaccante in grado di deviare un utente verso un server sotto il suo controllo è anche probabilmente in grado di bloccare le richieste DNS dall'utente o le risposte DNS inviate all'utente. Pertanto, per ottenere qualsiasi beneficio di sicurezza dall'utilizzo del certificato 0 o 1, un'applicazione che invia una richiesta per i record TLSA deve ottenere una risposta firmata valida contenente record TLSA o la verifica che il dominio è non sicuro o indeterminato. Se una richiesta per un record TLSA non soddisfa uno di questi due criteri ma l'applicazione continua comunque con l'handshake TLS, l'applicazione non ha ottenuto alcun beneficio da TLSA e NON DOVREBBE fare alcuna indicazione interna o esterna che TLSA è stato applicato. Se un'applicazione ha un'impostazione di configurazione che ha attivato l'uso di TLSA, o ha qualsiasi indicazione che TLSA è in uso (indipendentemente dal fatto che ciò sia configurabile o meno), quell'applicazione NON DEVE avviare una connessione TLS o DEVE interrompere un handshake TLS se entrambi i due criteri sopra non sono soddisfatti.

L'applicazione può eseguire la ricerca TLSA prima di avviare l'handshake TLS, o farlo durante l'handshake TLS: la scelta spetta al client.