l-Tag DKIM Vulnerability: What Can You Do to Secure Your Email?

DKIM is a crucial email authentication method designed to ensure the integrity of emails. While it helps verify that the content has not been altered, a specific DKIM vulnerability involving the length tag (l=) in DKIM signatures can leave emails open to tampering.

In this article, learn about the potential risks associated with the “l=” tag and get actionable steps to secure your emails against this vulnerability.

What is DKIM and How Does It Work?

DKIM (DomainKeys Identified Mail) is an email authentication method designed to verify the integrity of an email during its journey to the recipient’s inbox. It uses attributes found in the email header (FROM address, subject, date, mime-version, etc.) to create an asymmetric cryptographic signature that verifies the email’s integrity with a domain.

Signature Creation:

• The sending mail server creates a DKIM signature using a private key stored on the server.
• This signature is added to the email header.
• The corresponding public key is hosted in the DNS zone of the sending domain.
  

Signature Verification:

• When the recipient’s mail server receives the email, it retrieves the public key from the DNS record of the sending domain using the selector provided in the DKIM signature header (s=selectorvalue).
• The server uses this public key to decrypt the signature and compare it with a freshly generated hash of the email’s header and selected content.
• If the hashes match, it confirms that the email’s header and selected content have not been altered.
  

The l-tag DKIM Vulnerability

The vulnerability in DKIM is associated with the length tag (l=). The l= tag is optional and specifies the length of the portion of the email body that was signed. For example, l=500 means that only the first 500 bytes of the email body are signed. This leaves the rest of the email body, which is not covered by the DKIM signature, susceptible to alterations.

Exploitation

An attacker could exploit this by appending malicious content after the signed portion of the email body. Since the appended content is not covered by the DKIM signature, it won’t affect the validity of the signature. Email clients will display the entire email content (both signed and unsigned portions), potentially misleading the recipient and defeating the fundamental integrity promise of DKIM.

Example:

⒈Vulnerable Email Header with DKIM Signature Containing the Length Tag

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=randomselector;
h=date:from:to:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; 
bh=1kfwQkFg+nKq2DRy7GwHjDsfmrk=; b=ZL8/3fvcqK8ZVHy+iZ/AGuM9mPlU9WjJpY6BG3J6Y
M+8Nf4Ybaq8wDpMj5Nd; l=500;

⒉ Invulnerable Email Header with DKIM Signature Without the Length Tag

DKIM-Signature:

v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=randomselector;
h=date:from:to:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; 
bh=1kfwQkFg+nKq2DRy7GwHjDsfmrk=; b=ZL8/3fvcqK8ZVHy+iZ/AGuM9mPlU9WjJpY6BG3J6Y
M+8Nf4Ybaq8wDpMj5Nd;

Solutions and Fixes

To mitigate this vulnerability, you should avoid using the l= tag in DKIM signatures.

For ESPs and Third-Party senders:

• Avoid using the l= tag and rotate all current DKIM keys to remove the length tag implementations.
• For ESPs using CNAME-type public key records, changes can be made and keys rotated without end-users having to update their DNS.
• For ESPs using TXT type public DKIM key implementation, notify end-users and provide the new public DKIM key for them to update in DNS.
  

Dedicated Servers:

• Ensure your OpenDKIM configuration does not include the parameter BodyLengthDB(dataset). Modify the settings and rotate keys to avoid this vulnerability.
• Check your MTA (Mail Transfer Agent) documentation and verify that the length tag is not included in the DKIM configuration.
• Modify the settings and rotate keys to avoid this vulnerability.

Email Investigation

To determine if your DKIM signatures are vulnerable:

• Send a test email to yourself.
• Check the email headers for the presence of the l= tag in the DKIM-Signature element.

Example: Checking Email Headers

Google (Gmail/Google Workspace):

⒈ Open the email.

⒉ Click on the three vertical dots in the top-right corner of the email.

⒊ Select “Show original.”

⒋ Look for the DKIM-Signature header and check for the l= tag.

Microsoft (Outlook, Microsoft365):

⒈ Open the email

⒉ Click on the three dots in the top-right corner, then View > View message source

⒊ Look for the DKIM-Signature header

⒋ If the l= tag is detected, modify your DKIM settings and rotate keys to mitigate the vulnerability.

The Impact on BIMI

BIMI (Brand Indicators for Message Identification) relies on a valid DKIM signature to display a logo in the recipient’s inbox. If the l= tag is exploited:

• The attacker can pass DMARC, causing the email to land in the recipient’s inbox.
• This could lead to the BIMI logo being displayed unless ESPs create specific rules to exclude emails with the l= tag.

This means that even with an enforced DMARC policy (p=quarantine or p=reject), an attacker can append malicious content to an email, pass DKIM verification, and still have the BIMI logo displayed, potentially misleading recipients.

Final Thoughts: The Good News

The good news is that the adoption of the l= tag is relatively low, so you may not have it in your DKIM signatures. However, it’s always better to double-check your emails and ensure your organization is not prone to this vulnerability.