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

[Hector Santos <[e-mail]>]

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

arc=none (or no arc= tag) means the domain has no interest whatsoever 
in ARC. It is a highly exclusive restricted domain and it expects that 
complaint DMARC readers will honor the policy.  No interference.  This 
is the highest payout with the highest security value.

It gets more relax with the others; first or last or first and last, 
but with arc=all it is a tougher condition that requires all seals to 
be valid.  If any fails, reject.

I would also try to get more bang for the buck with a tag that could 
informs MLS to honor the DMARC p=reject policy by restricting users 
from a) subscribing and b) submitting list mail from restricted 
p=reject domains, although I think such a tag is needed to tell the 
MLS this. It should be a requirement, imo, cross all the teas, dot all 
the eyes.  If the MLS knows its going to be problematic, it should 
restrict the subscription and submission to relax policies only.

-- 
HLS