Correo electrónico identificado por DomainKeys

DomainKeys estaba protegido por la patente estadounidense 6,986,049 , ahora vencida. Yahoo! licenció sus reivindicaciones de patente bajo un esquema de licencia dual: el Acuerdo ^de Licencia de Patentes de DomainKeys v1.2 [ ^{9 ]} o la Licencia Pública General GNU v2.0 (y ninguna otra versión) . ^{[ 10 ] [ 11 ]}

En esencia, tanto DKIM como SPF proporcionan diferentes medidas de autenticidad del correo electrónico. DMARC permite a una organización publicar una política que especifica qué mecanismo (DKIM, SPF o ambos) se emplea al enviar correos electrónicos desde ese dominio; cómo verificar el From:campo que se muestra a los usuarios finales; cómo debe el receptor gestionar los fallos, y un mecanismo de informes para las acciones realizadas conforme a dichas políticas. ^{[ 12 ]}

DKIM es un método para etiquetar mensajes y no filtra ni identifica el spam por sí mismo. Sin embargo, su uso generalizado puede impedir que los spammers falsifiquen la dirección de origen de sus mensajes, una técnica que emplean habitualmente. Si se obliga a los spammers a mostrar un dominio de origen correcto, otras técnicas de filtrado pueden ser más eficaces. En particular, el dominio de origen puede incorporarse a un sistema de reputación para identificar mejor el spam. Por otro lado, DKIM facilita la identificación de correos que se sabe que no son spam y que, por lo tanto, no necesitan ser filtrados. Si un sistema receptor dispone de una lista blanca de dominios de envío legítimos, ya sea gestionada localmente o por certificadores externos, puede omitir el filtrado de correos firmados procedentes de esos dominios y, posiblemente, filtrar el resto de los correos de forma más rigurosa. ^{[ 13 ]}

DKIM puede ser útil como tecnología antiphishing . Los remitentes de correo en dominios con alta incidencia de phishing pueden firmar sus correos para demostrar su autenticidad. Los destinatarios pueden interpretar la ausencia de una firma válida en correos de esos dominios como una señal de que probablemente se trate de un correo falsificado. La mejor manera de determinar qué dominios merecen este nivel de escrutinio sigue siendo una incógnita. DKIM solía tener una función opcional llamada ADSP que permitía a los autores que firmaban todos sus correos identificarse, pero fue relegada a estado histórico en noviembre de 2013. ^{[ 14 ]} En su lugar, se puede utilizar DMARC para el mismo propósito ^{[ 15 ]} y permite a los dominios autopublicar las técnicas (incluidas SPF y DKIM) que emplean, lo que facilita al receptor tomar una decisión informada sobre si un correo determinado es spam o no. ^{[ 16 ]} Por ejemplo, utilizando DMARC, eBay y PayPal publican políticas que establecen que todo su correo está autenticado y solicitan que cualquier sistema receptor, como Gmail , rechace cualquier correo que no lo esté. ^{[ 17 ]}

Debido a que se implementa utilizando registros DNS y un campo de encabezado RFC 5322 adicional, DKIM es compatible con la infraestructura de correo electrónico existente. En particular, es transparente para los sistemas de correo electrónico existentes que carecen de soporte para DKIM. ^{[ 18 ]}

Este enfoque de diseño también es compatible con otros servicios relacionados, como los estándares de protección de contenido S/MIME y OpenPGP . DKIM es compatible con el estándar DNSSEC y con SPF .

DKIM requiere que se generen sumas de verificación criptográficas para cada mensaje enviado a través de un servidor de correo, lo que resulta en una sobrecarga computacional que no se requiere para la entrega de correo electrónico. Esta sobrecarga computacional adicional es un sello distintivo de los sellos postales digitales, lo que hace que el envío masivo de spam sea más costoso (computacionalmente). ^{[ 19 ]} Esta faceta de DKIM puede parecer similar a hashcash , excepto que la verificación del lado del receptor es una cantidad insignificante de trabajo, mientras que un algoritmo típico de hashcash requeriría mucho más trabajo.

