On 8/11/2017 9:26 AM, Dave Crocker wrote:
Here's the task I see:
* Talk about ARC in non-technical terms, describing not just its
abstract goal but the nature of how it achieves those goals, in terms
of threats it is responding to, capabilities that it is responding
to, and limitations to those capabilities.
* This needs to include reference to the concept of 'trust' as an
operational attribute.
* There also needs to be statements about the operational history
upon which ARC builds -- that is, what is it doing that is
well-founded -- and what it is doing that is new.
* For the parts that are 'new', there needs to be statements the
provide explain why it is reasonable to be optimistic that deployment
and use will be safe and useful.
Possibly-useful examples that already showed up in this thread:
On 8/7/2017 4:22 PM, Seth Blank wrote:
ARC is about maintaining a chain of custody so that a final receiver
can be certain of which domains modified a message in transit. Like
DMARC, DKIM, and SPF, we're trying to ascertain if the message was
handled by the domain it said it was handled by - we're not passing
judgement on the contents of the messages itself.
On 8/7/2017 4:22 PM, Seth Blank wrote:
When validating an ARC signed message, one verifies the latest AMS
(which must validate), and *the entire chain* of ARC Seals, not only
the latest. This guarantees you a list of all message signatories -
the chain of custody we're talking about.
When evaluating the chain for final receipt, there are two states to
worry about as a matter of local policy: 1) you trust all the
signatories on the chain 2) there is an untrusted signatory on the
chain
In state #1, you're done - if you trust the signatories then you
trust they're not playing games with the AMS and AAR contents or
manipulating the message in malicious ways. Now you can make a
delivery decision as local policy dictates.
In state #2, you're also done - if you don't trust all the
signatories, then there are a multitude of routes for the message to
be garbage, including but not limited to everything you've outlined
above.
The critical thing about the ARC Seal is that it guarantees this
behavior in state #1 - if you trust all the d= values in the ARC
Seals, they all validate, and you have cv=pass, then you know for
certain everyone who has manipulated the message (and maybe some who
handled but did not modify).
Without the ARC Seal this determination is not possible and there is
no way to evaluate the ARC chain for delivery as a final receiver.
On 8/7/2017 7:41 PM, John Levine wrote:
Since it only makes sense to look at the ARC chain on mail that
comes from senders that are generally reliable, I've asked why you
don't just whitelist those senders and be done with it.
The answer, at least at very large mail systems, is that a mailing
list sends nice clean mail, but then it starts forwarding lots of
spam. I've seen this on some of the ICANN lists where someone got
his address book stolen that had both the lists and individuals'
addresses, so we're now getting mail through the lists with faked
addresses of a frequent participant. ARC passes along info from
previous hops so the recipient can retroactively do filtering that
the mailing list didn't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
