]> Fastmail Pty Ltd

Level 2, 114 William Street 3000 Australia +61 457 416 436 brong@fastmailteam.com

Yahoo

rclayton@yahooinc.com

Google

weihaw@google.com

Internet-Draft This memo provides a rationale and outline design for replacing the existing email security mechanisms with a new mechanism based around a more strongly authenticated email delivery pathway, including an asynchronous return channel.

Background and motivations In 2007, (Domain Key Identified Mail / DKIM) was published, outlining a mechanism for a domain to sign email in a way that recipients could ensure that the email had come from an entity possessing the secret key matching a public key published in the DNS by the source domain. For clarity in this document we call this established scheme "DKIM1". This document has been obsoleted and updated many times since then, and a large amount of operational experience has been gained using it. However, it has some known weaknesses with some kinds of email flow. If an intermediary alters the email then the original DKIM1 signature will no longer be verifiable. In 2019, (Authenticated Received Chain / ARC) attempted to solve this issue. However, it does not provide a mechanism for determining whether recipients will recognise the ARC signatures or trust the veracity of the systems that add them. A further issue is that bad actors may "replay" bad email that systems have DKIM signed and erode the reputation of the signer. Ad hoc systems have been developed so that systems that have placed a DKIM signature onto an email may be informed about the quality of the messages that they are relaying -- so called feedback loops. However, there are no formal specifications for such schemes and feedback may be sent where it is not actually required. Furthermore, where the origin of a message has been forged and the final intermediary in a chain finds that it is undeliverable, then the Delivery Status Notification (DSN) may be sent to an unsuspecting third-party -- a phenomenon called backscatter. This document solves these and related problems in a holistic way, by having every hop in a forwarding chain responsible for: verifying the path that messages have taken to get to it, including by being able to reverse modifications or by asserting that it trusts the previous hop unconditionally, and that it is the declared next hop in the chain. declaring (under protection of its own signature) where the message is being sent to next. asserting that it will pass control messages (including bounces, abuse reports and delivery notifications) back to the previous hop for a reasonable time.

Design Goals It is intended that legacy mail systems constructed in the last century will be able to interoperate with this new specification. However, more recently developed systems will, after a period of parallel running, need to be upgraded in order to continue to be able to authenticate email. We favor simplicity over obscure functionality. We aim to keep the number of cryptographic operations required the same or less, for all the most common types of email flow. We aim to make all parts of the specification mandatory to implement because experience shows that interworking is adversely affected by providing optional functionality.

Basic ideas An email is DKIM2 signed by the originator -- in pretty much the same way as is done in the existing DKIM1 standard. In practice the vast majority of mail is signed using relaxed/relaxed methods. DKIM2 will only allow relaxed/relaxed. Each "hop" that handles the email adds another, sequentially numbered, DKIM2 header field. A simple relay will only add a single header. Email service providers will often add two, one on behalf of the actual originator the other for themselves. A relay that rewrites email from one domain to another will add two headers to record the rewriting. If an email is accepted by a server but it is later found that it cannot be delivered onward, or further analysis of its contents leads to a determination that it should not be delivered after all, then the previous hop is informed by means of a Delivery Status Notification (DSN). If a DSN is received for an email that was previously relayed, then the DSN is passed back to the system that delivered the email. Hence, DSNs are returned back along the "outgoing path" until they reach a system that can take responsibility for handling the report. The DKIM2 headers contain the source and destination of the email. They may also request "feedback" from later entities as to the quality of the email. This feedback is sent directly from systems that choose to honor such requests to any all of the requestors that the sender deems appropriate. Intermediaries that alter emails record their actions (so that later hops can undo and check signatures). Intermediaries whose alterations are too complex to be described or reversed will either have to arrange to be treated as the originator of the message (if they are near the start of the message's journey) or they will need to implicitly trusted by any further intermediaries (if they are near the end of the message's) journey. Intermediaries that duplicate ("explode") emails, record their action so that any further systems that see multiple copies of the email will not reject or discard the email as a "replay".

