Wei,
Have you studied the past R&D and functional specifications,
architectural surrounding SPF and DKIM leading up to DMARC?
RFC5598 Internet Mail Architecture
RFC5322 Internet Message Format
RFC5321 Simple Mail Transfer Protocol
RFC4405 SUBMITTER SMTP Service Extension
RFC4406 Sender ID: Authenticating E-Mail
RFC4407 Purported Responsible Address (PRA)
RFC4408 Sender Policy Framework (SPF)
RFC4686 Analysis of Threats Motivating DKIM
RFC4870 DomainKeys
RFC4871 DKIM (RFC5672.TXT, RFC6376.TXT)
RFC5016 Requirements for a DKIM Signing Practices Protocol
RFC5451 Message Header Field for Indicating Message
Authentication Status
RFC5518 Vouch By Reference
RFC5585 DKIM Service Overview
RFC5617 DKIM Author Domain Signing Practices (ADSP)
RFC5863 DKIM Development, Deployment, and Operations
RFC5965 An Extensible Format for Email Feedback Reports
RFC6376 DomainKeys Identified Mail (DKIM) Signatures
RFC6377 DomainKeys Identified Mail (DKIM) and Mailing Lists
RFC6541 DomainKeys Identified Mail (DKIM) Authorized Third-Party
Signatures
I find it technically unfeasible and non-logical to support a high
overhead, complex ARC concept that has no promise of any solution for
a DKIM Policy model we have been seeking since 2005.
What are we solving in the first place with ARC? The ability to
revert to original integrity due to unknown middle wares changes? What
ever happen to passthru mail transports?
In my technical view, it has been the PORT 25 unsolicited 3rd party
signature unauthorized by the author domain due to the dearth of
scaled AUTHOR::SIGNER Authorization methods. ARC is not resolving
this problem. The overhead is horrendous.
We have been seeking deterministic protocols to filter out failures
with zero to low false positive. Diffusion by Osmosis!
We don't have it today. It has been made more complex than it really
is. I recommend to study the past work.
Thank you.
--
Hector Santos, CEO/CTO
Santronics Software, Inc.
On 5/15/2023 5:02 AM, Wei Chuang wrote:
That's a good point around ARC as that's what it was meant to do.
And that got me thinking that it might be helpful to systematically
compare the different proposed approaches and their pros and cons.
The next approach would be to consider the general approach of the
reversible transform idea that several folks have proposed, and how
that would look. And that got me rethinking the "DARA" work that
we're already prototyping for DKIM replay mitigation, if it can
relate to mailing-list and forwarder modifications and I now think
DARA can help here too. The three different approaches have distinct
pros and cons.
The following is a summary of the comparison. Attached is a more
detailed comparison as PDF that tries to work through what the
algorithms would likely do.
ARC
Use ARC to override the SPF and DKIM results at Receiver by those
found at the Forwarder.
Pros:
*
Uses existing SPF, DKIM and ARC standards.
*
Tolerates header and body modifications
Cons:
*
Receiver must trust the ARC headers generated by the forwarder.
*
Receiver must trust the modifications the forwarder made.
*
Receiver must trust that no ARC replay occurred
Transform
Proposed in draft-kucherawy-dkim-transform
<https://datatracker.ietf.org/doc/draft-kucherawy-dkim-transform/02/>where
the forwarder can specify a "tf=" tag that specifies addition of
Subject header prefix, text footer to a mime-part, mimify plaintext,
and adding a mime-part representing a footer to an existing
mime-tree to the DKIM-Signature. These all may be reversed to
recover the original signature.
DKIM-Signature: d=...; tf=subject,mime-wrap,
The ideas in draft-vesely-dmarc-mlm-transform-07
<https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform-07>are
conceptually similar though add support for ARC.
Pros:
*
Tolerates header and body modifications
*
Identifies the modifications
*
Does not require particular trust of the forwarder to be
non-malicious
Cons:
*
Receiver must trust that no DKIM replay occurred
*
Might not compose across multiple modifying forwarders
*
Might not support all possible modifications by forwarder
*
Reversing all possible draft transformations is potentially
complicated
DARA
This clarifies the DARA ideas in draft-chuang-replay-resistant-arc
<https://datatracker.ietf.org/doc/draft-chuang-replay-resistant-arc/>which
calls for authenticating a path from the Originator through the
Forwarder to the Receiver that's tolerant of modifications. Some
ideas of a validated path are explored in
draft-levine-dkim-conditional
<https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional-04>.
Pros:
*
Tolerates header and body modifications
*
Does not require particular trust of the forwarder to be
non-malicious
*
Supports arbitrary many forwarders that may modify the message
*
Supports protocol unaware participants
Cons:
*
Requires DNS policy lookup on outbound delivery
*
Requires additional messages DKIM signing to support
Bcc/Mailing-list recipients (each get their own signed copy)
*
Builds upon ARC which is considered complicated
-Wei
On Sat, May 6, 2023 at 7:42 AM John R Levine <jo...@taugh.com
<mailto:jo...@taugh.com>> wrote:
> It is not a commitment at this time. That said, we are
interested in
> solving this problem and welcome collaboratively figuring out
the right way
> to do this.
It seems to me that ARC provides the useful parts of third party
signatures and, while rather complicated, has the benefit of
actually
existing. The chain of authority runs from the relay host back
to the
original rather than the other way around, but that's a lot
easier to do
mechanically.
Regards,
John Levine, jo...@taugh.com <mailto:jo...@taugh.com>,
Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
