Appendice C. Considerazioni speciali

I paragrafi seguenti chiariscono comportamenti specifici e spiegano considerazioni particolari per le implementazioni.

C.1. Salting

Aggiungere un salt agli owner name originari prima dell'hashing aumenta il costo di un dizionario di valori hash pregenerati. Per ogni bit di salt, il costo di un dizionario precalcolato raddoppia, poiché deve contenere una voce per ogni parola combinata con ogni possibile valore di salt. Il RR NSEC3 può usare al massimo 2040 bit, 255 ottetti, di salt, moltiplicando il costo per 2^2040. In pratica, ciò significa che un attaccante deve ricalcolare il dizionario ogni volta che il salt viene modificato.

L'inclusione di un salt, indipendentemente dalla sua dimensione, non influenza il costo di costruzione dei RR NSEC3, ma aumenta la dimensione del RR NSEC3.

DEVE esistere almeno un insieme completo di RR NSEC3 per la zona che usi lo stesso valore di salt.

Il salt DOVREBBE essere modificato periodicamente per impedire il precalcolo basato su un unico salt. È RACCOMANDATO modificarlo a ogni nuova firma.

Si noti che questo può far sì che un resolver osservi RR con valori di salt differenti per la stessa zona. È innocuo, poiché ogni RR è autonomo: nega l'insieme di owner name i cui hash, ottenuti con il salt nel RR NSEC3, cadono tra i due hash del RR NSEC3. Solo il server necessita di un insieme completo di RR NSEC3 con lo stesso salt per poter rispondere a ogni possibile query.

Non è vietato avere RR NSEC3 con salt differenti nella stessa zona. Tuttavia, affinché i server autorevoli possano trovare con coerenza i RR NSEC3 coprenti, il server autorevole DEVE scegliere un unico insieme di parametri, algoritmo, salt e iterazioni, da usare nella selezione dei RR NSEC3.

C.2. Collisione hash

Le collisioni hash si verificano quando messaggi differenti hanno lo stesso valore hash. Il numero atteso di nomi di dominio necessario per avere una probabilità di 1 su 2 di una singola collisione è circa 2^(n/2) per un hash di lunghezza n bit, cioè 2^80 per SHA-1. Sebbene questa probabilità sia estremamente bassa, i paragrafi seguenti trattano come evitare le collisioni e valutare i possibili danni in caso di attacco che sfrutti collisioni hash.

C.2.1. Evitare collisioni hash durante la generazione

Durante la generazione dei RR NSEC3, i valori hash sono considerati univoci. Nel caso teorico che si verifichi una collisione, DEVE essere scelto un salt alternativo e tutti i valori hash DEVONO essere rigenerati.

C.2.2. Analisi del requisito di seconda preimmagine

Una funzione hash crittografica possiede la proprietà di resistenza alla seconda preimmagine. Tale proprietà significa che è computazionalmente impraticabile trovare un altro messaggio con lo stesso valore hash di un messaggio dato; ossia, data la preimmagine X, trovare una seconda preimmagine X' != X tale che hash(X) = hash(X'). Per SHA-1, il fattore di lavoro per trovare una seconda preimmagine è dell'ordine di 2^160. Per condurre un attacco che usi un RR NSEC3 esistente, un avversario deve trovare una seconda preimmagine.

Assumendo che un avversario sia in grado di condurre un attacco così estremo, il danno reale consiste nella possibilità di generare un messaggio di risposta che affermi l'esistenza di un certo QNAME, cioè della seconda preimmagine, quando in realtà il QNAME non esiste: un falso positivo. Ciò indurrà un resolver consapevole della sicurezza a rieseguire la query per il nome inesistente oppure farà fallire la query iniziale. L'avversario non può condurre questo attacco contro un nome esistente, ma solo contro un nome che non può scegliere e che non esiste ancora.