DKIM header oversigning and why the l= tag is a trap

The l= tag is a trap#

The l= tag tells verifiers to hash only the first N bytes of the canonicalized body. It was intended to let mailing lists append footers without breaking signatures.

The problem is obvious once stated: anything after byte N is unsigned. An attacker who obtains a message signed with l= can append arbitrary content, including a convincing phishing call to action, and the signature still verifies as your domain.

It gets worse with MIME. An attacker can append new MIME parts, or content that some clients render in place of the original, depending on the structure. Researchers have demonstrated practical attacks along these lines.

There is no good reason to use l= today. Mailing lists that modify messages are better handled through ARC and From rewriting. Check your outgoing mail for l= in the DKIM-Signature header and disable it if present.

How to audit your current signatures#

Send a message from each system that signs for your domain to a mailbox you control. In the raw source, find the DKIM-Signature header and check:

1. Is l= present? If so, disable it.
2. What is in h=? At minimum: from, to, subject, date, message-id, mime-version, content-type, plus reply-to and list-unsubscribe headers when present.
3. Are critical headers listed twice? If From and Subject appear once each, you are not oversigning.
4. Is the algorithm rsa-sha256 (or ed25519-sha256)? RFC 8301 removed rsa-sha1 from what signers may use.

A short script helps if you have many senders:

import email, re, sys

msg = email.message_from_binary_file(open(sys.argv[1], "rb"))
for sig in msg.get_all("DKIM-Signature", []):
    tags = dict(t.strip().split("=", 1) for t in re.sub(r"\s+", "", sig).split(";") if "=" in t)
    h = [x.lower() for x in tags.get("h", "").split(":")]
    print("d=", tags.get("d"), "s=", tags.get("s"), "a=", tags.get("a"))
    print("  l= present!" if "l" in tags else "  no l= tag")
    for name in ("from", "subject", "reply-to", "to"):
        print(f"  {name}: signed {h.count(name)}x")

What to ask your vendors#

If a third party signs mail as your domain, you cannot change its signer configuration directly, but you can ask. Useful questions for a vendor's support or security team:

• Which headers do you include in h=, and do you oversign From and Subject?
• Do you ever set the l= tag, for example to accommodate footers?
• Which algorithm and key length do you use, and how often do you rotate keys?
• If you add tracking or footers, does that happen before or after signing?

A vendor that cannot answer these questions clearly is telling you something about how much attention it pays to authentication. The answers also give you a baseline to re-check after the vendor changes its platform.

Checklist#

• Never use the l= body length tag.
• Sign From, To, Subject, Date, Message-ID, MIME-Version, Content-Type, and Reply-To and List-Unsubscribe headers when present.
• Oversign From, Subject, Reply-To and To at minimum.
• Use rsa-sha256 with keys of at least 2048 bits.
• Audit signatures from every system that sends as your domain, including vendors.

Key takeaways#

• DKIM only protects the headers listed in h= and the body up to l=; everything else can be changed.
• Verifiers match signed headers from the bottom up, which allows extra headers to be injected above signed ones.
• Oversigning, listing a header one more time than it appears, blocks that injection.
• The l= tag leaves the rest of the body unsigned and should never be used.
• Check the raw DKIM-Signature on mail from every sender you use.