Algoritmi di firma DNSSEC

13

Virtualmin supporta una raffica di algoritmi per DNSSEC: RSASHA1, RSASHA256, RSAMD5, DSA, DH, HMAC-MD5 (???), NSEC3RSASHA1, NSEC3DSA.

Se ho capito bene, c'è Proof of Concept disponibile per SHA1 che è facile da compromettere quando usato con DKIM, a causa della lunghezza dei dati. Questo mi porterebbe a credere che lo stesso valga per DNSSEC.

Quali sono gli algoritmi chiave più adatti per l'uso in DNSSEC con gli ambienti di produzione?

E quali documenti tecnici di supporto sono disponibili per giustificare il ragionamento per la scelta dell'algoritmo?

Tuttavia, qui si trova un equilibrio, lo stesso che INFOSEC deve trovare così spesso, nella scelta di un algoritmo appropriatamente sicuro senza sprecare zelante risorse negli ambienti di produzione.

Tuttavia, un algoritmo appropriato per i cyber-sistemi vitali (informazioni personali sensibili o finanziarie) potrebbe variare da uno per i sistemi mission-critical.

O la minaccia degli attacchi man-in-the-middle è troppo grande in un evento di cyber-diaster globale, tale che la crittografia più strong è garantita anche per i sistemi mission-critical senza informazioni altamente sensibili?

    
posta insignificant zebra 26.03.2014 - 15:09
fonte

2 risposte

5

(Sì, la domanda è vecchia, ma merita una risposta.)

Alcune regole per la crittografia moderna:

L'uso di un HMAC per DNSSEC non ha senso, un HMAC richiede ad entrambe le parti di avere accesso allo stesso segreto; nel contesto di DNSSEC, ciò significa che i client possono falsificare il server, rendendolo inutilizzabile.

C'è un molti algoritmi mancanti da la tua lista, non so perché Virtualmin ti offre queste opzioni. Le opzioni ECDSA offrono risposte più piccole e un utilizzo della CPU leggermente inferiore nelle operazioni di firma.

Data la durata relativamente breve delle chiavi e dei tasti DNSSEC; risposte, preferirei opzioni più brevi dopo aver preso in considerazione tutto quanto sopra. Ciò significa l'uso di RSASHA256 con una chiave RSA a 2048 bit o ECDSAP256SHA256 (ECDSA a 256 bit con SHA256).

    
risposta data 01.11.2014 - 01:50
fonte
0

A settembre 2018, Viktor Dukhovni ha riportato gli algoritmi osservati in uso e le lunghezze delle chiavi sono:

DNSKEY parameter frequency (1000 or more instances), by zone count:

 kskalgs | flags | proto | alg
 --------+-------+-------+-----
    4780 |   257 |     3 |   3
  358979 |   257 |     3 |   5
 2210428 |   257 |     3 |   7
 4198328 |   257 |     3 |   8
   87469 |   257 |     3 |  10
 1844138 |   257 |     3 |  13
   62481 |   257 |     3 |  14
 --------+-------+-------+-----

 zskalgs | flags | proto | alg
 --------+-------+-------+-----
    4780 |   256 |     3 |   3
  132748 |   256 |     3 |   5
 2192269 |   256 |     3 |   7
 4142767 |   256 |     3 |   8
   87250 |   256 |     3 |  10
  791434 |   256 |     3 |  13
   61548 |   256 |     3 |  14
 --------+-------+-------+-----

RSA key size distribution (1000 or more instances), by zone count:

 kskdomains | bits
------------+------
      67580 | 4096
    5149822 | 2048
     302182 | 1536
       2992 | 1280
    1333428 | 1024
       8392 |  512
------------+------

 zskdomains | bits
 -----------+------
      13287 | 4096
     110595 | 2048
     306770 | 1280
    6115735 | 1024
       8169 |  512
 -----------+------

Il link nella risposta di David alla RFC tradurrà il numero alg nell'algoritmo attuale.

Victor pubblica regolarmente gli aggiornamenti di questi dati nella dns-operations . Se sei coinvolto in operazioni DNS per la tua organizzazione, ti consiglio vivamente di iscriverti alla lista.

    
risposta data 06.10.2018 - 16:53
fonte

Leggi altre domande sui tag