12. Security Considerations (Considerazioni di sicurezza)

12.1. Hashing Considerations (Considerazioni sull'hash)

12.1.1. Dictionary Attacks (Attacchi a dizionario)

Gli RR NSEC3 restano vulnerabili ad attacchi a dizionario (cioè l'attaccante recupera tutti gli RR NSEC3, poi calcola gli hash di tutti i nomi di dominio probabili, confrontandoli con gli hash trovati negli RR NSEC3, e così enumera la zona). Questi sono sostanzialmente più costosi di quanto sarebbe stato enumerare gli RR NSEC originali, e in ogni caso un tale attacco potrebbe essere usato direttamente contro il name server stesso eseguendo interrogazioni per tutti i nomi probabili, sebbene ciò sarebbe ovviamente più rilevabile. Il costo di questo attacco offline può essere scelto impostando il numero di iterazioni nell'RR NSEC3.

Le zone sono anche vulnerabili a un attacco a dizionario precalcolato: cioè si calcola una volta una lista di hash per tutti i nomi probabili, poi si scansionano periodicamente gli RR NSEC3 e si confrontano con gli hash precalcolati. Questo attacco è impedito cambiando il salt a intervalli regolari.

Il salt DOVREBBE essere lungo almeno 64 bit e imprevedibile, così che un attaccante non possa anticipare il valore del salt e calcolare il prossimo insieme di dizionari prima che la zona sia pubblicata.

12.1.2. Collisions (Collisioni)

Possono verificarsi collisioni di hash tra QNAME e nome del titolare di un RR NSEC3. Quando accade, sarà impossibile dimostrare la non esistenza del QNAME collidente. Tuttavia, con SHA-1, ciò è altamente improbabile (dell'ordine di 1 su 2^160). Si noti che DNSSEC si affida già alla presunzione che una funzione di hash crittografica sia resistente alle seconde preimmagini, poiché tali funzioni di hash sono usate per generare e convalidare firme e RR DS.

12.1.3. Transitioning to a New Hash Algorithm (Transizione a un nuovo algoritmo di hash)

Sebbene i formati RR NSEC3 e NSEC3PARAM includano un parametro di algoritmo di hash, il presente documento non definisce un meccanismo particolare per transitare in sicurezza da un algoritmo di hash NSEC3 a un altro. Quando si specifica un nuovo algoritmo di hash per l'uso con NSEC3, DEVE essere definito anche un meccanismo di transizione. È possibile che gli unici meccanismi di transizione pratici e accettabili richiedano una transizione intermedia a uno stato non sicuro, o a uno stato che usa record NSEC invece di NSEC3.

12.1.4. Using High Iteration Values (Uso di valori di iterazione elevati)

Poiché i validatori dovrebbero trattare le risposte contenenti RR NSEC3 con valori di iterazione elevati come non sicure, la presenza di un solo RR NSEC3 firmato con valore di iterazione elevato in una zona offre agli attaccanti un possibile attacco di downgrade.

L'attacco consiste semplicemente nel rimuovere gli RR NSEC3 esistenti da una risposta e sostituire o aggiungere un singolo (o più) RR NSEC3 che usa un valore di iterazioni elevato alla risposta. I validatori saranno quindi costretti a trattare la risposta come non sicura. Questo attacco sarebbe efficace solo quando sono soddisfatte tutte le condizioni seguenti:

È presente nella zona almeno un RR NSEC3 firmato che usa un valore di iterazioni elevato.
L'attaccante ha accesso a uno o più di questi RR NSEC3. Ciò è banalmente vero quando gli RR NSEC3 con valori di iterazione elevata sono restituiti in risposte tipiche, ma può essere vero anche se l'attaccante può accedere alla zona tramite interrogazioni AXFR o IXFR, o qualsiasi altra metodologia.

Usare un numero elevato di iterazioni introduce anche un'ulteriore opportunità di denial-of-service contro i server, poiché i server devono calcolare diversi hash per risposta negativa o jolly.

12.2. Opt-Out Considerations (Considerazioni sull'Opt-Out)

Il flag Opt-Out (O) consente che esistano nomi non firmati, sotto forma di deleghe verso zone non firmate, all'interno di una zona altrimenti firmata. Tutti i nomi non firmati sono, per definizione, non sicuri e la loro validità o esistenza non può essere dimostrata crittograficamente.

In generale:

I resource record con nomi non firmati (esistenti o meno) soffrono delle stesse vulnerabilità degli RR in una zona non firmata. Queste vulnerabilità sono descritte più in dettaglio in [RFC3833] (si noti in particolare la sezione 2.3, "Name Chaining", e la sezione 2.6, "Authenticated Denial of Domain Names").
I resource record con nomi firmati hanno la stessa sicurezza che si usi o meno Opt-Out.

Si noti che con o senza Opt-Out, una delega non sicura può essere alterata in modo non rilevabile da un attaccante. Per questo, la principale differenza di sicurezza quando si usa Opt-Out è la perdita della capacità di dimostrare l'esistenza o la non esistenza di una delega non sicura nell'estensione di un RR NSEC3 Opt-Out.

In particolare, ciò significa che un'entità malevola può essere in grado di inserire o eliminare RR con nomi non firmati. Questi RR sono normalmente RR NS, ma ciò include anche espansioni jolly firmate (mentre l'RR jolly stesso è firmato, il suo nome espanso è un nome non firmato).

Si noti che poter aggiungere una delega è funzionalmente equivalente a poter aggiungere qualsiasi tipo di RR: un attaccante deve solo falsificare una delega verso un name server sotto il suo controllo e collocare gli RR necessari all'apice della sottozona.

Sebbene in casi particolari questa questione possa non presentare un problema di sicurezza significativo, in generale non dovrebbe essere presa alla leggera. Pertanto è fortemente consigliato usare Opt-Out con parsimonia. In particolare, gli strumenti di firma della zona NON DOVREBBERO impostare per default l'uso di Opt-Out, e POSSONO scegliere di non supportare affatto Opt-Out.

12.3. Other Considerations (Altre considerazioni)

Percorrere gli RR NSEC3 rivelerà il numero totale di RR nella zona (più i non terminali vuoti), e anche quali tipi vi sono. Ciò potrebbe essere mitigato aggiungendo voci fittizie, ma certamente si può sempre trovare un limite superiore.