DomainKeys Identified Mail

DomainKeys Identified Mail (DKIM) es un mecanismo de autenticación de correo electrónico que permite a una organización responsabilizarse del envío de un mensaje, de manera que éste pueda ser validado por un destinatario. Dicha organización puede ser una fuente directa del mensaje, como el autor, el servidor encargado de gestionar el correo de ese dominio, o un servidor intermedio situado en el tránsito que recorre dicho correo, como por ejemplo un servicio independiente que provee recursos de correo al servidor que gestiona el dominio principal.

La necesidad de este tipo de autenticación surge por la falsificación de contenidos de las que hace uso el spam. Por ejemplo, un mensaje de spam puede falsear el campo "From:" de las cabeceras de un mensaje diciendo que el origen es usuario@ejemplo.com, cuando realmente no proviene de esa dirección, y el único objetivo del spammer es convencer al destinatario de que acepte y lea el mensaje. Como el mensaje no proviene realmente del dominio usuario@ejemplo.com, quejarse a ese dominio no serviría de nada. Además, resulta complicado por parte de los destinatarios el distinguir cuándo deben confiar o no en un determinado dominio, y los administradores de correo tienen que hacerse cargo de quejas de spam que supuestamente se originan desde su dominio, cuando realmente no es así.

DKIM utiliza criptografía de clave pública para permitir al origen firmar electrónicamente correos electrónicos legítimos de manera que puedan ser verificados por los destinatarios. Entre los proveedores de servicio de correo que implementan ese sistema se encuentran Yahoo, Gmail, y FastMail. Cualquier correo originado desde estas organizaciones deben llevar una firma DKIM.​​​​​

DKIM también protege contra la manipulación de correo electrónico, proporcionando integridad de extremo a extremo, desde un módulo firmante a un módulo validador. En la mayoría de los casos el módulo firmante actúa en nombre de la organización originaria insertando una firma DKIM en las cabeceras del mensaje, y el módulo de comprobación en nombre de la organización del receptor, validando la firma obteniendo la clave pública del firmante a través del DNS.

DKIM, según informa la página principal de la Organización DKIM, es el resultado de la fusión de DomainKeys y de Identified Internet Mail. La especificación de esta fusión ha sido la base de un Grupo de Trabajo IETF que ha producido una serie de especificaciones de estándares y documentos técnicos de soporte.

Resumen

DKIM es un método de autentificación de correo electrónico. A diferencia de otros métodos, ofrece integridad de datos de extremo a extremo, desde un módulo firmante a un módulo validador como por ejemplo un Agente de Transporte de Correo (MTA). En la mayoría de los casos el módulo firmante actúa en nombre de la organización remitente del mensaje, y el módulo validador en nombre de la organización receptora del mensaje. DomainKeys se específica en el RFC 4870, que ha sido actualizado en el RFC 4871, "DomainKeys Identified Mail (DKIM) Signatures" y posteriormente en el RFC 5672, "DomainKeys Identified Mail (DKIM) Signatures -- Update".

DKIM es independiente del protocolo SMTP, actuando en el cuerpo y cabeceras del mensaje (RFC 5322) y no en la conversación SMTP definida en el RFC 5321.

DKIM permite a la entidad firmante distinguir el flujo de su mail legítimo, pero no previene o identifica el comportamiento abusivo. Esta capacidad de distinguir o firmar el correo legítimo tiene beneficios tanto para los destinatarios del correo como para los remitentes. Además, ya hay clientes de correo electrónico que son capaces de hacer uso de ella.

Cómo funciona

DKIM añade una cabecera llamada "DKIM-Signature" que contiene una firma digital del contenido (cabeceras y cuerpo) del mensaje. Los parámetros por defecto del mecanismo de autenticación son la utilización de SHA-256 como la firma criptográfica y RSA como el esquema de criptografía asimétrica. Finalmente se codifica la firma resultante con Base64.

El servidor SMTP utiliza el nombre de dominio perteneciente al emisor, la cadena "_domainkey", y un selector del campo de la firma DKIM para realizar una consulta al DNS. La respuesta debe incluir la clave pública del dominio. El receptor puede utilizar esta información para descifrar el valor de la firma del campo de la cabecera, y al mismo tiempo, recalcular el valor de la firma para el mensaje (cabeceras y cuerpo) que ha recibido. Si los dos resultados coinciden, esto prueba criptográficamente que el mensaje fue firmado por el dominio indicado y que no ha sido alterado en tránsito.

