Aggregate Reports for DKIM Signers
draft-brotman-dkim-aggregate-reporting-00

Network Working Group                                         A. Brotman
Internet-Draft                                              Comcast, Inc
Intended status: Standards Track                           26 March 2024
Expires: 27 September 2024

                   Aggregate Reports for DKIM Signers
               draft-brotman-dkim-aggregate-reporting-00

Abstract

   This document introduces a mechanism enabling DKIM-signing domain
   owners to solicit comprehensive aggregate reports from email
   receivers.  Presented in an XML format, these reports possess
   adaptable elements conducive for integration with current and future
   drafts and standards like DMARCbis.  They capture the evaluation
   outcomes of DKIM signatures, such as 'pass' or 'fail', alongside
   other potential data attributes.  Receivers can relay these aggregate
   reports to destinations designated by the DKIM-signing domain holder,
   contingent upon their support capabilities.

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 27 September 2024.

Copyright Notice

   Copyright (c) 2024 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

Brotman                 Expires 27 September 2024               [Page 1]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   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
   2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Enhancing Trust through DKIM-based Reporting  . . . . . . . .   3
   4.  Decoding DKIM Reports: Insights and Implications  . . . . . .   4
   5.  Configuring DKIM Aggregate Reporting: A Guide to DNS
           Records . . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.1.  Delegation of sending to Third-Parties: . . . . . . . . .   4
     5.2.  Receiving DKIM Aggregate Reports: . . . . . . . . . . . .   5
     5.3.  Third-Party Signature Considerations: . . . . . . . . . .   5
     5.4.  Feedback Suppression and Visibility:  . . . . . . . . . .   5
   6.  DNS Entry Format  . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Example DNS Entries for DKIM-based Reporting  . . . . . .   6
   7.  Dual (Or More) Signed Messages  . . . . . . . . . . . . . . .   7
   8.  Feedback Mechanisms . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  mailto  . . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Report Format . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Report Declaration  . . . . . . . . . . . . . . . . . . .   8
       9.1.1.  Published Policy  . . . . . . . . . . . . . . . . . .   9
     9.2.  Row Data  . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.3.  Report Metadata . . . . . . . . . . . . . . . . . . . . .   9
     9.4.  Extensions  . . . . . . . . . . . . . . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
     10.1.  Report Abuse . . . . . . . . . . . . . . . . . . . . . .  10
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  10
   12. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   With a growing emphasis on email security, the industry is rapidly
   adopting message authentication mechanisms such as DKIM and SPF.
   While many initiatives, including DMARC, aim to enhance message
   validation through their reporting features, they often fall short in
   meeting the diverse needs of all stakeholders in the email delivery
   process.  Moreover, these mechanisms aren't always effective in
   identifying certain abuses, like DKIM replay.

   A notable challenge arises with marketing and transactional messages,
   which often contain multiple valid DKIM signatures.  While DMARC
   reports can provide information to the 5322.From Domain holder, some

Brotman                 Expires 27 September 2024               [Page 2]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   DKIM signers may not receive a copy of that information.  This gap in
   information could result in a lack of understanding when there is an
   issue with authentication.

2.  Glossary

   *  DKIM (DomainKeys Identified Mail): An email authentication method
      utiilizing a cryptographic signature.

   *  DMARC (Domain-based Message Authentication, Reporting &
      Conformance): An email authentication mechanism that uses SPF and
      DKIM to verify the use of the domain in an email's visible From:
      header.

   *  SPF (Sender Policy Framework): An email authentication method
      using an IP-based configuration.

   *  Replay Attack: A malicious technique where an attacker intercepts
      and retransmits a valid data transmission, often to impersonate
      another user or entity.

   *  Selector: A string used by the DKIM system to help identify the
      DKIM public key information.

   *  GUID (Globally Unique Identifier): A unique reference number used
      as an identifier in software.

   *  DNS (Domain Name System): A system for converting human-friendly
      domain names into IP addresses.

   *  5322.From domain: The domain present in the "From:" field of an
      email, as defined in RFC 5322.

   *  Aggregate Report: Summarized feedback about messages purported to
      come from a specific domain during a specified period.

