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

[Bron Gondwana <[e-mail]>]

On Sat, 19 Aug 2017, at 16:33, Hector Santos wrote:
> On 8/16/2017 8:21 PM, Bron Gondwana wrote:
>> On Thu, 17 Aug 2017, at 03:46, Hector Santos wrote:
>>> On 8/13/2017 10:28 AM, Kurt Andersen (b) wrote:
>>> 
>>>   On Sat, Aug 12, 2017 at 4:51 PM, Hector Santos wrote:
>>> 
>>>     If we even have a DMARC ARC Policy concept, than that may be
>>>     enough to begin pursuing the high cost of experimentation and
>>>     development here.
>>> 
>>> 
>>>   Beyond the protocol and usage specs, what are you looking for?
>>> 
>>> 
>>> A practical purpose for supporting (implementing) this work.   It
>>> appears ARC wants the network to stamp mail "blindly" as the mail
>>> travels from point to point.  I am trying to grasp how it helps
>>> resolve the main issue with "unauthorized" indirect 3rd party
>>> signatures, in particular when dealing with strong, exclusive DKIM
>>> signature policy models such as DMARC p=reject.
>> 
>> We spent a while thinking about this (Neil and myself from FastMail)>> at IETF99 after learning how ARC works, and came to the conclusion
>> that ARC as specified can't help with DMARC p=reject.
>> 
>> The only way you could even hope (as a mailing list) to avoid
>> rewriting the sender is for every site that currently has DMARC
>> p=reject to change that to a new policy which explicitly means "only>> reject if no ARC chain" - otherwise you can't stop rewriting sender
>> until you know that every receiver on your list is ARC-aware.
> 
> The MLS (Mail List Server) cam also reject submissions from
> restrictive (p=reject) domains because that MAY be the intent of the
> originating author domain.   The MLS can so prohibit new subscriptions> by verifying the user's domain is not restrictive.
> 
> We need more protocol information from what extracted from DMARC.  As> I see it, these are some of the boundary conditions:
> 
>     DMARC p=reject;  arc=none;       ignore ARC, same as no arc= tag
>     DMARC p=reject;  arc=all;        reject if any arc seals is
>     invalid>     DMARC p=reject;  arc=first;      don't reject if first arc seal is> valid
>     DMARC p=reject;  arc=last;       don't reject if last arc seal is> valid
>     DMARC p=reject;  arc=first,last; don't reject if first and last
> arc seals are valid

For what it's worth, the ONLY one of these which my "fake Brandon" email
would have failed to validate for is p=reject, arc=none.  A chain of
valid ARC seals is so easy to fraudulently create that it's not funny.
Everything other than arc=all there is totally pointless - if you can
intercept and modify email, you can easily add ARC headers that maintain
a complete chain is seals.
Now arc=site2.com,site3.com,site4.com - that's valuable.  You could say
"only allow ARC through the following intermediate domains" - and then
you could add those to your allowed list for your domain as you got
reports of validation failures and user requests.  Over time a domain
would build a list of mail flows that its users used.   You could even
use a different selector for each sending user, and publish a different
policy for that selector, so each user got their own allowed mail flows!
But anything that's based on count/position of seals in the chain, that
has no value.
Bron.


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