← RFC Reference

RFC 8463: Ed25519 para firmas DKIM

Por qué existe

DKIM (RFC 6376) originalmente especificaba solo RSA para firmas. RSA ha funcionado bien, pero tiene costos:

• Claves grandes. Una clave pública RSA de 2048 bits tiene aproximadamente 400 bytes codificados en Base64. Los registros TXT de DNS tienen un límite práctico de alrededor de 255 bytes por cadena (con la mayoría de resolvedores que admiten hasta aproximadamente 4096 bytes en total), lo que hace que las claves RSA grandes sean engorrosas y a veces frágiles en DNS.
• Verificación lenta. La verificación de firma RSA, especialmente con claves más grandes, consume tiempo de CPU medible cuando un receptor procesa millones de mensajes por hora.
• Escalada del tamaño de clave. La seguridad de RSA depende de la longitud de la clave. A medida que crece la potencia computacional, las claves de 2048 bits eventualmente necesitarán convertirse en 3072 o 4096 bits, empeorando el problema de DNS.

Ed25519 (Algoritmo de Firma de Curva de Edwards usando Curve25519) resuelve los tres problemas. Sus claves de 256 bits proporcionan seguridad equivalente a aproximadamente RSA de 3072 bits, la clave pública tiene solo 32 bytes (44 caracteres Base64), y la verificación es significativamente más rápida.

Cómo funciona

Firma con Ed25519

El proceso de firma es idéntico a DKIM estándar, con dos cambios: la etiqueta a= usa ed25519-sha256 en lugar de rsa-sha256, y la clave privada es una clave Ed25519 en lugar de RSA.

1. Canonicalizar encabezados y cuerpo según las reglas de RFC 6376.
2. Calcular el hash SHA-256 del cuerpo canonicalizado (etiqueta bh=).
3. Calcular el hash SHA-256 de los encabezados firmados más el hash del cuerpo.
4. Firmar el hash del encabezado usando la clave privada Ed25519.
5. Emitir el encabezado DKIM-Signature con a=ed25519-sha256.

Ejemplo: DKIM-Signature de Ed25519

Registro de clave pública de DNS

El registro de clave usa k=ed25519 y la clave pública es dramáticamente más pequeña que RSA:

Firma dual: el enfoque recomendado

No todos los receptores admiten Ed25519 aún. RFC 8463 recomienda firma dual: aplicar tanto una firma RSA como una firma Ed25519 a cada mensaje. Los receptores que entienden Ed25519 pueden verificar la firma más fuerte; los que no la entienden recurrirán a la firma RSA.

Ambas firmas comparten el mismo bh= (hash del cuerpo) y h= (encabezados firmados) pero usan selectores diferentes que apuntan a tipos de clave diferentes en DNS.

Detalles técnicos clave

Comparación del tamaño de clave

Generación de clave

Formato de registro de DNS

El único cambio respecto a un registro de clave DKIM estándar es k=ed25519. Todas las demás etiquetas (v=, p=, t=, etc.) funcionan igual que con registros de clave RSA:

Comportamiento del receptor

Cuando un receptor encuentra a=ed25519-sha256 en un DKIM-Signature:

1. Buscar el registro de clave DNS para el selector.
2. Confirmar k=ed25519 en el registro de clave.
3. Decodificar la clave pública de 32 bytes de la etiqueta p=.
4. Verificar la firma Ed25519 contra el hash SHA-256 de los encabezados canonicalizados.

Si el receptor no admite Ed25519, trata la firma como no verificable (no un error grave) y continúa con cualquier otro encabezado DKIM-Signature en el mensaje.

Errores comunes

• Desplegar solo Ed25519 sin firma dual. Muchos receptores aún no verifican firmas Ed25519. Eliminar RSA significa que esos receptores no ven ninguna firma DKIM válida, lo que afecta la alineación de DMARC y la entrega.
• Extracción incorrecta de clave. Las claves públicas Ed25519 en formato PEM incluyen un prefijo ASN.1. El valor p= de DNS debe ser la clave sin formato de 32 bytes, no la SubjectPublicKeyInfo codificada en DER completa. Hacerlo mal produce una clave que parece válida pero falla en la verificación.
• Usar una versión antigua de OpenSSL. La compatibilidad con Ed25519 se agregó en OpenSSL 1.1.1 (septiembre de 2018). Las versiones anteriores no pueden generar ni verificar claves Ed25519. Muchas distribuciones de Linux enviaban OpenSSL más antiguo bien entrada en 2020.
• Asumir que Ed25519 reemplaza a RSA hoy. Ed25519 es la dirección futura, pero RSA sigue siendo la línea base que todos los verificadores DKIM entienden. Plan para firma dual durante al menos los próximos años.
• No probar la verificación. Después de publicar el registro DNS, enviar mensajes de prueba y verificar que ambas firmas se validen. Herramientas como opendkim-testkey pueden verificar el registro DNS de forma independiente.
• Compartir selectores entre tipos de clave. Usar selectores distintos para claves RSA y Ed25519. Un selector solo puede apuntar a un tipo de clave. Intentar sobrecargar un único selector causa fallos de verificación.

Impacto en la entregabilidad

• Menor huella en DNS. Las claves Ed25519 caben trivialmente en registros TXT de DNS, eliminando problemas de fragmentación que a veces afectan claves RSA grandes. Menos fallos de DKIM relacionados con DNS significa autenticación más consistente.
• Preparación para el futuro. A medida que los tamaños de clave RSA necesitan crecer (2048 → 3072 → 4096), el problema de DNS empeora. Ed25519 proporciona seguridad más fuerte sin escalada del tamaño de clave.
• Verificación más rápida a escala. Para receptores de alto volumen que procesan miles de millones de mensajes, la verificación Ed25519 es notablemente más rápida que RSA. Esto beneficia al ecosistema reduciendo el costo computacional de la autenticación.
• Demuestra madurez en seguridad. Desplegar firma dual Ed25519 muestra que un remitente mantiene activamente su infraestructura de autenticación. Si bien esto no es un factor de puntuación directo, refleja madurez operativa que se correlaciona con buenas prácticas de envío.
• Firma dual como red de seguridad. Con dos firmas independientes, un mensaje tiene dos oportunidades de pasar la verificación de DKIM. Si una firma se rompe debido a la modificación de mensaje intermedia, la otra puede sobrevivir.

Related RFCs