3.  Enhancing Trust through DKIM-based Reporting

   Visibility into DKIM signatures responsible for message
   authentication can be fairly important to system operators, perhaps
   more so when the signatures do not align with the 5322.From Domain.
   Allowing receivers to inform signers about potential validation
   errors could aid in resolving those issues, and allow for better
   authentication for the given message stream.

Brotman                 Expires 27 September 2024               [Page 3]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

4.  Decoding DKIM Reports: Insights and Implications

   The essence of DKIM aggregate reports is to furnish Signing Domain
   Owners with a thorough understanding of the following:

   *  Authentication Results: The outcomes from various verification
      checks provide an indication of how receivers evaluate the
      messages.  It's crucial for signing domain owners to comprehend
      the frequency of their successful authentications and pinpoint
      potential areas for improvement.

   *  Trust in Original Senders: Before applying signatures to future
      messages, signing domain owners need to evaluate the credibility
      and reliability of the submission entity.  If issues or
      inconsistencies arise in reports, it might signal that the
      original sender's practices aren't aligned with the signing domain
      owner's standards, leading to reconsideration of the signing
      relationship.

   OR

   *  Evaluation of Submitting Entity: Allowing the signing entity to
      understand if the signer would like to continue to sign on behalf
      of the submitter.  If the submitter has questionable practices,
      the signing may not wish to continue signing on behalf of that
      submitter.

   *  Indications of DKIM Replay: DKIM replay involves the malicious
      reuse of a previously signed email by unauthorized entities.  By
      identifying signs like SPF zone misalignment or unexpected volume
      discrepancies, signing domain owners can address potential threats
      and maintain the integrity of their emails.

5.  Configuring DKIM Aggregate Reporting: A Guide to DNS Records

   Email security necessitates clear and accurate configuration.  As
   domains employ authentication mechanisms, they must follow technical
   specifications, as well as best common practices.  Domain owners may
   choose to use their own resources for this, or utilize a third-party
   to assist them with various parts of the process or on-going
   operations.

5.1.  Delegation of sending to Third-Parties:

   To delegate DKIM signing to a third party, the domain owner must
   publish specific DNS TXT or CNAME records associated with the DKIM
   keys used by the third-party sender.

Brotman                 Expires 27 September 2024               [Page 4]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   Example: delegatedselector._domainkey.example.org TXT
   v=DKIM1;k=rsa;p=<data>

   _dmarc.example.org TXT v=DMARC1;rua=mailto:reports@example.org

   Here, delegatedselector is the selector.  As per DMARCbis,
   example.org will receive DMARC aggregate reports at
   reports@example.org.

5.2.  Receiving DKIM Aggregate Reports:

   For the third party DKIM signer to access DKIM aggregate reports, an
   additional DNS TXT record is required.

   Example: _report.delegatedselector._domainkey.example.org TXT
   v=RDKIM;tgt=mailto:reports@thirdparty.example

   Additionally, to prevent unsolicited reports and denial of service
   against third party receiving endpoints, report senders MUST check
   for the existence of a DNS record:

   Example: example.org._report._domainkey.thirdparty.example

   This ensures that the third party can retrieve the reports via email
   without receiving unsolicited reports.

5.3.  Third-Party Signature Considerations:

   Third-party senders might use additional signatures under their own
   domains to gather feedback about email quality.  A typical setup:

   selector._domainkey.thirdparty.example TXT v=DKIM1;k=rsa;p=<data>

   For the DKIM aggregate reports:
   _report.selector._domainkey.thirdparty.example TXT
   v=RDKIM;tgt=mailto:reports@thirdparty.example