La función de no repudio de DKIM impide que los remitentes (como los spammers) nieguen de forma creíble haber enviado un correo electrónico. Ha resultado útil para medios de comunicación como WikiLeaks , que ha podido aprovechar las firmas del cuerpo de DKIM para demostrar que los correos electrónicos filtrados eran auténticos y no habían sido manipulados. ^{[ 20 ]} En la práctica, es difícil verificar muchos correos electrónicos antiguos debido a la rotación de claves y a la dificultad de encontrar las claves originales antes de la rotación, ya que no se publican en ningún sitio. Una forma de verificar correos electrónicos antiguos es utilizar archivos que recopilan firmas y selectores de correos electrónicos existentes y que pueden recuperar claves públicas caducadas a partir de pares de firmas realizadas con la misma clave. ^{[ 21 ]}

Matthew D. Green considera que la no repudiación es una característica no deseada de DKIM, impuesta por comportamientos como los descritos anteriormente. De hecho, el protocolo DKIM contempla la caducidad. Cada firma incluye una etiqueta "x" opcional que establece un tiempo de caducidad formal; sin embargo, los verificadores pueden ignorarla. Además, los propietarios de dominios pueden revocar una clave pública eliminando sus datos criptográficos del registro, lo que impide la verificación de la firma a menos que alguien haya guardado previamente los datos de la clave pública. La rotación de claves DKIM se suele recomendar para minimizar el impacto de las claves comprometidas. Sin embargo, para deshabilitar definitivamente la no repudiación, se pueden publicar claves secretas caducadas, lo que permite a cualquiera generar firmas falsas, invalidando así la validez de las originales. ^{[ 22 ] [ 23 ] [ 24 ]}

Por defecto, la publicación de un correo electrónico censurado no es verificable porque no se pueden construir los hashes del cuerpo DKIM. Sin embargo, aún se pueden verificar dichos correos electrónicos si el propietario crea una prueba de conocimiento cero de la firma DKIM en un subconjunto enmascarado de encabezados o texto del cuerpo, mientras que restringe las partes divulgadas para que coincidan con el mensaje firmado. Las implementaciones a menudo usan expresiones regulares o enmascaramiento para ocultar o mostrar contenido seleccionado. Esta prueba se puede proporcionar en lugar de una firma DKIM a terceros para que cualquiera pueda verificar la validez del correo electrónico. ^{[ 25 ]} Estas pruebas incluso se pueden generar localmente en el dispositivo de un usuario, de modo que la información censurada nunca se envíe a terceros. Se puede usar para crear foros de mensajes anónimos seguros con identidades privadas pero afiliaciones verificadas, como un Blind totalmente privado. También se puede usar cuando se necesita autenticar la afirmación de un remitente, pero el destinatario quiere permanecer anónimo.

Como se mencionó anteriormente, la autenticación no es lo mismo que la prevención de abusos. Un usuario malintencionado de correo electrónico de un dominio de buena reputación puede redactar un mensaje malicioso, firmarlo con DKIM y enviarlo desde ese dominio a cualquier buzón de correo desde donde pueda recuperarlo como un archivo, para así obtener una copia firmada del mensaje. El uso de la etiqueta `l` en las firmas facilita aún más la manipulación de dichos mensajes. La copia firmada puede reenviarse a millones de destinatarios, por ejemplo, a través de una botnet , sin control alguno. El proveedor de correo electrónico que firmó el mensaje puede bloquear al usuario infractor, pero no puede detener la difusión de mensajes ya firmados. La validez de las firmas en dichos mensajes puede limitarse incluyendo siempre una etiqueta de tiempo de expiración en las firmas, o revocando una clave pública periódicamente o tras la notificación de un incidente. La eficacia de este escenario difícilmente puede limitarse filtrando el correo saliente, ya que esto implica la capacidad de detectar si un mensaje podría ser potencialmente útil para los spammers. ^{[ 28 ]}

