**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.