ECDSA: la pieza que faltaba en DNSSEC

Cloudflare es el mayor proveedor de DNS administrado del mundo. Lo que realmente no queremos es convertir nuestros servidores DNSSEC en un vector de amplificación de ataques de denegación de servicio distribuidos (DDoS). Cada vez que solicitas un registro a un servidor DNSSEC, este también devuelve la firma asociada a ese registro, así como la clave pública utilizada para verificar esa firma. Hablamos de mucha información.

Hacer que el tamaño de la respuesta de las consultas DNSSEC sea lo más corto posible es un requisito importante para evitar el abuso de nuestra infraestructura DNS por parte de posibles atacantes. El tamaño reducido de las claves y firmas ECDSA contribuye en gran medida a este fin.

Conseguir una seguridad de 128 bits con ECDSA requiere una clave de 256 bits, mientras que una clave RSA comparable sería de 3 072 bits. Eso supone un factor de amplificación 12 veces mayor solo con las claves. Para más información sobre por qué las claves criptográficas tienen diferentes tamaños, consulta esta publicación del blog.

Sin embargo, la mayoría de las claves RSA no son de 3 072 bits, por lo que un factor de amplificación de 12 veces puede que no sea la cifra más realista. Veamos el peor escenario real para la amplificación de DDoS, que es una respuesta negativa (registro NSEC). Para un dominio en Cloudflare (que utiliza firmas ECDSA y las mentiras blancas DNSSEC), una respuesta DNSSEC típica es de 377 bytes. Compáralo con los 1 075 bytes de un dominio que no utilice ECDSA o las mentiras blancas DNSSEC.

Si tenemos en cuenta que todas las demás implementaciones de DNSSEC a gran escala se basan en firmas RSA, resulta poco atractivo para un atacante aprovechar nuestra infraestructura de DNSSEC como vector de DDoS.

El algoritmo ECDSA no está exento de inconvenientes. Según Roland van Rijswijk-Deij y otros., solo el 80 % de los solucionadores admiten la validación ECDSA. Este número está creciendo, pero significa que si cambiáramos todo Internet de DNSSEC a ECDSA ahora mismo, la validación de DNSSEC fallaría para millones de usuarios de Internet todos los días y volvería a devolver registros DNS no verificados.

Además, aunque la creación de la firma ECDSA es más rápida que la de RSA, la validación de la firma es en realidad mucho más lenta. Roland van Rijswijk-Deij y otros demostraron que, incluso con las optimizaciones de ECDSA que aportamos a OpenSSL, ECDSA sigue siendo 6,6 veces más lento que RSA de 1 024 bits (que es el algoritmo más utilizado para la firma de claves de zonas). Se trata de un problema grave porque la sobrecarga de los solucionadores de DNS podría ralentizar potencialmente toda la red pública de Internet.

Hay una salvedad muy importante en todo este debate sobre el algoritmo 13, y es que solo el 1,5 % de las propiedades web admiten DNSSEC en forma alguna. No todos los registradores admiten el protocolo DNSSEC, y añadirlo no es baladí. Tienen que permitir que sus usuarios carguen registros DS, y, a su vez, el registrador debe subir al registro. Estamos trabajando para que sea un proceso automatizado, de modo que el solicitante del registro ni siquiera tenga que subir el registro DS, pero aún se necesitará la intervención del registrador.

La buena noticia es que vamos en la dirección correcta. En los últimos 12 meses, el protocolo DNSSEC ha crecido de forma exponencial. Además, en las tres semanas transcurridas entre la versión beta pública del DNSSEC y el anuncio de Universal DNSSEC, Hover, OVH, Metaname, Internet.bs, y el registro .NZ han admitido el algoritmo 13.

Creemos que DNSSEC es una tecnología esencial para la web moderna y que ECDSA hace que la adopción global del protocolo DNSSEC sea una posibilidad real. Esperemos seguir viendo a registradores y registros, grandes y pequeños, admitir el algoritmo 13.