5.4.  Feedback Suppression and Visibility:

   Sending domain (5322.From) owners might sometimes prefer to suppress
   feedback, minimizing any potential exposure of sensitive report data
   or to hide their malicious intent from the signer.  To maintain
   transparency and ensure that all parties (the domain owner and the
   third-party sender) have adequate visibility, report senders SHOULD
   transmit reports to all the specified reporting addresses.

Brotman                 Expires 27 September 2024               [Page 5]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

6.  DNS Entry Format

   There are a number of methods by which a domain can declare the
   intention to receive reports:

   v: This MUST be "RDKIM".  If this is absent, the record is invalid.

   tgt: The location(s) for reports.  Methods can be requested as
   mailto.  Be mindful that more than one can be requested but not all
   receivers will support all varieties.  Each mechanism has more detail
   below.  If a mistake in the record is found by the receiver, the
   entirety of the record should be ignored.

   rfr: This is a pointer to another domain to use their data.  May be
   used in conjunction with a tgt attribute.  This should take the
   format of the FQDN, i.e.,
   "v=RDKIM;rfr:_report.selector._domainkey.foo.com".

6.1.  Example DNS Entries for DKIM-based Reporting

   *  Basic Reporting

   _report.selector1._domainkey.example.org TXT
   "v=RDKIM;tgt=mailto:reporting@example.org"
   (mailto:reporting@example.org")

   *  Delegated Reporting (with referral record)

   _report.selector1._domainkey.example.org TXT
   "v=RDKIM;tgt=mailto:reporting@other.org"
   (mailto:reporting@other.org")

   example.org._report._domainkey.other.org TXT
   "v=RDKIM"

   *  Two destinations

   _report.selector1._domainkey.example.org TXT
   "v=RDKIM;tgt=mailto:reporting@example.org,mailto:reporting@elsewhere.
   com" (mailto:reporting@example.org,mailto:reporting@elsewhere.com")

   example.org._report._domainkey.elsewhere.com TXT
   "v=RDKIM"

   *  Only a referral

   _report.selector1._domainkey.example.org TXT
   "v=RDKIM;rfr:_report._selector1.domainkey.other.org"

Brotman                 Expires 27 September 2024               [Page 6]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   _report.selector1._domainkey.other.org TXT
   "v=RDKIM;tgt=mailto:reporting@elsewhere.com"
   (mailto:reporting@elsewhere.com")

   example.org._report._domainkey.elsewhere.com TXT
   "v=RDKIM"

7.  Dual (Or More) Signed Messages

   When a message has multiple signatures which verify, the reporter
   SHOULD send reports to all signatories who have requested reports.
   In the case where two (or more) signatures have the same destination
   tgt, this should still generate as many reports as there are valid
   signatures.

   NOTE, this needs to be expanded.

8.  Feedback Mechanisms

8.1.  mailto

   Similar to DMARC reports, data is aggregated and sent to the site
   daily.

9.  Report Format

   This format will be an XML file.

   A sample file:

Brotman                 Expires 27 September 2024               [Page 7]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   <?xml version="1.0" encoding="UTF-8"?>
   <feedback xmlns="urn:ietf:params:xml:ns:dkimaggreport-1.0">
       <report_metadata>
           <org_name>Reporter Company</org_name>
           <email>contact@receiver.net</email>
           <extra_contact_info>dest_domain: foo.net</extra_contact_info>
           <report_id>GUID_HERE</report_id>
           <date_range>
               <begin>151061515</begin>
               <end>151071241</end>
           </date_range>
       </report_metadata>
       <signature>
           <domain>example.org</domain>
           <selector>delegatedselector</selector>
       </signature>
       <record>
           <row>
               <source_ip>10.123.23.12</source_ip>
               <spf_domain>botnet.example</spf_domain>
               <spf_result>pass</spf_result>
               <spf_alignment>fail</spf_alignment>
               <dkim_passed>123</dkim_passed>
               <dkim_failed>1</dkim_failed>
               <dkim_alignment>true</dkim_alignment>
               <from_domain>example.org</from_domain>
               <extensions>
                 <extension def="https://site.com/ext_def">
                   ...
                 </extension>
               </extensions>
           </row>
           <identifiers>
               <sample_msg_id>uuid@bounces.example.org</sample_msg_id>
           </identifiers>
       </record>
       <extensions>
         <extension def="https://site.com/ext2_def">
           ...
         </extension>
       </extensions>
   </feedback>

9.1.  Report Declaration

Brotman                 Expires 27 September 2024               [Page 8]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

9.1.1.  Published Policy

   The domain is the domain from the d= in the original message
   signature, and the selector is from the s=.

   The time period for the report should be a single UTC day, and noted
   in the report body by the epoch timestamps with start and end.

9.2.  Row Data

   Each row should contain information so that the recipient can
   understand more about how their signature is being used, whether pass
   or fail.

   source_ip: The Internet Address responsible for delivery of the
   message.

   spf_domain: The domain used during SPF evaluation, whether the HELO
   string or the Return-Path.  Review [RFC7208].

   spf_result: Must be one of pass/fail/error.

   spf_alignment: Acceptable values are true/false.

   dkim_passed: The number of messages in this row for which DKIM
   evaluation succeeded.

   dkim_failed: The number of messages for which this DKIM signature
   could not be properly evaluated.

   dkim_alignment: Per the DKIM RFC, was the DKIM signature properly
   aligned with Sending Domain.  Values are true/false.

   from_domain: The 5322.From sending Domain.

9.3.  Report Metadata

   The subject of the report should contain a few key components:

   *  Selector - The value from the s= being reported
   *  Domain - The value from the d= being reported
   *  Date - format is YYYYMMDD
   *  GUID

   Format MUST be:

   Subject: <selector>:<domain>; <date>; <guid>

Brotman                 Expires 27 September 2024               [Page 9]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

   The GUID MUST be in a header for the report, called DKIM-Aggregate-
   Report-GUID.

9.4.  Extensions

   The report format allows for the possibility of extensions.  The
   extensions can be included within a row, or within the record.  The
   absence of these sections MUST NOT result in a processing error.  The
   party including the extension should include a URL to a definition of
   some sort.  This would aid report receivers in understanding how to
   best interpret the data.

10.  Security Considerations

10.1.  Report Abuse

   NOTE, needs to be more fully considered.  If we allow for an open
   target for real-time reporting, how does a report receiver ensure the
   sender is reputable?

   *  Report receivers need to deduplicate reports if multiple signing
      domains with feedback enabled is employed
   *  Report receivers should use DMARC logic to authenticate the
      reporter when deciding whether to trust the reports.  For example,
      allow-list the RFC5322.From address of trusted reporters only if
      the reports are sent with DKIM domain-aligned authenticated
      identifier
   *  Report senders should include a sample message-id
   *  Report receivers should look for a sample message-id to
      authenticate the report as being associated with a message it has
      sent recently

11.  Contributors

12.  Notes

13.  References

   1.  *RFC5322*: "Internet Message Format".  IETF.

   2.  *RFC6376*: "DomainKeys Identified Mail (DKIM) Signatures".  IETF.

   3.  *RFC7489*: "Domain-based Message Authentication, Reporting, and
       Conformance (DMARC)".  IETF.

   4.  *RFC7208*: "Sender Policy Framework (SPF) for Authorizing Use of
       Domains in Email".  IETF.

Brotman                 Expires 27 September 2024              [Page 10]
RFC draft-brotman-dkim-aDKIM-AGGREGATE-REPORTING              March 2024

14.  Normative References

   [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/info/rfc7208>.

Author's Address

   Alex Brotman
   Comcast, Inc
   Email: alex_brotman@comcast.com

Brotman                 Expires 27 September 2024              [Page 11]