Independent Stream W. Chuang Internet-Draft Google, Inc. Intended status: Experimental 17 January 2023 Expires: 21 July 2023 Relay Flow Identifier draft-chuang-relay-flow-identifier-00 Abstract To prevent spammers from using relay forwarding, we propose to identify relay flows. We do this by having relays categorize their authenticated traffic flows and publish to receivers identifiers associated with those flows. This is a unique, persistent over time, base64 identifier token that is secured by some digital signature. Receivers can use this identifier to help categorize traffic through the relay and use that identifier to apply fine-grain anti-abuse policies instead of on the entire traffic through the relay. This document provides a specification for DKIM ([RFC6376]) for originating traffic and ARC [RFC8617] for forwarded traffic. 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 July 2023. Copyright Notice Copyright (c) 2023 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 Chuang Expires 21 July 2023 [Page 1] Internet-Draft Relay Flow Identifier January 2023 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. Terminology and Definitions . . . . . . . . . . . . . . . 2 1.2. Relay Flow Identifier Specification . . . . . . . . . . . 3 1.2.1. Flow Identification . . . . . . . . . . . . . . . . . 3 1.2.2. DKIM . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2.3. ARC . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Privacy Considerations . . . . . . . . . . . . . . . . . 4 1.4. Security Considerations . . . . . . . . . . . . . . . . . 4 1.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 4 2. Normative References . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Spammers utilize relays to obfuscate their identities and often to spoof some other identity with email receivers. For example a spammer may exploit the shared tenancy vulnerability of SPF to spoof some identity as follows. It finds a relay that hosts many different enterprise customers who include the relay's IPs in their SPF policies. The spammer then sends traffic through the relay assuming the identity of one of those customers i.e. it spoofs the MAIL FROM identity of the victim domain. While the SPF validation (if done) of the initial send by the spammer to the relay fails, a subsequent SPF validation when forwarded to some other victim receiver from the relay will pass SPF because the IPs are contained in the victim's SPF policy. At some point, the receiver notices the spam via the relay and wants to apply anti-abuse counter measures. With existing authentication methods, this policy would impact all mail flows through that relay, both innocent and malicious. A better approach would be to selectively apply anti-abuse counter measures to the spammer's flow which is what this proposal enables. 1.1. Terminology and Definitions Acronyms Chuang Expires 21 July 2023 [Page 2] Internet-Draft Relay Flow Identifier January 2023 * Authenticated Received Chain (ARC) [RFC8617] - is a protocol that is meant to resolve some of the issues for DMARC [RFC7489] to fix the problems that DMARC policy rejects caused by mail forwarding, and is based on DKIM, but suffers from similar issues as DKIM replay. ARC defines digital signatures and Authentication-Results by ADMD and a versioning mechanism for them. * Authentication-Results [RFC8601]- A header containing a list of validation results and comments. * DomainKeys Identified Mail (DKIM) [RFC6376]- IETF standard for the cryptographic protocol to authenticate email at the domain level and protect the integrity of messages during transit. - DKIM replay- [RFC6376] section 8.6 defines a vulnerability called DKIM Replay as a spam message sent through a SMTP MTA DKIM signer, that then is sent to many more recipients, leveraging the reputation of the signer. * Sender Policy Framework (SPF) [RFC7208]- IETF standard for authenticating sending servers typically based on IP address. 1.2. Relay Flow Identifier Specification This specification defines an identifier for authenticated relay. Typically it is password authenticated such as methods provided for in [RFC4954] but other methods MAY be possible. This identifier MAY be used for other authenticated forwarding flows such as mailing lists and with other authentication methods such DKIM or SPF that verifies who the sender is. Because some relays may be originated at the relay which traditionally will be DKIM signed, this document provides a specification for DKIM ([RFC6376]). In other instances, relays act as forwarders, and these are sometimes not DKIM signed by the relay so instead this document proposes a specification using ARC ([RFC8617]). 1.2.1. Flow Identification The relaying service choosing to use this specification MUST categorize and name relayed traffic flows such that receivers can do anti-abuse analysis upon them if necessary. In order for the identifier to be effective, it SHOULD be persistent in time and uniquely named across all flows through the relay. If a message is associated with more than one flow, the relay SHOULD select the more specific flow based on local policy. This specification defines the relay flow identifier as a base64 ([RFC4648]) token. That name MUST not be any internal name of the relay though MAY be a secure cryptographic hash of such. Chuang Expires 21 July 2023 [Page 3] Internet-Draft Relay Flow Identifier January 2023 1.2.2. DKIM This proposes a new DKIM [RFC8617] DKIM-Signature tag-value that identifies the presence of a relay flow and a flow identifier as a token. The tag is defined "rfid", while the token value is in base64 ([RFC4648]). The token parsers MUST ignore a reserved comma that may be further specified in the future. Example: \ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=20230116; h=...; bh=...; b....=; rfid=a+to+z/A+to+Z/0123456789, 1.2.3. ARC This proposes a new ARC [RFC8617] ARC-Authentication-Result defined method ([RFC8601]) that identifies the presence of a relay flow and its property that identifies a flow identifier as a token. The defined method is "relay", which when present, takes a single result value of "pass" that indicates the relay was authenticated. The relay method will have a propspec tag-value with a policy ptype with a "id" property i.e "policy.id" that takes a single token value. That token value is in base64 ([RFC4648]). The token parser MUST ignore a reserved comma that may be further specified in the future. Example: \ ARC-Authentication-Results: i=1; auth.example.com; relay=pass (comments) policy.id=a+to+z/A+to+Z/0123456789, 1.3. Privacy Considerations 1.4. Security Considerations 1.5. IANA Considerations This document has no IANA actions yet. 2. Normative References [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, DOI 10.17487/RFC4954, July 2007, . Chuang Expires 21 July 2023 [Page 4] Internet-Draft Relay Flow Identifier January 2023 [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, . [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC8601] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 8601, DOI 10.17487/RFC8601, May 2019, . [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. Kucherawy, Ed., "The Authenticated Received Chain (ARC) Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, . Appendix A. Acknowledgments Thanks goes to Emil Gustafsson for suggesting a DKIM specification. Author's Address Weihaw Chuang Google, Inc. Email: weihaw@google.com Chuang Expires 21 July 2023 [Page 5]