Actualmente, DKIM cuenta con dos algoritmos de canonización , simple y relajado , ninguno de los cuales es consciente de MIME . ^{[ 29 ]} Los servidores de correo pueden convertir legítimamente a un conjunto de caracteres diferente y, a menudo, documentan esto con campos de encabezado. Además, en ciertas circunstancias, los servidores tienen que reescribir la estructura MIME, alterando así el preámbulo , el epílogo y los límites de las entidades, cualquiera de los cuales rompe las firmas DKIM. Solo los mensajes de texto plano escritos en us-ascii , siempre que los campos de encabezado MIME no estén firmados, ^{[ 30 ]} gozan de la robustez que requiere la integridad de extremo a extremo.X-MIME-Autoconverted:

El proyecto OpenDKIM organizó una recopilación de datos que involucró a 21 servidores de correo y millones de mensajes. El 92,3 % de las firmas observadas se verificaron correctamente, una tasa de éxito que disminuye ligeramente (90,5 %) cuando solo se considera el tráfico de listas de correo. ^{[ 31 ]}

En octubre de 2012, Wired informó que el matemático Zach Harris detectó y demostró una vulnerabilidad de suplantación de identidad de correo electrónico con claves DKIM cortas para el google.comdominio corporativo, así como para otros dominios de alto perfil. Afirmó que la autenticación con claves de 384 bits se puede vulnerar en tan solo 24 horas "en mi portátil", y las claves de 512 bits, en aproximadamente 72 horas con recursos de computación en la nube. Harris descubrió que muchas organizaciones firman correos electrónicos con claves tan cortas; las vulneró todas y notificó a las organizaciones sobre la vulnerabilidad. Afirma que las claves de 768 bits podrían vulnerarse con acceso a una gran capacidad de procesamiento, por lo que sugiere que la firma DKIM debería utilizar claves de más de 1024 bits.

Wired afirmó que Harris informó, y Google confirmó, que comenzaron a usar claves más largas poco después de su revelación. Según la RFC 6376, la parte receptora debe poder validar firmas con claves que oscilen entre 512 y 2048 bits; por lo tanto, el uso de claves más cortas de 512 bits podría ser incompatible y debe evitarse. La RFC 6376 también establece que los firmantes deben usar claves de al menos 1024 bits para claves de larga duración, aunque no se especifica la duración. ^{[ 36 ]}

El protocolo DomainKeys original fue diseñado por Mark Delany de Yahoo! y mejorado gracias a los comentarios de muchos otros desde 2004. Está especificado en el RFC histórico 4870, reemplazado por el RFC estándar 4871, Firmas de correo identificado por DomainKeys (DKIM); ambos publicados en mayo de 2007. Posteriormente, se recopilaron varias aclaraciones y conceptualizaciones, que se especificaron en el RFC 5672, de agosto de 2009, en forma de correcciones a la especificación existente. En septiembre de 2011, el RFC 6376 fusionó y actualizó estos dos últimos documentos, conservando la esencia del protocolo DKIM. También es posible la compatibilidad de clave pública con la versión anterior de DomainKeys.

DKIM fue creado inicialmente por un consorcio informal de la industria y posteriormente fue presentado para su mejora y estandarización al Grupo de Trabajo DKIM de la IETF , presidido por Barry Leiba y Stephen Farrell, con Eric Allman de sendmail , Jon Callas de PGP Corporation , Mark Delany y Miles Libbey de Yahoo !, y Jim Fenton y Michael Thomas de Cisco Systems como autores principales.

El desarrollo del código fuente de una biblioteca común está liderado por The OpenDKIM Project , siguiendo las adiciones de protocolo más recientes y bajo la licencia New BSD License . ^{[ 53 ]}