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

[Bron Gondwana <[e-mail]>]

On Sat, 19 Aug 2017, at 04:10, Murray S. Kucherawy wrote:
> On Fri, Aug 18, 2017 at 10:08 AM, Dave Crocker
> <[e-mail]> wrote:>> On 8/18/2017 10:00 AM, Seth Blank wrote:
>>>
>>> Right now, we've got deployed code that we know works and improves
>>> the landscape. Everything else is - rightly or wrongly - conjecture.>> 
>> 
>> Personal Point of order:
>> 
>>     Using an 'installed base' argument for a brand new specification
>>     that is still in development and has minuscule deployment is not
>>     appropriate, in spite of having a long and storied history of
>>     being used to resist a proposal.>> 
>>     What's supposed to happen with a proposal is an evaluation of its
>>     technical and functional merits.>> 
>> 
>>  The entire point behind bringing a nascent specification to the IETF
>>  is to get review and suggestions from a wider audience.> 
> While I would normally agree firmly with that position, my view in
> this case is softer given what I believe was consensus (I'm not the
> chair, so that's not my call officially) that we're going to go for
> Experimental status.> 
> I submit that our primary mission here per our charter is to come up
> with a mechanism that mitigates DMARC's damage to mailing lists.  The
> claim that ARC as designed over-engineers a solution seems secondary
> to me; the question we need to answer is "Can this mitigate the
> damage?"  With or without Bron's reduced design, that's the question
> before us.
Yes, this is the crux of the question. 

> The "snake oil" claim may be true but it's orthogonal to that core
> question, and moreover points to the way we describe what exactly ARC
> provides ("chain of custody" is clearly not appropriate given that we
> are no longer sure what that actually covers), independent of whether
> it tells us enough to solve the question at hand.> 
> Accordingly, I would suggest we continue to deploy and experiment with
> the specification as-is, because there are implementations now, until
> we've determined that ARC as currently defined does or does not
> address DMARC's mailing list issues.  I also suggest that an appendix
> be added acknowledging that the super-crypto of ARC-Seal may be
> superfluous, and at the conclusion of the experiment we can make a
> decision about removing it and moving more toward what Bron's
> suggesting.> 
> Of course, the danger of proceeding along that line is that we do
> establish a deployed base, however small, that will be difficult to
> change later.  I don't know the answer to that question immediately,
> and admittedly I'm only going to be on the periphery of cleaning up
> whatever mess results.
Well, let's have a look at the question - can ARC mitigate the damage?
It depends what p=reject means.
Right now Brandon can't email this list with his [e-mail]
address, because google.com publishes a p=reject record.  If the
list supported ARC, he could email this list and receivers which
supported ARC would accept the email from the list despite the
p=reject record.  Yay.
I could also take a message from the list, rewrite the subject and
content to be my own, sign it with my own key from my own domain, send
that to somebody as it if had come from Brandon, and assuming they
supported ARC, they would also accept that email, depite the p=reject
record.  Boo.
p=reject no longer stopped me sending a fraudulent email claiming to be
from Brandon with a "From:" of his official work address.
The receving site now needs to run heuristics including content analysis
and trust metrics on every hop in the ARC chain to determine whether to
accept the message.  That's fine, but we've basically mitigated DMARC
breakage of mailing lists by rolling back the meaning of DMARC p=reject.
Anyone can create an ARC seal on any email.  It doesn't even have to
have an original ARC seal on it.  Attached is an email which purports to
be from Brandon and has a valid ARC-Seal on it (assuming my code works
correctly - it adds the c= parameter now after Seth pointed out that
opendkim doesn't handle leaving it out).  Somebody from Google might be
able to tell which email I based this on (an email on Aug 9th to this
list and CCd to me which then got resent from a different address)
This will be accepted by an ARC-aware receiver unless I'm on a
blacklist, despite the p=reject.
Creating a new domain and putting a key in its DNS is pretty trivial -
so I guess the question is, what is ARC  doing other than rolling back
DMARC p=reject entirely?  We'd better think about that deeply, because
spammers/scammers sure will be.
Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]