Scegli un DKIM configurazione chiave che soddisfa il protocollo e funziona su tutti i sistemi che inviano e ricevono la posta. Un numero maggiore in un pannello di controllo non è una decisione di sicurezza completa. Registra l'algoritmo, il tipo di chiave e la prova del destinatario e mantieni la forza crittografica separata dalla consegna e allineamento.
Utilizza i requisiti RSA aggiornati
RFC 8301 aggiorna la vecchia specifica DKIM . Per RSA, le chiavi di firma devono essere di almeno 1024 bit e i firmatari devono utilizzare almeno 2048 bit. I verificatori devono supportare la convalida con chiavi RSA da 1024 a 4096 bit, possono supportare chiavi più grandi e non devono accettare come valide chiavi RSA inferiori a 1024 bit. Un verificatore può comunque applicare una policy locale basata sulla lunghezza della chiave.
La stessa RFC vieta rsa-sha1 per la firma e la verifica. Non utilizzare l'esempio SHA-1 di un tutorial obsoleto come consiglio di distribuzione corrente. Controlla l'effettivo a= valore in un ricevuto DKIM-Signature e il tipo di chiave raggiunto tramite its selettore, piuttosto che fidarsi del ricordo della configurazione originale da parte di un amministratore.
Il minimo e la raccomandazione rispondono a domande diverse. Una chiave RSA a 1024 bit può soddisfare il piano specificato senza soddisfare la scelta consigliata più forte. Se l'organizzazione lo conserva a causa di una limitazione di sistema documentata, registrare l'eccezione, il proprietario e la condizione di rimozione. Non descrivere quell'eccezione come la migliore configurazione universale.
Controlla il servizio prima di generare le chiavi
Determina se il fornitore gestisce le chiavi o accetta il materiale fornito dal cliente. Documenti Amazon SES Easy DKIM a 2048 bit predefinito; che il comportamento del prodotto non dovrebbe essere generalizzato a tutte le piattaforme di posta. Alcuni servizi espongono solo un set di opzioni supportato. Una chiave a 4096 bit generata è inutile se il firmatario previsto non riesce a caricarla o se il percorso di provisioning DNS ne corrompe il record pubblico.
RFC 8463 aggiunge Ed25519-SHA256: i firmatari dovrebbero implementarlo e i verificatori devono implementarlo secondo tale specifica. Le sue dimensioni delle chiavi non sono numericamente paragonabili alle dimensioni RSA come misure di sicurezza equivalenti. Il supporto nello standard non dimostra il supporto in ogni firmatario, destinatario o interfaccia di amministrazione distribuita. Tratta la migrazione di un algoritmo come una modifica di compatibilità con prove esplicite, non come un'impostazione cosmetica. La sezione 6 RFC 8463 consente RSA parallela e Ed25519 firme durante la transizione; devono utilizzare selettori separati poiché ciascun selettore identifica un singolo record chiave. Verificare che il servizio di firma effettivo supporti questo approccio prima di pianificarlo.
Costruisci un'utile matrice di validazione
Per ogni percorso di invio, registrare il software o il fornitore, l'algoritmo, la dimensione della chiave ove rilevante, il selettore, il metodo di pubblicazione e un sistema di ricezione rappresentativo. Tre test separati: il firmatario accetta la configurazione, la chiave pubblica si risolve intatta e un destinatario verifica un messaggio prodotto da quel firmatario.
Una migrazione illustrativa inizia con un firmatario di fatturazione RSA legacy a 1024 bit. L'obiettivo proposto è RSA a 2048 bit con SHA-256. Pubblica un nuovo selettore utilizzando il processo supportato dalla piattaforma, verifica la chiave, invia tramite l'applicazione di fatturazione e controlla il risultato della ricezione. Un test effettuato dalla casella di posta di un dipendente non dimostra che l'applicazione di fatturazione è stata cambiata. Mantenere la vecchia dipendenza solo per la transizione pianificata e la posta legittima ritardata, a meno che la risposta all'incidente non imponga diversamente.
Interpretare con precisione i fallimenti
Se la pubblicazione di un record più grande non riesce, esamina l'interfaccia DNS e la rappresentazione TXT prima di indebolire la crittografia. Se la verifica segnala un algoritmo non supportato, conservare tale risultato confrontandolo con la versione effettiva del ricevitore e del software. Se DKIM passa ma DMARC fallisce, controlla l'allineamento dell'identità invece di modificare nuovamente la dimensione della chiave.
Documentare ciò che è stato testato e ciò che rimane sconosciuto. Un campione di ricevitori di successo è un’utile prova operativa, non una garanzia che copra l’intera Internet. Pianifica la revisione quando cambiano il fornitore, la guida crittografica o importanti destinatari. La decisione è difendibile quando i suoi requisiti, i limiti di attuazione e i risultati osservati sono tutti visibili.
Lettura correlata
Firme DKIM RSA ed Ed25519: domande di implementazione e interoperabilità · Sintassi della chiave pubblica DKIM : identificare valori DNS troncati o non corretti.
Registrare la decisione prima del lancio
- Percorso corrente: applicazione, proprietario, dominio di firma, selettore e algoritmo emesso.
- Scelta proposta: RSA-SHA256 supportato a 2048 bit o superiore ove giustificato, oppure transizione Ed25519 supportata.
- Prova di accettazione: il firmatario carica la chiave; DNS lo fornisce intatto; un sistema di ricezione attendibile verifica un messaggio da questa applicazione.
- Condizione di arresto: algoritmo non supportato, chiave non valida o firma mancante. Risolvere il difetto prima di ritirare il selettore funzionante.
- Eccezione: se si mantiene RSA a 1024 bit, indicare la limitazione, il proprietario del rischio e la data per la rivalutazione.