**Session Date/Time:** 21 Mar 2025 02:30

# DKIM Working Group Session

## Summary

The DKIM working group held its first in-person session to discuss DKIM2, a proposed new protocol to address limitations in the current DKIM implementation. The session covered working group procedures, charter goals, and detailed technical presentations on three proposed documents addressing DKIM replay attacks, backscatter mitigation, and message forwarding challenges. Key discussion points included the requirement for one recipient per message, signature validation across message modifications, and interoperability between DKIM1 and DKIM2 systems.

## Key Discussion Points

### Working Group Operations and Charter
- **Code of Conduct**: Working group will be stricter on code of conduct enforcement given potential contentious discussions in email authentication space
- **Compatibility Requirements**: Solutions must not break existing deployed email infrastructure; incremental upgrades preferred over disruptive changes
- **Charter Goals**: Four main problems to solve:
  - Maintain validation of signatures across forwarding modifications (with abuse-resistant methods)
  - Solve DKIM replay problem
  - Address backscatter concerns
  - Provide better visibility into resulting errors
- **Scope Limitations**: Email core protocols (SMTP) are out of bounds; focus strictly on charter-defined problems

### Technical Architecture Decisions
- **One Recipient Per Message**: Extensive debate on requiring single recipient per message to prevent BCC address leakage and enable proper replay detection
  - Data from Yahoo/Gmail shows >99% of messages already go to single recipients
  - Corporate email with attachments to multiple recipients identified as edge case
  - Privacy preservation for forwarding requires this restriction
- **DKIM2 vs DKIM1 Headers**: Decision to use separate header field rather than extending existing DKIM-Signature header to avoid breaking existing validation systems
- **Signature Per Hop**: Each forwarding hop must add its own signature to create ordered chain of modifications

### Message Modification Handling
- **Modification Algebra**: Proposal for powerful but receiver-friendly algorithm to describe message changes
  - Copy instructions to recreate earlier message versions
  - Supports complex modifications while remaining simple for validators
  - Discussion on whether to support simple common cases vs. full flexibility
- **Canonicalization**: Strong preference for strict body canonicalization (not relaxed) since bodies will be processed in memory for modification algebra
- **Header Signing**: Proposal for mandatory header list based on best practices rather than sender choice

### Interoperability and Deployment
- **DKIM1 to DKIM2 Upgrade Path**: Discussion of mechanisms to detect DKIM2 support and handle transitions
  - DNS lookup or SMTP extension detection proposed
  - Challenges with caching capability information
  - Potential for double-signing during transition period
- **Backscatter Prevention**: Bounce messages must be cryptographically verifiable and follow same path as original delivery
- **Fragmentation Concerns**: Acknowledgment that deployment may create email ecosystem fragmentation but consensus this is acceptable trade-off

### Implementation and Testing
- **Experimental Header Names**: Recommendation against experimental header names due to historical problems with migration
- **Early Implementation**: Multiple parties expressed interest in implementation and testing once specifications stabilize
- **Crypto Agility**: Post-quantum cryptography mentioned as future consideration but not core requirement

## Decisions and Action Items

### Immediate Actions
- **Document Adoption**: Consensus to proceed with adoption call for three proposed documents:
  - Problem statement and overview document (informational)
  - Technical specification documents (standards track)  
  - Applicability statement (standards track)
- **Header Requirements**: Richard Clayton to provide list of mandatory headers for signing based on best practices
- **Bounce Handling**: Alan (remote participant) to contribute bounce message format specifications

### Technical Decisions
- **Single Recipient Requirement**: Working group consensus to proceed with one recipient per message requirement
- **Separate Header Field**: Use new header field name rather than extending DKIM-Signature
- **Strict Body Canonicalization**: Preference established for strict rather than relaxed body canonicalization

## Next Steps

### Short Term (Before Madrid IETF)
- **Interim Meetings**: Plan for 2-3 interim meetings, with first meeting targeted for second half of April 2024
- **Specification Lockdown**: Finalize header requirements, modification algebra format, and mandatory signing requirements to enable interoperability testing
- **Implementation Phase**: Begin interoperability testing once core specifications are stable

### Design Space Exploration
- **Testing Priorities**: Focus initial testing on core functionality (replay prevention, modification handling) before advanced features (feedback mechanisms, crypto agility)
- **Capability Detection**: Develop mechanisms for detecting DKIM2 support in receiving systems
- **Transition Strategy**: Define approach for coexistence and migration from DKIM1 to DKIM2

### Documentation Requirements
- **Decision Rationale**: Document reasoning behind design decisions for future reference
- **Security Considerations**: Address potential abuse scenarios including mailing list impersonation
- **Deployment Guidance**: Provide clear guidance for staged deployment and interoperability

The session concluded with strong momentum for moving forward with the DKIM2 proposal, pending resolution of remaining technical details and successful interoperability testing.