O que são comprimentos de chave aceitáveis para o DNSSEC KSK / ZSK?

Question

Recebi a tarefa de investigar a implementação do DNSSEC em nossos servidores de nomes. Embora o lado técnico disso (gerar chaves, assinar zonas, preparar sobreposições) seja relativamente simples, enfrentei um problema logístico.

A partir da documentação que estou lendo, 1024 bits têm um bom tamanho para uma chave de assinatura de zona, e o procedimento adequado seria um ZSK para cada zona com uma sobreposição de um mês

No entanto, leva até 10 minutos em um computador razoavelmente rápido com entropia decente para gerar uma chave de 1024 bits ... E o ISP eu trabalho para hosts com mais de três mil zonas. A menos que, de alguma forma, eu automatize o processo do início ao fim, isso não será viável - e, mesmo se eu o fizer, quando o processo terminar, já é quase hora de começar com a próxima rolagem.

Em suma, isso não é viável. No momento, estou restringindo o DNSSEC a clientes que pedem isso explicitamente, mas isso é o melhor possível.

Minhas perguntas:

• Eu estou indo ao mar com o tamanho da chave?
• Como posso acelerar o processo de geração de chaves?
• Devo criar chaves individuais de assinatura de chave para cada zona, bem como ZSKs?

EDIT: Adicionado os comandos exatos que estou usando para gerar as chaves:

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256 -f KSK -b 1280 -n ZONE example.com 
Generating key pair.............................+++++ ...+++++ 
Kexample.com.+008+10282

real    9m46.094s
user    0m0.092s
sys 0m0.140s

caleburn: ~/Projects/Systemec/DNS-magic/DNSSEC/keys/ >time dnssec-keygen -r/dev/random -a RSASHA256  -b 1280 -n ZONE example.com 
Generating key pair.........................+++++ .........+++++ 
Kexample.com.+008+22173

real    12m47.739s
user    0m0.124s
sys 0m0.076s

    

Answer 1

dnssec-keygen lê /dev/random por padrão. Se a entropia no seu sistema for baixa, você não obterá dados aleatórios suficientes para gerar as chaves em tempo hábil. A Strace provavelmente mostrará muitas coisas como:

select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "5%6713", 46)  = 8
read(3, 0x7fff5b6c3df0, 38)             = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "51c31", 38) = 8
read(3, 0x7fff5b6c3df0, 30)             = -1 EAGAIN (Resource temporarily unavailable)

/dev/random bloqueia se não houver entropia suficiente, por isso pode demorar um pouco.

Você tem algumas opções para fazer isso muito mais rápido. O mais fácil é usar a alteração -r /dev/random to -r /dev/urandom para usar o gerador de números aleatórios sem bloqueio (mas não tão seguro). Isso pode não ser considerado seguro para algo como uma chave GPG ou SSH que você esperaria usar por vários anos, mas provavelmente é seguro que algo seja alterado a cada 30 dias.

Outra opção é usar algo como EGD ou possuía como um substituto para /dev/random .

Se você deseja um RNG muito mais seguro, é melhor usar um RNG de hardware dedicado. Estes são provavelmente um exagero para o DNSSEC, a menos que você esteja gerenciando TLDs ou domínios bancários.

Você pode querer ficar com / dev / random para o KSK, mas / dev / urandom deve ser bom para os ZSKs.

    

Answer 2

Acho que o consenso geral é que o seu ZSK deve ser de 1024 bits e ser distribuído a cada trimestre e o seu KSK deve ser de 2048 bits e ser distribuído a cada dois anos.