Internet Engineering Task Force D. Crocker Internet-Draft Brandenburg Internetworking Intended status: Standards Track 19 April 2025 Expires: 21 October 2025 DomainKeys Originator Recipient (DKOR) draft-crocker-dkor-00 Abstract DKIM associates a domain name with a message stream, using cryptographic methods, to permit reliable and accurate reputation- oriented analysis of the stream. It is possible for an authorized user to conspire for additional distribution of a message, leveraging the domain name reputation for promoting spam. This is called DKIM Replay. DKOR defines a means of limiting that ability, by associating original addressing information with the message's DKIM signature, to detect distribution beyond the intended recipient. DKOR uses existing DKIM services and only requires implementation of the additional DKOR requirements by the signer and any receiving site wishing to participate in DKOR services. Other DKIM receivers can process the same DKIM signature without knowledge of DKOR. Status of This Memo 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 21 October 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Crocker Expires 21 October 2025 [Page 1] Internet-Draft DKOR April 2025 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. DKOR Design . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Signing Behavior . . . . . . . . . . . . . . . . . . . . . . 4 4. Evaluating Behavior . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5.1. RCPT-TO Header Field . . . . . . . . . . . . . . . . . . 5 5.2. MAIL-FROM header field . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction DKIM [RFC6376] associates a domain name with a message stream, using cryptographic methods, to permit reliable and accurate reputation- oriented analysis of the stream. Each message in the stream has a DKIM digital signature attached to it, using the domain name. Receiving sites can then develop a reputation analysis for messages in that stream, without concern that a message was created by an unauthorized actor. However, it is possible for an authorized user of a platform, which is signing messages with a domain name, to conspire for additional distribution of a message, beyond the set of recipients that were included at the time of original posting. The message goes through an additional platform, which then redistributes the message, while preserving the original DKIM signature. Reception and delivery of the message to these additional recipients is aided by the reputation of the domain name used in the DKIM signature. This capability can, therefore, be used for spamming. This is called DKIM Replay. Crocker Expires 21 October 2025 [Page 2] Internet-Draft DKOR April 2025 Ideally, authorized users of a platform are subject to sufficient controls and accountability, so their likelihood -- or even ability -- to effect this abuse is severely limited. Unfortunately, operational realities on some platforms do no achieve such control. There is therefore a need for a mechanism that can be added to aid email transit handling, to detect DKIM Replay and facilitate differential handling of such messages. Extensive community discussion converged on the view that a useful line of effort, for enabling this detection, is to include the email envelope address (e.g., SMTP RCPT-TO) [RFC5321] as part of the DKIM hash calculation. There is also interest in similarly encoding the email envelope notification return address (e.g., SMTP MAIL FROM), with the view that this might be helpful in efforts to limit use of the return 'channel' as a spamming path, called backscatter. [ Note: Including the return address needs a more complete explanation. I gather it is for backscatter control, but am not clear on how it will get used to achieve that. So it's inclusion here is as a placeholder, pending further text. /d ] Domain Keys Originator Recipient (DKOR) defines such a mechanism, using existing DKIM services and only requiring implementation of the additional DKOR requirements by the signer and any receiving site wishing to participate in DKOR services. Other DKIM receivers can process the same DKIM signature without knowledge of DKOR. Note: Reference to SMTP in this document is strictly informative. Nothing in this specification is dependent upon the specific email transport service details, other than being able to obtain recipient and return address information.[RFC5598] The means for obtaining these is outside the scope of this specification. 1.1. Requirements Language 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. 2. DKOR Design A message covered by DKOR is restricted to having a single recipient address. Crocker Expires 21 October 2025 [Page 3] Internet-Draft DKOR April 2025 DKOR defines a use of DKIM, with the DKIM signature covering whatever other header fields it is normally used to cover. For DKOR, it also covers one header field that specifies the original recipient address, and another field that specifies the envelope notifications return address. The addresses in these fields are redundant with the addresses in their corresponding envelope fields/commands. The presence of either DKOR header field self-declares the use of DKOR. Further there is no benefit in having the signer publish that it uses DKOR. The method(s) for obtaining envelope information, to be used by DKOR, are a matter of local implementation and are outside the scope of this specification. If the addresses in the fields match those in their corresponding envelope fields/commands, and the DKIM signature validates, then DKOR passes. If either does not match, or the DKIM evaluation fails, then DKOR fails. Policies and actions that apply to the handling of messages that pass or fail DKOR are local matters for the evaluating service and are outside the scope of this specification. An example of challenges in determining the handling of a DKOR failure is that the failure can be the result of entirely legitimate reasons, such as a legitimate redistribution service that does not make changes to message content and only uses a new recipient address. Failures can also occur due to the considerable vagaries of email handling idiosyncrasiesf. Note: The header fields used by this specification are independent of any other header fields that might contain the same addresses, in order to avoid any potential confusion about semantics or purpose. Also the field names were chosen for obvious correspondence to their SMTP equivalent envelope fields/commands; however this specification has no dependence on SMTP and the values can come from whatever email transport service is being used. 3. Signing Behavior 1. If the recipient address (e.g., RCPT TO) is to be protected, obtain that envelope address and place a copy of it into a RCPT- TO header field. [RFC5322] 2. If the return notices address (e.g., MAIL FROM) is to be protected, obtain that envelope) address and place a copy of it into a MAIL-FROM header field. Crocker Expires 21 October 2025 [Page 4] Internet-Draft DKOR April 2025 3. DKOR permits either or both fields to be present; however the signature MUST cover both fields. 4. Create a DKIM signature that includes both of these header fields. 4. Evaluating Behavior 1. If either of the DKOR header fields is present, then perform a DKOR evaluation. 2. Obtain the two envelope address values used by DKOR. 3. Compare the values to the corresponding DKOR header field values. 4. If either value does not match, then DKOR fails. 5. Perform a DKIM validation. 6. If DKIM validation fails, then DKOR fails. 5. IANA Considerations 5.1. RCPT-TO Header Field IANA has added RCPT-TO to the "Permanent Message Header Field Names" registry (see [RFC3864]) for the "mail" protocol, using this document as the reference. 5.2. MAIL-FROM header field IANA has added MAIL-FROM to the "Permanent Message Header Field Names" registry (see [RFC3864] for the "mail" protocol, using this document as the reference. 6. Security Considerations This specification defines a mechanism for detecting retransmission of a message, that sends it to additional addressees, while preserving a DKIM signature from its original posting. The incremental security considerations are accuracy of creating and evaluating the two address fields defined here. As with other email assessment mechanisms and the heuristics they use, DKOR creates opportunities for false positives, which can produce hostile treatment of legitimate email. Crocker Expires 21 October 2025 [Page 5] Internet-Draft DKOR April 2025 There are no other security considerations that result from using DKOR. 7. References 7.1. Normative References [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, . 7.2. Informative References [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, . Acknowledgements Extended discussions about DKIM Replay converged on the unpleasant necessity to have messages contain only one recipient in the envelope. No alternative approach gained any traction. Author's Address Crocker Expires 21 October 2025 [Page 6] Internet-Draft DKOR April 2025 Dave Crocker Brandenburg Internetworking Email: dcrocker@bbiw.net URI: https://bbiw.net Crocker Expires 21 October 2025 [Page 7]