Since nobody else responded, here's my tl;dr -- interesting proposal, but no.
The first problem is that there is no appetite to change ARC at this point.
The other is that most if not all of the things you propose are not new.
I proposed a chained DKIM signaure that lets the signer say who's allowed
to forward and resign. No interest, for reasons that in retrospect I
think were good ones because it doesn't scale. Ale has been proposing
ways to undo list modifications for ages, again no interest.
I would suggest spending some time looking at the archives of this list
and related ones like DKIM and ietf-822 to see what has been proposed
before, so you don't waste your own time reinventing them.
Finally, while the IETF is very good at standardizing things that exist
and small tweaks, it is not great at inventing new things. That tends to
happen in other groups which for mail include M3AAWG and perhaps APWG. If
you're interested in this kind of work, you should look into getting
involved there, too.
R's,
John
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. +39 0185 799079
M. +39 348 5130136
E-Mail [email protected]
www.bertoldicybersecurity.com
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