How the aims of DKIM2 are achieved

Simplification & codification Issue: Every DKIM1 signature specifies an explicit list of which email header fields have been signed. This leads to inconsistent signing of headers, and allows a signature to be created in which security-critical headers are not covered. To prevent bad actors from adding headers which were not originally present it is common to oversign by signing null versions of headers that are not present. This oversigning may be extended to signing two, for example, Subject header fields because some recipients may not enforce the requirement of uniqueness. Mitigation: DKIM2 will specify a fixed set of headers in accordance with now well-established best practice (and insist they are unique) so there will be no need to list what is signed. However, some exotic headers may need to be signed for unusual or future use-cases. DKIM2 will allow this with an h= field.

Preventing backscatter Issue: With DKIM1, you can send delayed bounces if the message has come directly to you and the DKIM signature is DMARC aligned, but otherwise you need to reject at SMTP transaction time to ensure you won't be creating backscatter. Mitigation: Provided that an email is correctly signed when received, it can be rejected at a later point in time. The DSN will be sent to the immediately preceding intermediary. Since the bounce travels back along the (fully authenticated) incoming path it cannot be sent to an uninvolved third party.

Improved privacy for forwarders Issue: If you want to create a privacy preserving forwarding service, you need to SRS rewrite the email's bounce address so that bounces don't accidentally leak the real address of the recipient. Mitigation: Since the DSN messages always go back up the DKIM2 chain, any hop can strip off the higher number (i=) records; including the sender and recipient addresses for them, and create a bounce as if the forwarder itself was doing the rejection. As asynchronous bounces will be common in DKIM2, this is indistinguishable to the sender.

Simplifying error handling for intermediaries Issue: ESPs and other entities that send email on behalf of others have a need to know when delivery errors occur. At present this can only be done by changing the RFC5321 return path so that DSNs will be delivered to an intermediary rather than original sender. Non-standardised mechanisms such as VERP or SRS may be employed to be able to pin down the details of the failure. Mitigation: In DKIM2 DSNs are passed back along the outgoing path so the ESP will receive the DSN and, depending on contractual arrangements, may be able to avoid passing this message any further back along the chain. Issue: A mailing list wishes to learn when email it has handled cannot be delivered. At present DSNs (as opposed to next hop delivery rejections) are often passed to the originator of the email (the value in the MAIL FROM) and are invisible to the mailing list. Mitigation: Passing bounces back along the outgoing path allows a mailing list to take responsibility for the event and not bother the person who sent a message to the list.

The "mailing list DMARC issue" Issue: Once an intermediate (for example, a mailing list or alumni forwarder) makes a change to the header or body of a message, the hashes covered by the sender's DKIM signature no longer match, and it's not possible to see whether the message is semantically similar, or has been completely replaced by a bad actor. Mitigation: DKIM2 will define an algebra for describing how to reverse any changes to create the prior binary data, by inspecting the diff between the two versions, recipients will be able to see who injected bad content. Mailing lists (or alumni forwarders etc.) that alter the Subject header field (or other headers) will record the previous header field contents. This is easy to undo for checking purposes. Mailing lists that add text (either to a simple email body or one or more MIME parts within the body) will record details of the text they have added. This text can then be removed when checking earlier signatures. We expect the "algebra" describing changes to be in a stand-alone document that need not be finalised on the same timescale as DKIM2 itself.

Security gateways Issue: There are some types of alteration, for example by security gateways, that may be impractical to describe in a cost-effective manner. Mitigation: We would expect that outgoing gateways that may be adding disclaimers or rewriting internal identifiers would be provided with appropriate signing keys so that they could be the "first hop" as far as the rest of the email handling chain is concerned. Incoming security gateways may be making substantial changes. Typically they will remove problematic types of attachment and rewrite URLs to use "interstitials". Since this type of functionality is generally provided on a contracted basis further intermediaries will be fully aware of the presence of the security gateway and can be configured to implicitly trust that it has checked earlier signatures and found them to be correct. Hence there is not need to be able to "undo" these changes.

