1. Introduzione (Introduction)
Le «estensioni di sicurezza DNS (DNSSEC)» [RFC9364] sono utilizzate per fornire l'autenticazione dei dati DNS. Gli algoritmi di firma DNSSEC sono definiti da vari RFC, tra cui [RFC4034], [RFC4509], [RFC5155], [RFC5702], [RFC5933], [RFC6605] e [RFC8080].
Per garantire l'interoperabilità, un insieme di algoritmi di chiave pubblica DNS (DNSKEY) «obbligatori da implementare» è definito in [RFC8624]. Per rendere lo stato attuale degli algoritmi più facilmente accessibile e comprensibile e per facilitare la pubblicazione di modifiche future a queste raccomandazioni, questo documento sposta lo stato canonico degli algoritmi da [RFC8624] ai registri degli algoritmi DNSSEC IANA. Questo documento incorpora anche le considerazioni DNSSEC IANA riviste da [RFC9157]. Inoltre, come consiglio agli operatori, aggiunge raccomandazioni per la distribuzione e l'utilizzo di questi algoritmi.
Questo è simile al processo utilizzato per il registro «TLS Cipher Suites» [TLS-ciphersuites], dove l'elenco canonico delle cipher suite si trova nel registro IANA e gli RFC fanno riferimento al registro IANA.
1.1. Destinatari del documento (Document Audience)
Le colonne aggiunte ai registri IANA «DNS Security Algorithm Numbers» [DNSKEY-IANA] e «Digest Algorithms» [DS-IANA] sono rivolte agli operatori e agli implementatori DNSSEC.
Le implementazioni devono soddisfare elevate aspettative di sicurezza e fornire interoperabilità tra varie implementazioni e con versioni diverse.
Il campo della crittografia si evolve continuamente. Appaiono nuovi algoritmi più robusti e gli algoritmi esistenti possono rivelarsi meno sicuri di quanto originariamente pensato. Pertanto, i requisiti di implementazione degli algoritmi e le linee guida di utilizzo devono essere aggiornati di tanto in tanto per riflettere la nuova realtà e consentire una transizione fluida verso algoritmi più sicuri nonché la deprecazione di algoritmi ritenuti non più sicuri.
Le implementazioni devono essere conservative nella selezione degli algoritmi che implementano al fine di minimizzare sia la complessità del codice sia la superficie di attacco.
La prospettiva degli implementatori può differire da quella di un operatore che desidera distribuire e configurare DNSSEC solo con l'algoritmo più sicuro. In quanto tale, questo documento aggiunge anche nuove raccomandazioni su quali algoritmi dovrebbero essere distribuiti indipendentemente dallo stato di implementazione. In generale, ci si aspetta che la distribuzione di algoritmi obsoleti dovrebbe generalmente essere ridotta prima che le implementazioni smettano di supportarli.
1.2. Aggiornamento dei livelli di requisito degli algoritmi (Updating Algorithm Requirement Levels)
Nel momento in cui un algoritmo crittografico DNSSEC viene reso obbligatorio da implementare, dovrebbe già essere disponibile nella maggior parte delle implementazioni. Questo documento definisce una modifica della registrazione IANA per consentire ai documenti futuri di specificare le raccomandazioni di implementazione per ciascun algoritmo, poiché lo stato di raccomandazione di ciascun algoritmo crittografico DNSSEC dovrebbe cambiare nel tempo. Ad esempio, non vi è alcuna garanzia che gli algoritmi appena introdotti diventeranno obbligatori da implementare in futuro. Allo stesso modo, gli algoritmi pubblicati sono continuamente soggetti ad attacchi crittografici e possono diventare troppo deboli, o addirittura essere completamente violati, e richiederanno la deprecazione in futuro.
Ci si aspetta che la deprecazione di un algoritmo venga eseguita gradualmente. Questo fornisce tempo alle implementazioni per aggiornare i loro algoritmi implementati rimanendo interoperabili. A meno che non vi siano forti ragioni di sicurezza, ci si aspetta che un algoritmo venga retrocesso da MUST a NOT RECOMMENDED o MAY, invece che direttamente da MUST a MUST NOT. Allo stesso modo, un algoritmo che non è stato menzionato come obbligatorio da implementare dovrebbe essere prima introdotto come RECOMMENDED invece di un MUST.
Poiché l'effetto dell'utilizzo di un algoritmo DNSKEY sconosciuto è che la zona viene trattata come non sicura, si raccomanda che gli algoritmi retrocessi a NOT RECOMMENDED o inferiore non vengano utilizzati dai nameserver autoritativi e dai firmatari DNSSEC per creare nuovi DNSKEY. Questo garantisce che l'uso di algoritmi deprecati diminuisca nel tempo. Una volta che un algoritmo ha raggiunto un livello di distribuzione sufficientemente basso, può essere contrassegnato come MUST NOT, in modo che i resolver ricorsivi possano rimuovere il supporto per la sua convalida.
I resolver ricorsivi di convalida sono incoraggiati a mantenere il supporto per tutti gli algoritmi non contrassegnati come MUST NOT.
1.3. Notazione dei requisiti (Requirements Notation)
Le parole chiave «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «NOT RECOMMENDED», «MAY» e «OPTIONAL» in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in lettere maiuscole, come mostrato qui.
[RFC2119] considera il termine SHOULD equivalente a RECOMMENDED e SHOULD NOT equivalente a NOT RECOMMENDED. Questo documento ha scelto di utilizzare i termini RECOMMENDED e NOT RECOMMENDED, poiché ciò esprime più chiaramente le raccomandazioni agli implementatori.