| Internet-Draft | DKIM Anti-Replay Canonicalization | September 2022 |
| Kucherawy | Expires 12 March 2023 | [Page] |
DomainKeys Identified Mail (DKIM) provides a digital signature mechanism for Internet messages, allowing a domain name owner to affix its domain name in a way that can be cryptographically validated.¶
DKIM signatures protect the integrity of the message header and body only. By design, it decoupled itself from the transport and storage mechanisms used to handle messages. This gives rise to a possible replay attack, but the original DKIM specification fell short of providing a mitigation strategy. This document presents an optional method for binding a message to a specific recipient or set of recipients so that broader replay attacks can be discouraged.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 12 March 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
DomainKeys Identified Mail (DKIM) provides a digital signature mechanism for Internet messages, allowing a domain name owner to affix its domain name to a message in a way that can be cryptographically validated.¶
[RFC4686] presents the original threat model DKIM was meant to address, and the environment in which it was expected to work. Notably, DKIM decoupled itself from the transport of the message. The theory suggests it should be possible to validate a signature whether a message is in situ (i.e., in an inbox on disk), in transit between mail servers, or being retrieved through a mailbox access protocol.¶
In particular, this meant a DKIM signature can validate irrespective of what is in the SMTP [RFC5321] envelope containing it, or even when there is no envelope to consider. This means a message and its signature can be re-sent to anyone simply by changing the set of recipients in the envelope and passing the message back to a Mail Transport Agent (MTA). As the message itself is unaltered, any DKIM signature(s) on it will continue to validate. This is a form of replay attack, and it relies for its success on the perceived value (i.e., reputation) of the domain(s) named in the signature(s).¶
This document describes a mechanism by which a signature and a message are coupled such that successful replays to other recipient sets are not possible, as the signature will no longer validate.¶
Several terms used in this document are based on their definitions in [RFC5598].¶
The term "envelope recipient" is, using the notation proposed in that document, an RFC5321.RcptTo address.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This section describes a new DKIM canonicalization that can be used by a signer to ensure that a signature will only validate for a specific recipient set. It is essentially the same as the "relaxed" header canonicalization method described in Section 3.4.2 of [RFC6376] except that it also includes the envelope recipient(s) in the canonicalized which is then fed to the signing algorithm.¶
DKIM signers and verifiers to date have no reason to be interested in any aspect of the envelope used to transport a message. This canonicalization is not possible without that context being available. This may prove to be a challenge to some operating environments. Also, this will make it impossible to validate a DKIM signature using this algorithm in a context where no envelope exists, such as when retrieving a message from a mailbox.¶
The "no-replay-relaxed" header canonicalization algorithm MUST apply the following steps in order:¶
The signing and verifying processes defined for DKIM are otherwise unmodified.¶
Consider the following SMTP transaction, wherein "C" denotes something sent by an SMTP client, "S" denotes something sent by an SMTP server, and terminating CRLFs in both directions are omitted:¶
C: MAIL FROM:<msk@example.net> S: 250 Sender OK C: RCPT TO:<bob@example.com> S: 250 Recipient OK C: RCPT TO:<alice@example.com> S: 250 Recipient OK C: DATA S: 354 Go ahead [message header omitted] [message body omitted] . C: 250 Message delivered¶
The canonicalization described above would operate the same way as the "relaxed" header canonicalization would, except that the content fed to the hash algorithm would be preceded by:¶
alice@example.com<CR><LF> bob@example.com<CR><LF>¶
Use of this canonicalization guarantees that a signature will not verify unless sent to exactly the same set of envelope recipients as was present in the envelope when the message was prepared for signing. The fact that the recipient set is sorted allows verifiers to tolerate any reordering of the envelope that may be done in transit. However, if any original recipient is removed, or any new recipient added, the signature will not validate because the content passed to the hash step at the verifier will differ from what was done at the signer. Thus, in the replay scenario described in Section 1, the signature no longer validates.¶
If the need to be able to validate a signature from storage (without an envelope) needs to be preserved, the signer can still add a second signature using some other header canonicalization that does not need the envelope context to verify. This, however, requires the verifier to understand when it is appropriate to use which signature.¶
Note, however, that this is fragile in the modern Internet message ecosystem. Some scenarios that will yield false negatives with this method are described below.¶
If a receiving MTA notes that one of the envelope recipients refers to a mailbox in a domain for which it has administrative authority, but is known to be an alias, it may rewrite that envelope into its canonical form. For instance, if a receiving MTA is officially known as the mail server for "example.com", but also accepts mail for its users when addressed to "example.net", it may alter that latter address in the envelope to refer to its canonical name. This alters the recipient list, and thus alters the content passed to the hash algorithm when validating the signature, leading to a failure.¶
If a message contains envelope recipients at domains served by separate MTAs, [RFC5321] compels the handling MTA to split the message, creating two envelopes containing identical content. The first of these will be addressed to one recipient and sent on its way; the second will be addressed to the other and sent via its own route.¶
Upon arrival at either DKIM verifier, the recipient list has effectively been altered since signing. This alters the content passed to the hash algorithm when validating the signature, leading to a failure.¶
This can be avoided by arranging that no envelope ever has more than a single recipient, but this renders useless an important "common factoring" feature of SMTP. In the case of a mailing list server that may need to distribute a single message to a very large number of recipients, this method can impose significant compute or storage costs.¶
IANA is asked to make the following entry in the "DKIM-Signature Canonicalization Header" sub-registry of the "DKIM Parameters" registry group:¶
All of the security considerations of [RFC6376] apply when this canonicalization is in use.¶
A signer that is forced to generate independently signed messages for each recipient in a situation where large recipient lists are common could be exploited to cause a denial-of-service attack simply from the fact that there is an amplication of work being done.¶
The loss of the ability to verify messages signed using this canonicalization from their mailboxes will have unknown security impact.¶