Addressing DKIM-replay Issue: Because an email can currently be sent as "Bcc" such that there's no evidence in the message data of who the recipient is expected to be, it's possible to take a message that is correctly signed and replay it millions of times to different destination addresses as if they had been BCC'd. This message can be resent at any time. Migitation: DKIM2 headers will always have timestamps so that "old" signatures have no value. DKIM2 headers specify both "from" and "to" so that most opportunities to alter a message, re-sign it and replay it at scale will no longer be possible. Since the "to" address is always encoded in the email, any email to multiple recipients must be exploded by the sender, and each copy signed separately with different headers. If the email is replayed (perhaps through a large system with many different customers) then if the email does not say that it has been duplicated then signatures can be assumed to be unique and hence simple caching (or Bloom filters) will identify replays. If the email has been duplicated then recipients can assign a reputation to the entity that did the duplication (along with the expected number of duplicates that will arrive from that entity) and assess duplicate signatures on that basis. If the email is altered before duplication then it is again the case that this will be apparent to the recipient who can develop a reputation system for the entity that did the modification and replay.

Algorithmic dexterity The specification will require both RSA and elliptic curve be implemented. If there is IETF consensus around a "post-quantum" scheme then that will also be included. Experience with DKIM1 is that everyone supports RSA keys and EC support is very patchy so we will emphasize this aspect in bake-offs etc. Dexterity will become essential if advances in cryptanalysis cause a particular type of algorithm to become deprecated. To allow a phased switch away from such an algorithm we will make provision for more than one signature to be present in a single DKIM2 header. Systems capable of checking both signatures will require both to be correct. If only one signature is correct then email will be rejected with a clear message -- allowing interworking issues to be easily debugged.

Reducing crypto-calculations Experience at large mailbox providers is that incoming messages can have large numbers of DKIM signatures all of which need to be checked. For DKIM2, in the common case where email has not been altered by earlier hops, it will only be necessary to check the first DKIM2 signature, the one applied by the previous hop and, if "feedback" is to be provided, the signatures of any entities that have requested feedback. If DKIM-replay is felt to be an issue (and some providers will detect this by identifying non-unique signatures) then more DKIM2 headers may need to be processed to establish the veracity of an alleged forwarding path. Additionally any attempt to do forensics or to assign reputation to intermediates will require more signatures to be checked.