Un fallo en la verificación de la firma no fuerza el rechazo del mensaje. En cambio, las razones precisas por las cuales la autenticidad del mensaje no ha podido ser verificada deberían comunicarse tanto al proceso de envío como el de recepción. Los métodos para llevar a cabo esta misión podrían ser enviar un mensaje FBL, o añadir una cabecera de Authentication-Results al mensaje tal y como se describe en el RFC 5451.

Desarrollo

DomainKeys fue diseñado por Mark Delany, de Yahoo!, y mejorado mediante los comentarios de mucha otra gente.

DKIM fue inicialmente desarrollado por un consorcio formado por un grupo de industria informal y posteriormente se presentó para mejorar y estandarizar por el Grupo de Trabajo DKIM de la IETF, presidido por Barry Leiba y Stephen Farrell, con Eric Allman de sendmail, Jon Callas de la Corporación PGP, Mark Delany y Miles Libbey de Yahoo!, y Jim Fenton y Michael Thomas de Cisco Systems a los que se les atribuye la autoría principal.

DomainKeys está cubierto por la Patente USPTO n.º 6986049 asignada a Yahoo!, que ha liberado DomainKeys bajo una licencia dual: la licencia tradicional orientada a empresas libre de regalías, no exclusiva y relicenciable, diseñada para complementarse bien con las implementaciones de software libre y código abierto, y también bajo GPL 2.0 para llevar a cabo el propósito del Grupo de Trabajo DKIM de la IETF.

Ventajas

La principal ventaja de este sistema para los receptores de correo electrónico es que permite firmar el dominio de manera que se puede identificar de manera fiable el flujo de correo legítimo, lo que permite que la utilización de listas blancas o negras basadas en dominio sean mucho más efectivas.

Hay algunas ventajas para el que envía correo al firmarlo con DKIM:

• Permite reducir drásticamente la falsificación de dominios de origen del mensaje, ya que podremos identificar perfectamente aquellos mensajes de correo electrónico que hayan sido firmados si su dominio tiene el DKIM habilitado.
• El poseedor del dominio puede centrar sus esfuerzos para evitar el abuso reduciendo el ámbito de uso inapropiado de ese dominio a sus mismos usuarios.

Utilizado en conjunto con el filtrado de spam

DKIM es una tecnología de autenticación, y no identifica o filtra el spam por sí mismo. Sin embargo, el uso generalizado de DKIM puede evitar que los spammers falsear la dirección de origen de sus mensajes, una técnica que emplean habitualmente.

Si los spammers se ven obligados a utilizar un dominio de origen correcto, las técnicas de filtrado de spam podrán trabajar más eficazmente.

En particular, el dominio de origen, puedan introducirse en un sistema de reputación para identificar mejor el spam.

Por el contrario, DKIM puede hacer que sea más fácil identificar el correo que sabemos que no es spam y por tanto no necesita ser filtrado. Si un sistema de recepción de correo tiene una lista blanca de dominios que envían correo lícito, ya sea local o mantenida por una tercera parte certificadora, puede saltarse el filtro de correo electrónico firmado desde esos dominios, y entonces filtrar el correo electrónico restante de manera más agresiva.​

DKIM puede ser útil como una tecnología anti-phishing. Los servidores de correo salientes de los dominios que sufren más ataques de phishing pueden firmar su correo para demostrar que es lícito. Los destinatarios pueden asociar la ausencia de firma en el correo de estos dominios como una indicación de que el correo es probablemente falso. La mejor manera de determinar el conjunto de dominios que merecen este grado de control sigue siendo una cuestión abierta; DKIM, probablemente tendrá una función opcional llamada ADSP que permite a los emisores que firman todos sus correos el auto-identificarse, pero la eficacia de este enfoque está siendo sometida a prueba.​ ​

Compatibilidad

Dado que DKIM se implementa utilizando registros DNS y una cabecera de correo compatible con el RFC 5322, es totalmente compatible con la infraestructura de correo existente. En particular, es transparente con los sistemas de correo actuales que no implementan el soporte DKIM.

Este enfoque es también compatible con otros servicios relacionados, tales como el S/MIME y OpenPGP, estándares en la protección del contenido. DKIM es ortogonal y compatible con el estándar DNSSEC y con SPF.

Debilidades

Las firmas DKIM no abarcan todo el mensaje, deja fuera el return-path y los destinatarios del mensaje. Una preocupación para cualquier solución criptográfica sería el abuso en el envío de mensajes repetidos, que se saltaría las técnicas que actualmente limitan el nivel de abuso para grandes dominios. La repetición puede detectarse utilizando claves públicas por mensaje, haciendo consultas DNS para esas claves y filtrando aquellas consultas masivas producidas por correos enviados a listas de correo enormes o consultas maliciosas producidas por terceros.

