Independent Stream                                             W. Chuang
Internet-Draft                                              Google, Inc.
Intended status: Experimental                            19 January 2023
Expires: 23 July 2023


                         Relay Flow Identifier
                 draft-chuang-relay-flow-identifier-01

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,
   relay flow identifier name 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 23 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 23 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 . . . . . . . . . . . . . . . . .   4
       1.2.2.  DKIM  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.2.3.  ARC . . . . . . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .   5
     1.4.  Security Considerations . . . . . . . . . . . . . . . . .   5
     1.5.  IANA Considerations . . . . . . . . . . . . . . . . . . .   5
   2.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

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.  Better yet, the
   receiver is enabled to cluster traffic to a spammer controlled domain
   and apply policies scoped to what the spammers have control over.

1.1.  Terminology and Definitions

   Acronyms






Chuang                    Expires 23 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 name for mail traversing a
   relay.  Typically the relay uses password authentication such as
   methods provided for in [RFC4954] but other methods MAY be possible.
   This identifier MAY also be used for authenticated forwarding flows
   such as mailing lists and with other authentication methods such DKIM
   or SPF that verify who the sender is.  Because some traffic may have
   originated at the relay, which traditionally may be DKIM signed, this
   document provides a specification for DKIM ([RFC6376]).  In other
   instances, the relay forwards traffic originated elsewhere, and these
   are typically not DKIM signed by the relay, so instead this document
   provides a specification using ARC ([RFC8617]).

   Email Service Providers can delegate relay and forwarding services to
   enterprise customers, typically associated with some customer domain.
   Spammers utilize these features either by acting as an enterprise
   customer or by hijacked accounts.  This specification proposes naming
   flows by enterprise customers to help the email receiver with
   categorization and application of anti-abuse counter measures.  As
   some mechanisms for mail forwarding such as mailing lists are often
   opaque after being sent and problematic for debug and abuse
   protection, this offers a naming scheme to help identify those
   mechanisms.





Chuang                    Expires 23 July 2023                  [Page 3]

Internet-Draft            Relay Flow Identifier             January 2023


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.  As relayed
   traffic flow is often associated with a delegated domain, the first
   part of the identifier MUST either include a domain associated url-
   safe base64 ([RFC4648]) token, or be empty if no such delegated
   domain is present.  It MAY include a local part url-safe base64
   ([RFC4648]) token after the domain token and separated by a period
   '.'.  This local part token can help describe the mail forwarding
   mechanism.  Combined the domain token and the optional local token
   form the relay flow identifier name.  If a message is associated with
   more than one flow, the relay SHOULD select the more specific flow
   based on local policy.  That name MUST not be any relay internal name
   though MAY be a secure cryptographic hash of such.  Also that name
   MUST not contain or be associated with any Personally Identifiable
   Information (PII).  The parser should ignore commas '+' whose use may
   be specified in the future.

   Example valid names:

   0123456789
   0123456789.abcdwxyz
   .abcdwxyz

1.2.2.  DKIM

   This proposes a new DKIM [RFC8617] DKIM-Signature tag-value that
   identifies the presence of a relay flow and a relay flow identifier
   name.  The tag is defined "rfid", while the value name consists of a
   domain url-safe base64 token and the optional local url-safe base64
   token separated by a period.  The token parsers MUST ignore a
   reserved plus 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=0123456789.abcdwxyz











Chuang                    Expires 23 July 2023                  [Page 4]

Internet-Draft            Relay Flow Identifier             January 2023


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 relay flow identifier name.  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 consists of a domain url-safe base64 token and the
   optional local url-safe base64 token separated by a period.  The
   token parsers MUST ignore a reserved plus that may be further
   specified in the future.

   Example:

ARC-Authentication-Results: i=1; auth.example.com; relay=pass (comments) policy.id=0123456789.abcdwxyz

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,
              <https://www.rfc-editor.org/rfc/rfc4648>.

   [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,
              <https://www.rfc-editor.org/rfc/rfc4954>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc6376>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/rfc/rfc7208>.





Chuang                    Expires 23 July 2023                  [Page 5]

Internet-Draft            Relay Flow Identifier             January 2023


   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/rfc/rfc7489>.

   [RFC8601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 8601,
              DOI 10.17487/RFC8601, May 2019,
              <https://www.rfc-editor.org/rfc/rfc8601>.

   [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,
              <https://www.rfc-editor.org/rfc/rfc8617>.

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 23 July 2023                  [Page 6]