Cuando hablamos de "autenticación de correo electrónico", nos referimos a una técnica que proporciona al destinatario de un mensaje cierto nivel de certeza de que el mensaje se originó realmente en la supuesta fuente del mensaje. La idea detrás de estas técnicas es lograr cierto nivel de defensa contra el correo electrónico fraudulento, como el phishing y el spoofing, correo que podría erosionar la confianza del destinatario en la recepción de correo electrónico. Dicho esto, el acto de enviar correo electrónico autenticado no afirma que el correo electrónico sea bueno o deseado; sólo significa que el correo es tal que puede establecerse de forma fiable una reputación para la parte autenticada y utilizarse en las decisiones de aceptación y colocación del correo electrónico.

En la actualidad se utilizan dos formas de autenticación del correo electrónico:

• Sender Policy Framework (FPS)

• Correo identificado por claves de dominio (DKIM)

En el artículo de hoy, explicaré qué es DKIM y cómo funciona.

Visión general de DKIM

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

Mi objetivo con este post es que aprenda y comprenda los siguientes conceptos sobre DKIM:

• DKIM es una autenticación "basada en el contenido", a diferencia del SPF "basado en la ruta".

• La entidad responsable afirma su responsabilidad "firmando" el mensaje con un par de hashes criptográficos insertados en una cabecera de mensaje.

• La validación DKIM la realiza el dominio receptor intentando generar los mismos dos hashes.

• En muchos casos, la validación DKIM no puede completarse hasta que el servidor remitente haya transmitido el mensaje completo.

• Los fallos de validación pueden ser difíciles de solucionar.

• 
  

"Autenticación "basada en el contenido

DKIM se denomina autenticación "basada en el contenido", en lugar de "basada en la ruta", porque el hecho de que un mensaje pase o no la validación DKIM se basa únicamente en si el contenido ha cambiado o no entre el momento en que se firmó y el momento en que se intentó la validación.

Firma y validación DKIM

Las organizaciones que deseen firmar correo DKIM generarán primero dos claves criptográficas. Una de las claves se mantendrá privada y a disposición del servidor remitente para la firma del correo, y la otra se hará pública en DNS para que la utilicen los dominios receptores al intentar validar la firma. Los métodos para generar estas claves e instalarlas dependen de la plataforma y están fuera del alcance de este post, aunque más adelante describiré la publicación en DNS de la clave pública DKIM.

El encabezado de firma DKIM

Para empezar a entender DKIM, veamos primero una cabecera DKIM-Signature:

DKIM-Signature: v=1; a=rsa-sha256; d=bienvenidos.foo.com; s=avisos; c=relajado/relajada; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;

La cabecera DKIM-Signature es una serie de pares clave-valor, algunos de mayor interés para el lector que otros, pero los describiré todos aquí.

En primer lugar, veremos las que interesan más de pasada al lector:

• v=1; – Specifies the DKIM version (1 is the only valid value)

• a=rsa-sha256; – En algorithm used to construct the cryptographic hashes

• c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.

• t=1454417737; – En timestamp of when the signature was created.

Estas tres partes de la cabecera contienen la información real de la firma:

• bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; - This is the hash of the body of the message.

• h=De:Respuesta-A:Asunto:Fecha:Mensaje-ID:Para:Versión-MIME:Tipo-Contenido; - This is a list of the headers that were used to create the signature data shown below.

• b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; -; -; -; -. This is the acutal DKIM signature data

Estas tres partes son las que más interesan al servidor receptor que validará la firma:

• d=bienvenido.foo.com; - This identifies the domain that signed the message

• s=avisos; - The selector; domains can have multiple selectors that they use when signing messages.

• i=@welcome.foo.com; - This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.

La razón por la que estas partes son de interés para el servidor receptor es que proporcionan la información necesaria para ayudar al receptor a validar las firmas.

DKIM Validation

In addition a la requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found en el location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at avisos._clavedominio.bienvenidos.foo.com, and it might look something like this:

notices._domainkey.welcome.foo.com. texto descriptivo "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"

El validador utiliza esa clave (los bits p=) para producir su propio conjunto de hashes del mensaje; si esos hashes coinciden, entonces el mensaje no ha sido alterado en tránsito, y por tanto el mensaje puede contribuir, y quizás beneficiarse, de cualquier reputación que exista para el firmante del mensaje.

Fallo de validación y resolución de problemas

Antes he mencionado que los fallos de DKIM pueden ser difíciles de solucionar, y aquí explicaré por qué.

Algunos fallos de validación DKIM tienen causas obvias, como que el mensaje no esté firmado, o que la clave pública del dominio firmante no se encuentre en DNS o no sea sintácticamente correcta, o quizás que el mensaje haya sido obviamente alterado en tránsito. Cuando se producen este tipo de fallos, es fácil averiguar el problema y recomendar una solución. Sin embargo, los casos difíciles, y los que dan lugar a la experiencia de asistencia más frustrante, son aquellos en los que el mensaje se firmó, la clave pública existe en DNS y el mensaje no se alteró de forma evidente, pero el validador informa de que la firma no se validó.

La razón por la que son difíciles de solucionar es porque no hay forma real de que ninguna de las partes reproduzca las condiciones en las que se firmó y validó el mensaje. El mensaje tiene en su cabecera DKIM-Signature los hashes generados por el firmante en el momento de la firma, pero es probable que el validador no tenga acceso a la infraestructura del firmante y, por tanto, no pueda intentar reproducir la firma en las condiciones del firmante. Del mismo modo, es probable que el firmante no tenga acceso a la infraestructura del validador y, por tanto, no pueda intentar validar el mensaje del mismo modo que lo hizo el validador.

Los fallos como el que describo aquí son poco frecuentes, y los fallos de validación de DKIM por sí solos no suelen repercutir en la colocación de la entrega. Según mi experiencia, estos fallos generan más incidencias que cualquier otro tipo de problema con DKIM.