Este artículo es parte de la serie “RFCs de IETF” que en forma periódica comentará en idioma español los últimos RFCs publicados, en especial los que tienen relevancia con la operación de TLDs, DNS y dominios.

http://www.rfc-editor.org/rfc/rfc6944.txt

Pese a que es desde hace sólo un par de años que DNSSEC comenzó su despertar a nivel de producción mundial, principalmente con la firma de la raíz del DNS -influenciado a su vez por los nuevos ataques que aparecieron al protocolo-, los RFC de DNSSEC tienen 8 años de publicados. La criptografía también tiene sus propios plazos y épocas de validez. Un algoritmo que era seguro hace 5 años, hoy puede que ya no lo sea, tanto porque se le encontró una vulnerabilidad en implementación, como porque el avance en el poder computacional ha hecho más probable un ataque de fuerza bruta. Por una u otra razón, es necesario ir revisando de tiempo en tiempo la validez y fortaleza criptográfica de los algoritmos.

Por ejemplo, el organismo gubernamental estadounidense NIST genera un informe periódico indicando qué algoritmos considera seguros, cuáles no deben usarse más, y por cuánto tiempo se estima que permanezcan seguros, para programar con tiempo las migraciones. (“Federal Information Processing Standart 180-4, Secure Hash Standard” http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf formato PDF, en inglés).

Cada vez que la IETF crea un nuevo protocolo, le encarga a IANA la mantención de los registros con los códigos especiales que necesitan de una centralización. Es así como IANA mantiene en su sitio los RRs válidos en DNS, los RCODES que retornan los servidores ante consultas, y en particular los algoritmos válidos en el campo “algorithm” del resource record DNSKEY:

http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml

IANA es el encargado de la publicación y administración de ese registro, pero los datos que están ahí están bajo el control de la IETF, quien necesita de un RFC para actualizarlos.

Hasta este momento (junio de 2013) esa tabla lista los códigos permitidos, donde por ejemplo tenemos que el número “5” corresponde a “RSA/SHA1”, descrito en el RFC3110, y que indica que las firmas que realiza una llave está realizada con el sistema de llave pública RSA, y la firma es calculada con el hash SHA1.

Lo que el RFC6944 agrega es una nueva columna en esa tabla, que indica el “estatus de implementación” de cada algoritmo. Así, cada fila de esa columna tendrá asociado los estados “Must implement”, “Must not implement”, “Recommended to implement” y “Optional”. Estos campos indican a cada implementador de DNSSEC (los fabricantes de software de firma, manejadores de llaves, y resolvers/autoritativos de DNS) qué algoritmos debe implementar, cuáles dejar de utilizar, y cuáles son opcionales. El RFC6944 aprovecha de establecer el estado de cada algoritmo actual, y por ejemplo el número 1 “RSAMD5” será movido a “no se debe implementar”, siguiendo las recomendaciones de dejar de utilizar MD5 por sus reconocidas debilidades con colisiones de hash (http://es.wikipedia.org/wiki/MD5#Seguridad)