2

Many people have written about DKIM header injection attacks. [1] The suggestion to mitigate it is to oversign headers and to rotate any DKIM keys that were previously used to sign e-mails where not all important headers have been oversigned.

  • Essentials and obvious things first. If the e-mail uses a headers such as To:, From:, Subject: etc, then these headers must be signed.

  • For better security, such header actually included in the e-mail have to be signed again. That is called DKIM oversigning. "Signed again" here means adding it again to the h= field of the DKIM signature. So when someone views the e-mail headers, they see To:, From:, Subject: etc are signed (in the h= list) two times. This is because otherwise if that wasn't the case then a spammer might inject that header as an additional malicious header.

  • For other headers for example a header such as List-Unsubscribe that is usually not included unless the e-mail was sent by a mailing list, it should be oversigned anyhow. I.e. also added to the the h= field. But adding the header to the h= field only once is sufficient. There's no additional security by oversigning the header two, three more or even more times. That's because that way it has already been unambiguously expressed that this header didn't exist in the original e-mail. [2]

  • Maybe headers such as for example List-Unsubscribe aren't too important for non-mailinglists but as defense in depth, why not add it anyway? It makes the h= (headers) part of the DKIM signature longer but most users are not looking at it anyhow so why not.

Is my understanding so far correct?

Elsewhere I am reading:

Normal headers: they are signed as many times as you specify them.

Why would a header be signed let's say 3 times? Ok, when using a header twice legitimately in the original then signing it twice plus one more time (oversign) so 3 times in total makes sense.

But if a header is included only once, signing it 2 times makes sense. But signing it 3 times, seems unnecessary? At best, does nothing. At worst, confuses DKIM verification software or breaks maximum string length settings or something.

[1]

[2] Technically because the header is not in the original e-mail. It's only in a list of the h= field in the DKIM signature. The DKIM signature can only be verified if no part of headers covered by the DKIM signature has been modified. Adding this header even though it was already oversigned (which means it was added to the h= field even though the original e-mail didn't include it) would result in DKIM signature verification failure.

[3]

Improve this question

1 Answer 1

Reset to default
2

In order to protect against changing a critical header fields (including removing) each of the existing critical headers need to be included into the DKIM signature. In order to protect against adding a new critical header fields it should be over-signed exactly once, i.e. if a field like Subject is included one time in the mail, then it should be included two times in the DKIM signature - one to include the existing field and another (empty) one to prevent adding another Subject field.

Critical header fields are the ones where the interpretation of the message might be changed significantly by adding, removing or modifying such a field. This also includes the seemingly invisible content, which gets used in displaying the mail inside a mail thread (References, In-Reply-To) or which might change where answers go (Reply-To) etc.

The latest DKIM standard RFC 6376 contains in section 5.4.1. Recommended Signature Content clear recommendation of which fields are recommend to include in the signature. Unfortunately this is a MAY only, and not a SHOULD or even MUST.

Even more unfortunately this list is missing some critical header fields, notably Content-Transfer-Encoding and Content-Type which can significantly change the interpretation and display of a message. These header fields were included in the preceding version of the standard RFC 4871 but were removed in the updated standard for some unknown reason.

Based on this - sign and over-sign all header fields mentioned in both of these standards together. This means also to include these header fields in the signature even if they do not currently exist in the mail (i.e. over-sign non-existing fields) so that they cannot be added later without invalidating the signature.

In detail as mentioned in both standards:

From (the only mandatory header)
To, Cc, Reply-To
Subject
In-Reply-To, References
Date
List-Archive, List-Help, List-Id, List-Owner, List-Post, List-Subscribe, List-Unsubscribe
Resent-Cc, Resent-Date, Resent-From, Resent-To

Only mentioned in the older standard:

MIME-Version
Content-Transfer-Encoding
Content-Type
Message-ID, Sender, Resent-Message-ID, Resent-Sender
Content-Description, Content-ID

Now I would really like to see some mail providers actually to implement this. An unscientific look into my mailbox shows that only half include Content-Type and 15% include Content-Transfer-Encoding in the signature. And while all include the Subject only about 20% over-sign it so that it cannot be injected and thus the displayed subject changed for all mail clients which display the upper subject in the mail header.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .