Markdown Version | Transcript | Session Recording | Session Materials

DKIM

Summary

The DKIM Working Group met at IETF 118 to discuss the progress of DomainKeys Identified Mail Signatures v2 (DKIM2). The session included a Hackathon report, a detailed review of open technical issues within the core protocol specification (draft-ietf-dkim-dkim2-spec), deployment concerns for the best practices document (draft-ietf-dkim-dkim2-bcp), and a proposal to handle trace headers.

Key Discussion Points

1. Welcome and Agenda Bash

Chairs Pete Resnick and Murray Kucherawy opened the meeting and presented the Chair slides. The agenda was updated to add a discussion on trace headers led by Bron Gondwana and a brief AOB on feedback loops raised by John Levine.

2. Hackathon Report

• Bron Gondwana reported on development work leading up to the Hackathon. He noted that Received-SPF was identified as an issue on his testing systems due to headers being dynamically added. He has established a weekly Zoom meeting to coordinate DKIM2 interop testing.
• Mauro Escalante announced that he implemented DKIM2 in the Rust-based mail-auth library and the Stalwart mail server. He created a Docker-based test matrix for cross-testing multiple implementations (including Bron Gondwana's and Steve Atkins' Go implementations). The only minor issue identified was related to message folding. The Docker containers will be moved to the official working group repository.

3. Issues Discussion

Richard Clayton presented the Issues Discussion slides, covering several open items in draft-ietf-dkim-dkim2-spec and draft-ietf-dkim-dkim2-bcp.

• Null Recipes for Header Fields in DSN Generation: In draft-ietf-dkim-dkim2-spec -04, null recipes for header fields were removed because no valid use cases were found (unlike null recipes for bodies). Since no use cases were presented by the working group, the decision to exclude them remains.

• Extraneous Message Instances (Must Not vs. Discourage): The current specification draft contains "must not" language regarding the generation of unnecessary message instance header fields. To address interop issues where strict parsers bounced valid messages containing empty instances, Pete Resnick suggested downgrading "must not" to a recommendation (discouraging unnecessary instances to save processing overhead/prevent "heating up the planet").

  • Bron Gondwana suggested implementing a maximum limit on message instances (e.g., 255) and DKIM2 hops.
  • Richard Clayton and Alexey Melnikov suggested lower, more practical limits, such as 15 or 31, aligning with typical SMTP Received header count limits.
  • Outcome: The "must not" language will be removed in favor of discouragement. The specific maximum hop/instance limits will be debated and finalized on the mailing list.

• Post-Quantum (PQ) Cryptography Integration: The working group is working toward selecting a PQ algorithm to insert into the specification.

  • Richard Clayton raised concerns about key sizes and running DNS over UDP, referencing ongoing discussions in the DNSOP working group about increased TCP usage.
  • Wei Chuang updated the group on a proposed problem statement drafted for CFRG/security experts (specifically Paul Wouters).
  • Barry Leiba, Bron Gondwana, and John Levine discussed whether all signatures/algorithms on a given instance are required to pass. The group agreed that a verifier should only be required to validate algorithms it understands; if an unknown algorithm is encountered, it must be ignored for interop, but any validated signatures must pass.
  • Outcome: The group will refine the problem statement to consult with security area experts and aim to select an algorithm by the next IETF meeting.

• Lowercasing JSON Header Field Names: Richard Clayton proposed that all header field names in the JSON recipes must be lowercase to simplify parsing and matching.

  • Outcome: No objections were raised. This requirement will be integrated into the next draft.

• Receipts and Certifications (DSN Detection Flag): The group discussed whether a specific flag should be added to the DKIM2 signature header to signal that a message is a DSN.

  • Mauro Escalante and Bron Gondwana agreed that parsing the MIME content-type (multipart/report) is sufficient to identify DSNs, making a new flag redundant.
  • Outcome: No new flag will be added.

• Alignment in DKIM2 BCP: The group discussed whether draft-ietf-dkim-dkim2-bcp should require strict alignment between the RFC 5322 From header, the RFC 5321 Mail From envelope, and the DKIM2 d= domain.

  • Alan Robinson highlighted the need for DMARC to recognize DKIM2 to enforce alignment policies.
  • John Levine and Jim Fenton raised concerns about legacy mailing lists that rewrite the From header.
  • Alan Robinson, Richard Clayton, and Bron Gondwana clarified that this alignment requirement only applies to hop 1 (the originator) and that DKIM2 recipes allow receivers to roll back modifications to verify the original aligned state.
  • Outcome: The core protocol (draft-ietf-dkim-dkim2-spec) will remain silent on From alignment, and these guidelines will be documented in draft-ietf-dkim-dkim2-bcp.

• Handling DKIM1 Messages: Richard Clayton outlined recommendations for DKIM2-aware nodes handling inbound DKIM1 messages:

  • Mailing lists should sign with DKIM2 to safely handle bounces.
  • Standard forwarders should not sign with DKIM2 due to replay and reputation risks.
  • Submission servers should strip DKIM1 and initiate a clean DKIM2 chain.
  • Outcome: There was general agreement with these principles, which will be incorporated into draft-ietf-dkim-dkim2-bcp.

• Feedback Loops (FBL): Richard Clayton asked if there was interest in standardizing FBL protocols.

  • Alan Robinson, Bron Gondwana, and John Levine noted that while FBL standardization is valuable, it is out of scope for the DKIM WG and should not block the core DKIM2 specifications.
  • Kenneth Murchison and Alexey Melnikov noted that draft-brotman-dkim-fbl is currently being tracked by the MAILMAINT working group.
  • Outcome: FBL standardization is deferred. The privacy protection flags currently in draft-ietf-dkim-dkim2-spec -04 will be retained.

4. Trace Headers

Bron Gondwana presented the Trace Headers slides. He reviewed headers that act like trace fields (such as Received-SPF, Authentication-Results, and Delivered-To) which should be skipped during DKIM2 signature verification.

• IANA Registry Updates: Bron suggested updating the central IANA registry to accurately tag these headers as trace fields.
• Trace/Vendor Prefixes: To prevent future headers from breaking DKIM2 verification, Bron proposed reserving Trace- and Vendor- prefixes so that conforming parsers automatically skip them.
• Discussion:
  • Alexey Melnikov suggested that registry maintenance should remain separate from his active email core work.
  • Andrew Newton (AD) and Kenneth Murchison indicated that the MAILMAINT working group is the appropriate venue for updating the registry.
  • Jim Fenton and Alexey Melnikov expressed skepticism about tying semantics directly to a naming prefix.
  • Outcome: Bron Gondwana will split the work into two documents: an informational document targeting MAILMAINT to update the IANA registry, and a separate standards-track proposal for the prefix-skipping behavior.

Decisions and Action Items

Next Steps

• The chairs will coordinate a virtual interim meeting to continue resolving outstanding issues before the next face-to-face meeting.

Related Documents

draft-brotman-dkim-fbl, draft-ietf-dkim-dkim2-bcp, draft-ietf-dkim-dkim2-spec