DKIM2 header fields DKIM2 headers will have the following fields Field identifier Explanation i= Sequence Number (from 1 to N) t= Timestamp ds= Signing key identifier (domain & selector) a= Crypto algorithm(s) used (unless combined with b= to allow for multiple signatures on the same email, see discussion of crypto-agility above) b= Signature over hash value strings (DKIM uses b=) bh= Body hash value (see discussion) h= Extra headers signed by this hop m= Indicates if mail has been modified or exploded mf= RFC5321.mail-from rt= RFC5321.rcpt-to fb= feedback requested for this email n= a nonce value (could use for database lookup for DSN handling) At the first hop there cannot be any modification, so instead the m= field is used to indicate a request by the sender that the email never be modified and/or never be “exploded” to multiple recipients. This might be appropriate for some types of transactional email. Since it is only a request, intermediaries may, by local policy, not honor it, but they SHOULD NOT relay mail where the request has not been honored to third parties. We will always hash headers in a "relaxed" mode (to use the DKIM1 jargon). For the body we will always use "relaxed" because that is the usual scheme for DKIM1. Relaxed is more expensive than "simple" but there have been concerns about expressed about interworking. The vast majority of DKIM1 email (99%+) uses relaxed/relaxed. The hashes of the header and the body can be placed into the DKIM2 header field, and then a signature is applied. Alternatively we could define a signature over the hashes but not record their values. The second is neater but the former does allow an unchanged body hash to just be copied and may assist in diagnosing faults. Note also, that there is no technical reason for computing two hashes rather than one, but the presence of an obviously unchanged body hash may again be useful for fault diagnosis and may assist humans in reasoning about how and where changes were made to the body. The nonce value is available for any purpose, but may well be used as an index into a database to access meta-data about an email that has been handled in the past. DKIM2 signatures expire after a fixed period (a week would be appropriate) so that it is not necessary to hold information for indefinite periods or to handle DSNs for email that was delivered long ago. Note that we have not included a version number. Experience from MIME onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, we recommend using header fields labeled DKIM3 instead. For simplicity using single characters before the = would be good, but we quickly run out of obvious relevant letters. Where there is a match to DKIM1 fields these have been copied (though this is merely to assist humans, it's unlikely to affect any code).

Value of rt= Note that is inherent in the DKIM2 design that emails are only ever sent to one recipient at a time. At present some mail servers will batch deliveries together if they are going to the same destination and issue multiple RCPT TO commands in the SMTP protocol conversation. This is not possible with DKIM2 because each email must document a single RFC5321 destination in the rt= parameter. This may seem inefficient but only about 1% of email is currently delivered using multiple RCPT TO commands.

Maximum value for i= There will be an absolutely maximum value of 255 for i=; though realistically we should be able to bring this value back down to about 50.

Maximum age for t= For a message in transit, the timestamp MUST be less than one week ago. For bounces, they MUST be returned to their source within 2 weeks of the timestamp on hop i=1. This requires that as the destination, you MUST create the bounce within 1 week of receipt.

Registry of values for m= Value Purpose nomodify Any hop that adds this requires no modifications; anybody later hop must either reject it or agree to pass it on unmodified header This hop has modified the headers; a separate header lists the algebra to revert the changes body This hop has modified the body; a separate header lists the algebra to revert the changes complex This hop has done something complex and there is no way to revert it If there is no "m" value then this hop asserts it has not modified either the body nor any header covered by a previous DKIM2 signature.

Value for the fb= header Not present, do not send feedback for this email to the signing domain fb=y - this signing domain would like to receive feedback about the disposition of this email (e.g. percentage reported as spam).

Checking hashes For clarity this is written as if there is only one hash and signature to check, whereas there may in fact be one for the header and one for the body. Issues with DNS will cause 4xx responses to be sent.

Step 1 Find the latest DKIM2 signature and determine if the email as received matches that hash AND that you are named as the destination of the email AND that the mail is coming from the named source. If not then refuse to accept the email. The previous hop is responsible for the email (they have either forged it or mangled it -- either way it is their problem). If this check passes then other checks can either be done at delivery time or the mail can be accepted and if later rejected there is a valid path back to the sender over which a DSN can be sent. If it is decided, by local policy, to accept an email where the hash fails (or you are not the documented recipient) then DSN messages back along the chain MUST NOT be sent.

Step 2 Find the first DKIM2 header (numbered 1) and determine if the email as received has the same hash as recorded there. If so, you know the email has not been altered on its way to you. The path it has followed is most likely irrelevant for deciding what to do with it.

Dealing with modifications. Find the highest numbered DKIM2 header that reports a modification. Undo the modification and repeat. When all modifications have been done then there should be a match with the original signature (at hop1). If not then the email has been altered (in an undocumented manner) on its way to you and it SHOULD be rejected. Note that it is not necessary to check the signature on a DKIM2 header that reports a modification. Undoing the modification and discovering that the message can now be authenticated is sufficient. Over time a reputation can be developed for a intermediary which is making modifications and given sufficient trust then the "undo" step could be skipped. Note that the signature of the DKIM2 header that reports the modification would need to be checked to ensure reputation accrued to the correct entity. If the modification is substantial (eg URLs rewritten, MIME parts removed) and it cannot be undone then the receiver (who may not be the immediate next hop) MUST trust the system doing the modification. If it does not then the mail SHOULD be rejected. It will be noted that some modifications can totally change the meaning of an email. This specification does not try to limit modifications. We believe that being able to attribute modifications to a particular entity will allow reliable blocking of malicious intermediaries once they are identified.

Dealing with replays Checking source and destination as recorded by the previous hop makes many “DKIM replay” scenarios impossible. It is possible to exclude all replays by determining if any DKIM2 header reports an expansion event (one incoming email resulting in multiple further emails). If not then you would expect that the (original) hash of the email is unique and duplicates can be rejected. If a expansion event is recorded then receiving multiple copies would not be a surprise. It will be necessary to use local policy to assess whether the number of copies received is acceptable or not. Over time you may wish to develop a reputation for a DKIM2 identity which is doing expansions and conclude that a specific number of copies is to be expected. This can be used to refine local policy.

Feedback loops Some mailbox providers are prepared to report their, or their customers', opinions about incoming email -- for example: that a customer marked a particular email as "spam". These systems are generally called "feedback loops". There are usually bureaucratic systems to ensure reports are only sent to entities that wish to receive them and the mailbox provider may decide that some entities should not be sent any feedback. The senders of email, the originator and/or a commercial company (an ESP) hired to send the email generally favor feedback loops because it allows them to make their emails more acceptable, and the commercial companies can rapidly become aware of customers whose email is widely disliked. In DKIM2 any intermediary can request feedback, but it is still the decision of the mailbox provider as to whether any feedback will be sent. They may still require pre-registration on a per domain basis to receive feedback if only to ensure that any nominated email address is appropriate and is not an unsuspecting third party. Note that feedback can be sent to any requesting entity. There is nothing special about a requester being at hop1 or hop2 on a chain. In particular some forwarding systems late in the chain may wish to become aware if they are forwarding emails that are then reported to be spam.

DKIM1/DKIM2 Interworking Note that DKIM2 signed email can also be DKIM1 signed, and so systems that are not DKIM2 aware can and will operate as they do at present. DKIM2 capable servers will announce the capability in their initial banner in the usual manner for SMTP extensions. When a DKIM2 signed email is delivered to a server that does not understand DKIM2 and leaves the DKIM2 ecosystem the DKIM2 specific events can no longer be expected to occur. In particular any failures to be deliver will be reported to the address in the relevant return path and not back along the DKIM2 chain. A DKIM2 signed email may be delivered to a server that understands DKIM2 but if that server needs to forward the email elsewhere it may find that there is no signing key available for the relevant domain (recalling that the incoming email recorded the destination domain and it is necessary for the next "hop" to match with that. In such a case, once more the email will leave the DKIM2 ecosystem. Refusing to allow an email to leave the DKIM2 ecosystem may be an appropriate choice in some circumstances. If so then an appropriate DSN should be created and passed back along the chain in the normal manner. It is more likely that local policy will be to pass the email to the next intermediary even though this means that it leaves the DKIM2 ecosystem. In such a case it would be possible to add a final DKIM2 header to record this event, but doing this adds considerable complexity, and would provide limited information which was not otherwise available, hence no such header will be added. If, after having left the DKIM2 ecosystem, the email reaches a DKIM2 aware system then the email may have been altered in such a way that the DKIM2 signatures now fail. The receiving system will apply its local policy to determine whether or not to accept the email. If the DKIM2 signatures on the mail are valid, except that the last header does not specify the receiving system as the next hop, then once again it will a matter for local policy as to whether to accept the email. It might be thought that it was obvious that the email was acceptable, but the non-DKIM2-aware intermediaries that have handled it may have duplicated the email and there will be no DKIM2 headers to record this. In any event, systems that accept email which has been outside the DKIM2 ecosystem MUST NOT add any further DKIM2 headers.

Security TBA

IANA Considerations TBA

DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of "spam" and "phishing". [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries.

Changes from Earlier Versions [[This section to be removed by RFC Editor]]

draft-gondwana-dkim2-motivation-01: remove the z= parameter on the grounds that it adds too much complexity document that messages MUST NOT re-enter the DKIM2 world once the chain has been broken.

draft-gondwana-dkim2-motivation-00: initial version