DNSSEC es un tema ya de por sí complicado, al que se suma la disponibilidad de varios algoritmos de seguridad estándar para firmar registros DNS, definidos por la IANA, que agrega más confusión si cabe. El algoritmo 13 es una variante del algoritmo de firma digital de curva elíptica (ECDSA). Si bien hoy en día lo utilizan menos del 0,01 % de los dominios, nos gustaría subrayar que ECDSA nos ayudó a eliminar las dos últimas barreras para la adopción generalizada de DNSSEC: la enumeración de zonas y la amplificación de DDoS.
Después de leer este artículo podrás:
Copiar el enlace del artículo
DNSSEC es un tema ya de por sí complicado, al que se suma la disponibilidad de varios algoritmos de seguridad estándar para firmar registros DNS, definidos por la IANA, que agrega más confusión si cabe. El algoritmo 13 es una variante del algoritmo de firma digital de curva elíptica (ECDSA). Si bien hoy en día lo utilizan menos del 0,01 % de los dominios, nos gustaría subrayar que ECDSA nos ayudó a eliminar las dos últimas barreras para la adopción generalizada de DNSSEC: la enumeración de zonas y la amplificación de DDoS.La enumeración de zonas se evita mediante la firma en directo, algo que solo es eficiente desde el punto de vista computacional con la generación rápida de firmas de ECDSA. Las curvas elípticas también generan claves y firmas mucho más pequeñas que sus homólogas RSA, lo que significa que las respuestas a las consultas DNS son más breves. Esto reduce en gran medida el factor de amplificación de los ataques DDoS basados en el DNS.
DNSSEC incorpora la denegación de existencia autentificada mediante los registros NSEC y NSEC3. Sin embargo, como comentamos en nuestra página sobre las complejidades y consideraciones del protocolo DNSSEC, tanto NSEC como NSEC3 permiten a los atacantes recorrer la zona. La solución es una ingeniosa técnica llamada "mentiras blancas DNSSEC" (descrita en los RFC 4470 y 4471), pero solo se puede aplicar si los registros DNSSEC se firman sobre la marcha.RSA es el algoritmo de firma más generalizado en DNSSEC, en parte porque es el único algoritmo obligatorio definido por el protocolo. Lamentablemente, la firma en directo con RSA es demasiado costosa.
Los beneficios de rendimiento del algoritmo ECDSA son espectaculares. Generar una firma ECDSA es 10 veces menos costoso en términos computacionales que una firma RSA comparable. Esto hace que la firma en directo (y las mentiras blancas DNSSEC) sean viables, incluso a escala. Durante la versión beta de DNSSEC (con menos de 1 000 dominios firmados), Cloudflare ha estado respondiendo a decenas de miles de consultas de DNSSEC por segundo. Eso supone más de 1 000 millones de consultas al día, y firmamos todos los registros RRSIG necesarios sobre la marcha. Disponer de un algoritmo de firma 10 veces más rápido que el algoritmo RSA marca una gran diferencia cuando se trata de la carga en nuestros servidores DNSSEC. Cuando empezamos a trabajar con ECDSA, la implementación de OpenSSL que utilizábamos estaba en Go. Teniendo en cuenta todas las firmas que hacemos, optimizar la generación de firmas era una prioridad importante. Así que reescribimos la implementación de ECDSA en ensamblado de bajo nivel, y ahora es más de 20 veces más rápido que en Go. Ese código es de código abierto y llegará a Go 1.7 para que toda la comunidad criptográfica pueda aprovechar nuestras optimizaciones. Más información
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. Eso es potencialmente 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.
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 obtener 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.
ECDSA resuelve problemas importantes en DNSSEC, pero la comunidad global de DNSSEC apenas usa este algoritmo. Echemos un breve vistazo a la implementación de ECDSA en la zona DNS raíz y al millón de dominios de Alexa.
En primer lugar, examinamos la zona DNS raíz para ver qué algoritmos DNSSEC emplean los dominios de nivel superior. La siguiente tabla muestra los algoritmos de seguridad especificados por los registros DS en el archivo de la zona raíz:
curl -s http://www.internic.net/domain/root.zone | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
Realizamos un análisis similar para la lista del millón de dominios más visitados de Alexa, que nos da una muestra representativa aceptable del tráfico global de Internet:
| Algoritmo | Número de registros DS firmados |
|---|---|
| 1 (RSA/MD5) | 1 |
| 3 (DSA/SHA1) | 10 |
| 5 (RSA/SHA-1) | 3322 |
| 7 (RSASHA1-NSEC3-SHA1) | 5083 |
| 8 (RSA/SHA-256) | 7003 |
| 10 (RSA/SHA-512) | 201 |
| 13 (Curva ECDSA P-256 con SHA-256) | 23 |
La revelación más sorprendente es que del millón de sitios web, solo 15 643 utilizan el protocolo DNSSEC en cualquier forma. De ese 1,5 %, solo 23 zonas están firmadas con el algoritmo 13. Además, la red de Cloudflare protege más de la mitad de esas zonas de algoritmo 13. Eso significa que menos de una docena de zonas del millón de dominios de Alexa utilizan ECDSA fuera de Cloudflare. Estos datos confirman las conclusiones de Roland van Rijswijk-Deij y otros de que el 99,99 % de los dominios firmados en .com, .net, y .org usan RSA.
Entonces, ¿por qué el uso del algoritmo 13 es tan bajo, sobre todo teniendo en cuenta que resuelve problemas tan importantes en el protocolo DNSSEC? Pues bien, RSA se incorporó a DNSSEC desde los inicios del protocolo. ECDSA es un nuevo algoritmo criptográfico, y los solucionadores, registradores y registros todavía están tratando de entenderlo.
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 cuestión muy importante en todo este debate sobre el algoritmo 13: solo el 1,5 % de las propiedades web admiten DNSSEC en forma alguna. No todos los registradores admiten el protocolo DNSSEC, y agregarlo no es algo menor. 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.