Session Date/Time: 22 Jul 2025 15:00

DKIM Working Group Meeting - IETF 123

Summary

The DKIM working group met to discuss three proposed drafts for DKIM enhancements: draft-crocker-dkim-decor, draft-boneh-dkim-header, and draft-niemi-peso-dkim-access-control. The primary focus was determining which approach should be adopted as the working group's main document. The discussion revealed convergence around core concepts like forwarding instance numbers and message transformation handling, with preference emerging for the bronze/headers approach due to its completeness. Significant debate occurred around compatibility with existing DKIM implementations, transition strategies, and the technical approach (component-based vs. unified solution).

Key Discussion Points

Draft Preferences and Technical Approaches

Convergence observation: All three drafts are iterating toward similar concepts, particularly adopting ideas from the bronze/headers draft
Bronze/headers draft preference: Multiple participants favored this approach due to:
- More complete solution addressing practical DKIM issues
- Better bounce handling mechanisms
- Institutionalized feedback mechanisms for ESPs
- Includes diff/delta functionality for message transformation tracking
Component vs. unified approach debate:
- Some advocated for divide-and-conquer approach focusing on individual functions
- Others argued for complete, integrated solution to prevent security gaps

Compatibility and Transition Concerns

Installed base compatibility: Strong emphasis on maintaining compatibility with existing DKIM infrastructure
Transition timeline: Discussion revealed adoption will take years to decades, not months
Implementation complexity: Multiple participants noted that implementation using existing DKIM libraries is feasible (weekend implementation reported)
Market pressure: Large providers (Google, Yahoo) expected to drive adoption through policy requirements

Header Signing Strategy

Current issues: Problems with selective header signing leaving security gaps
Proposed solution: Sign all headers except explicit exclusion list (trace headers)
Over-signing problems: Need to address issues where bad actors can add headers not covered by signatures
Delta/diff requirement: Necessary for verifying previous hop work and preventing replay attacks

Security and Anti-Abuse Considerations

Bad actor definition: Hosts that lie about validation or strip/re-add headers inappropriately
ARC limitations: Current ARC implementation described as "borderline useless" due to trust chain issues
Replay attack prevention: Delta functionality essential for detecting and preventing message replay attacks

Decisions and Action Items

Adopted Documents

Motivations document: Adoption confirmed, author to submit IETF version
Document organization: Agreement that motivations document may need reorganization and scope clarification

Technical Decisions Needed

Header signing approach: Continue discussion on signing all headers vs. selective signing
Diff/delta functionality: General agreement this is necessary component
DNS key compatibility: Preference for reusing existing DKIM keys to reduce adoption barriers

Action Items

Chairs to summarize discussion and present options to mailing list
Consider interim meeting if document adoption moves forward quickly
Address transition strategy in future applicability statement
Evaluate post-quantum cryptography requirements (out of current charter scope)

Next Steps

Short-term

Mailing list discussion: Chairs will summarize meeting outcomes and facilitate adoption decision
Document selection: Working group to decide between the three proposed approaches
Interim meeting: Potential interim before IETF 124 if adoption proceeds quickly

Medium-term

Additional documents: Consider adoption of diff/delta draft and DNS/bounce handling components
Implementation experience: Gather more implementation experience before finalizing applicability statement
Post-quantum considerations: Discuss whether to address post-quantum cryptography now or defer

Long-term

Transition planning: Develop comprehensive transition strategy as part of applicability statement
Industry coordination: Work with major email providers on adoption timeline and requirements
Standards progression: Move toward complete solution addressing all identified mail flow security issues

The meeting concluded with recognition that while technical convergence is emerging, significant work remains on adoption strategy and transition planning to ensure successful deployment in the existing email ecosystem.