Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Dave Crocker <[e-mail]>]

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