Va bene pubblicare un record TLSA per servizi CNAME non DNSSEC?

Naviga le tue risposte
2

Nello scenario con due nomi di dominio

  • example.com protetto con DNSSEC
  • example.org non protetto con DNSSEC

e un servizio di posta in esecuzione a smtp.example.org :

Voglio proteggere il servizio di posta usando TLSA / DANE. È in qualche modo possibile e posso aspettarmi che funzioni per la maggior parte dei software DANE?

L'idea è di pubblicare un record TLSA _25._tcp.smtp.example.com e un record CNAME smtp.example.com che punta a smtp.example.org . La risposta dalla zona org non può essere considerata attendibile perché non è protetta da DNSSEC, ma il record TLSA da com può. È un modo ragionevole per iscrivere DANE per zone che non sono ancora DNSSEC pronte?

Aggiornamento: Ho appena trovato questo nella sezione 7 di rfc7671 :

The complexity of coordinating key management is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 6. Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated). If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups.

Quindi nel mio caso lo stato di convalida non è "sicuro" e il rfc continua con:

Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name. That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name.

Il client "dovrebbe" alla fine risolvere il nome di dominio iniziale, ma non sono sicuro che ciò avvenga nella maggior parte dei casi.

    
posta Dons 03.04.2018 - 15:37
fonte

2 risposte

3

La configurazione: 

example.com. IN MX 0 smtp.example.com. ; AD=1
smtp.example.com. IN CNAME smtp.example.org. ; AD=1
smtp.example.org. IN A 192.0.2.1 ; AD=0
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1

Fornirà TLS protetto da DANE con almeno alcune implementazioni DANE, ad es. Postfix. Tuttavia, questo potrebbe non funzionare in tutti i casi, per due motivi:

  1. I CNAME violano il requisito RFC che il campo Exchange del record MX sia già canonico e non un CNAME (vedi link ), quindi, anche se non conosco alcun MTA che non consente l'uso di CNAME qui, sarebbero conformi allo standard se lo facessero. Tuttavia, nel mio sondaggio di (oggi) 4.244.642 domini firmati DNSSEC che hanno record MX, trovo 1.432.478 host MX distinti di cui 21.262 sono CNAME (che servono 34.886 domini) e apparentemente non hanno problemi. Quindi in pratica i CNAME nei record MX sembrano funzionare.
  2. Ancora più importante, il link spiega che le ricerche TLSA devono essere saltate quando si trova il nome host MX in una zona non firmata, come evidenziato dallo stato di sicurezza dei suoi record A / AAAA. Quando non ci sono CNAME coinvolti, questo è semplice e le implementazioni non sono in grado di gestire in modo errato questo caso. Quando il nome host MX è un CNAME in una zona non protetta, mi aspetto che alcune implementazioni (ad es. Credo Exim) non determinino lo stato di sicurezza del CNAME iniziale e quindi (diversamente da Postfix) non tenteranno le ricerche TLSA in quel caso.

Capire se il record CNAME RR che punta a record A non sicuri è sicuro richiede una query CNAME separata con lo stesso nome, che sopprime la ricorsione nel resolver e restituisce lo stato di sicurezza del CNAME stesso. Exim, e probabilmente alcuni altri MTA potrebbero non farlo. Mentre RFC7672 dice che DOVREBBE farlo, è una logica piuttosto sottile e probabilmente verrà saltata nelle implementazioni.

In conclusione, se vuoi davvero che DANE funzioni, evita i CNAME in domini insicuri e, se necessario, pubblica i record A / AAAA nel dominio sicuro che duplicano i record A / AAAA dell'host sottostante: 

example.com. IN MX 0 smtp.example.com. ; AD=1
; smtp.example.com. IN CNAME smtp.example.org. ; AD=0
smtp.example.com. IN A 192.0.2.1 ; AD=1 (cloned from smtp.example.org)
_25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0...b855 ; AD=1
    
risposta data 03.04.2018 - 21:04
fonte
0
  1. Would it make sense in this case to also publish double DANE/TLSA records like you are suggesting on http://imrryr.org/~viktor/ICANN61-viktor.pdf#page=20?

La scelta dei tipi di record TLS da utilizzare per una solida gestione delle chiavi è un problema per lo più separato. Quindi sì, certo, probabilmente ci dovrebbero essere almeno due record sia dual "3 1 1" (corrente + successiva) o "3 1 1" + "2 1 1" (server + emittente).

Tuttavia:

  1. Besides, the used certificate probably won't match smtp.example.com. I guess that doesn't really matter, because sending mail servers usually don't match the server name against the certificate. Correct?

Il certificato deve corrispondere a tutti i nomi host MX utilizzati da qualsiasi dominio per indirizzare la posta al server in questione. Questo è ciò che subjectAlternativeName è nel certificato. Mentre nella corrispondenza SMTP dei record TLSA con l'utilizzo del certificato DANE-EE (3) ignora esplicitamente i nomi DNS nel certificato, prendendo il nome binding dal record TLSA in DNS, lo stesso non è vero per l'utilizzo dei certificati DANE-TA (2) . Quindi assicurati di elencare tutti i nomi necessari nel certificato.

    
risposta data 11.04.2018 - 00:43
fonte

Leggi altre domande sui tag

Qual è la trappola di connessione con Tor su un hotspot Wi-Fi pubblico? Google ha accesso alle sequenze di tasti sulla tastiera del nostro dispositivo Android? [duplicare]