Se puede ver una comparación de diferentes métodos que tratan este problema en e-mail authentication.

Reenvío arbitrario

Como se mencionaba antes, autenticación no es lo mismo que prevención del abuso: DKIM no previene el que un spammer cree un anuncio desde un dominio de buena reputación y se envíe a sí mismo el mensaje. Este mensaje firmado puede utilizarse entonces para reenviarse a millones de destinatarios, por ejemplo a través de un botnet sin ningún tipo de control. El proveedor que firmó el mensaje puede bloquear al usuario infractor, pero no puede parar la difusión de los mensajes ya firmados.

Modificación de contenido en tránsito

Uno de los problemas asociados a DKIM es que si el mensaje es modificado significativamente en su camino hacia el destinatario por cualquier agente de transmisión, como por ejemplo un servidor de listas, la firma DKIM deja de ser válida, y si en el dominio se especifica que todos los correos electrónicos deben ir firmados, el mensaje puede ser rechazado. Muchas soluciones de antivirus añaden un pie en el cuerpo del mensaje indicando que el correo ha sido escaneado y la fecha de las firmas de virus utilizadas en la exploración. Además, algunos servidores de correo electrónico gratuito añaden anuncios en la parte inferior del mensaje. La solución es crear una lista blanca de correo electrónico para los dominios conocidos, o la máquina que hace el reenvío debería comprobar la firma, modificar el correo, y volver a firmar el mensaje con una cabecera Sender. Sin embargo, cabe señalar que esta solución tiene riesgos si el servidor SMTP de destino soporta el protocolo ADSP.

Muchos dominios, en cambio, establecen que sólo algunos de sus correos van firmados, y por tanto una firma inválida o inexistente no debe ser razón para rechazar el correo. La solución aquí pasa por firmar todo tu correo. Si la única modificación en el camino que recorre el mensaje son el añadido o modificación de cabeceras, la firma seguirá siendo válida; además el mecanismo incluye características que permiten que sean hechas determinadas modificaciones a las cabeceras y el cuerpo del mensaje sin que esto invalide la autenticidad de la firma.

Algunos sugieren que esta limitación podría ser solventada combinando DKIM con SPF, ya que SPF (que deja de ser válido cuando los mensajes son reenviados) es inmune a las modificaciones de los datos del correo, y las listas de correo suelen utilizar sus propias direcciones de error SMTP, también conocidas como Return-Path. Resumiendo, SPF funciona sin problemas donde DKIM tiene dificultades, y viceversa.

Las listas de correo que añaden o cambian contenido también invalidan las firmas DKIM. Yahoo! sugirió que las listas de correo deberían volver a firmar los mensajes en estas circunstancias, haciéndose así responsables del mensaje.

Coste computacional del protocolo

DKIM genera checksums criptográficos para cada mensaje original enviado a través de sus servidores, lo que resulta en una sobrecoste computacional adicional al hacer el envío de correo. Si bien esto pudo ser un punto importante a la fecha de su presentación, el aumento en el poder de cómputo que ha tenido lugar en la última década y el aumento de hardware de asistencia criptográfica como parte de los sistemas estándar han reducido el impacto que DKIM pueda tener en la capacidad de procesamiento de un servidor.

Véase también

• DomainKeys
• Sender Policy Framework (SPF)
• S/MIME
• OpenPGP

Enlaces externos

• Domain Keys Identified Mail (DKIM)
• IETF DKIM working group (iniciado en 2006)

Especificaciones DKIM

• RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
• RFC 4871 DomainKeys Identified Mail (DKIM) Signatures
• RFC 5617 DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
• RFC 5585 DomainKeys Identified Mail (DKIM) Service Overview

Información y herramientas de DKIM

• Internet Messaging Leaders Work Together to Fight Email Fraud
• DKIM Software and Services Deployment Reports
• DKIM-Connector (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). Tool to simplify DKIM deployment
• DKIM installation for Exim (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). Tutorial for installing DKIM for outbound messages using Exim
• DomainKeys on cPanel Implementing DomainKeys on a cPanel powered server
• Domain Keys Identified Mail (DKIM) Archivado el 6 de diciembre de 2009 en Wayback Machine.
• DKIM signer/verifier drop-in replacement for qmail-queue
• Domain Keys Identified Mail (DKIM) DNS Record Generator
• Crocker, Dave (marzo de 2008), Trust in Email Begins With Authentication (PDF), Messaging Anti-Abuse Working Group, archivado desde el original el 6 de febrero de 2009, consultado el 9 de diciembre de 2009 .

• Datos: Q2605645