[dmarc-ietf] Proposal to Enhance Email Trustworthiness via RFC 8617 Modification - ARC

[Alessandro Bertoldi BCS <[e-mail]>]

Dear IETF Community,
 
I hope this email finds you well.
My name is Alessandro Bertoldi, and I am writing to you as an enthusiastic cybersecurity professional and the owner of a small, local email service provider. 
I have been following the development of email authentication protocols with great interest, particularly the work done on SPF, DKIM, DMARC, and the Authenticated Received Chain (ARC) protocol. 
As someone who is passionate about ensuring the trustworthiness and security of email communications, I have thoroughly studied RFC 8617 and believe that ARC has the potential to significantly enhance email authentication under certain circumstances.
 
Introduction: 
This proposal seeks to refine RFC 8617, which governs the Authenticated Received Chain (ARC), to bolster email authentication and trust management. ARC's reliance on intermediaries for maintaining authentication across hops, while beneficial under certain conditions, engenders a dependency on third-party entities. These entities can modify message headers and affix ARC signatures, all without the originating domain's oversight, potentially undermining the system's integrity.
 
Identified Issues:
* Dependency on Intermediaries: ARC's framework mandates trust in intermediaries not necessarily under the originating domain's purview, casting doubts on the authentication process's security and integrity.
* Absence of a Verifiable Trust Chain: Contrary to DNSSEC-like mechanisms, ARC lacks a transparent trust chain back to the origin, hampering efforts to independently ascertain the original authentication's legitimacy.
* Lack of a Standardized Trusted Server List: The current implementation of ARC relies on large providers like Google and Microsoft to maintain lists of trusted servers, which may not be accessible or suitable for smaller providers or self-hosted servers. Furthermore, the criteria and priorities used by these major providers to compile their trusted server lists may not always align perfectly with the needs of smaller or niche providers, raising concerns about transparency and impartiality.
 
Proposed Modifications: 
We suggest an amendment to RFC 8617 to empower the ARC sequence initiation right from the email's point of departure and to establish a standardized trusted server list. The modification encompasses:
* Crystallization of Initial Authentication State: Document the initial SPF, DKIM, and DMARC authentication status as the email exits the originating server, detailing the evidence necessary for authenticity verification.
* Documentation of Alterations: Mandate that any intermediary altering the message should annotate the specific changes made, thereby creating a verifiable chain of alterations leading back to the source.
* Facilitation of Independent Verification: Introduce a facility allowing recipients to independently verify the ARC's trust chain, thereby eliminating undue reliance on intermediary trust.
* Establishment of a Standardized Trusted Server List:
* Major email providers will maintain a publicly accessible list of trusted servers, regularly updated and serving as a reference for smaller providers and self-hosted servers.
* The list will adhere to a minimum set of standards, including categorization based on authentication capabilities and a machine-readable format for easy integration.
* To ensure transparency and impartiality, the process of compiling and maintaining these lists should involve input from a wide range of stakeholders, including smaller providers. Mechanisms should be in place for providers to contribute data, provide feedback, and appeal decisions related to the trusted server lists.
* Implementation Guidelines for Smaller Providers:
* Smaller providers and self-hosted servers can choose to rely on the standardized trusted server list, with the flexibility to supplement it based on their specific requirements.
* ARC implementations for smaller providers will include functionality to fetch and cache the trusted server list, compare intermediary authentication results against the list, and assign trust levels accordingly.
 
Implementation Details Draft: 
While the full specification of the proposed modifications will require further discussion and refinement with the IETF community, here is a high-level overview of key implementation aspects to be addressed:
* Standardized Trusted Server List:
* JSON format with mandatory fields (hostname, IP, authentication capabilities, trust score, last update)
* HTTPS REST API for access with rate limiting
* Daily updates and high availability ensured by list maintainers
* ARC Header Fields Extensions:
* New structured fields for initial SPF, DKIM, DMARC status
* Additional "ARC-Modifications" field to log changes by intermediaries
* Specification of required syntax and semantics
* Independent Verification Procedure:
* Recursive validation of ARC Sets starting from the outermost one
* Public key retrieval and signature verification for each ARC-Seal
* Signer trustworthiness check against the trusted list or local reputation
* Alignment check between ARC-Authentication-Results and initial status
* Modification audit based on ARC-Modifications vs. actual content
* Failure handling via informational tagging and DMARC re-evaluation
* Implementation Guidelines for Smaller Providers:
* MTA plugins and configuration templates for Postfix, Exim, Sendmail
* Trusted list fetching, caching, and processing scripts
* Testing and deployment best practices and checklists
* Staged migration plan with monitoring and rollback capabilities
* Success Metrics:
* ARC adoption rate among trusted servers
* Percentage of messages with valid ARC chains
* DMARC pass rate impact
* Qualitative feedback via participant surveys
*  
Expected Benefits:
* Empowerment of Domain Owners: This amendment aims to curtail reliance on intermediaries for authentication handling, mitigating unauthorized message alterations' security risks. Domain owners gain enhanced control over their message security.
* Establishment of a Verifiable Trust Chain: By documenting the authentication outset and successive adjustments, a level of transparency and verifiability hitherto absent in ARC is achieved. This promotes easier origin identification and transit modifications' verification.
* Broadened Inclusivity: The proposed hybrid approach, involving a standardized trusted server list with input from major providers as well as smaller operators, ensures that the system caters to the needs of the entire email ecosystem. By providing guidelines and tools for implementation, this proposal democratizes ARC adoption and enables entities of all scales to benefit from enhanced authentication capabilities.
* Improved Consistency and Reliability: The introduction of a standardized trusted server list ensures a consistent reference point for all providers, enhancing interoperability and reducing fragmentation in ARC implementations.
 
Conclusion: 
Our proposal aims to advance the ARC framework towards a more secure, transparent, and verifiably trustworthy email ecosystem, drawing parallels with DNSSEC's principles. By incorporating a standardized trusted server list and allowing for a hybrid approach that balances the inputs of major providers with the needs of smaller operators, we seek to create an inclusive and robust authentication system. The proposed modifications, including crystallization of initial authentication state, documentation of alterations, independent verification mechanisms, and implementation guidelines, work together to provide a comprehensive upgrade to the existing ARC protocol.
Recognizing the collaborative nature of this endeavor, we invite the IETF community to deliberate on and assess this approach to enhance email authentication. We look forward to engaging in constructive discussions, refining the proposal, and working towards a more secure and trustworthy email ecosystem for all.
 
Best regards, 
Alessandro Bertoldi


"Empowering your business with cutting-edge cybersecurity solutions, 
safeguarding your digital assets and ensuring a seamless, secure experience for your customers."
BertoldiCybersecurity
Alessandro Bertoldi

Owner
T. [phone]

M. [phone]
E-Mail [e-mail]
www.bertoldicybersecurity.com