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

[Hector Santos <[e-mail]>]

On 8/19/2017 3:48 AM, Bron Gondwana wrote:

> 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.

I agree. That is what the ATPS (Authorized Third Party Signature) and 
the ASL (Authorized Sender List) proposals was all about.

      https://tools.ietf.org/html/rfc6541

Check out this wizard that helps generate the appropriate ATPS records 
and/or ASL extended DMARC tags:

     http://www.winserver.com/public/wcdmarc/default.wct

But many feel it doesn't scale.  We also called it a "registration" 
problem, i.e. how to get that authorized list, etc.   What has been 
going since then is to develop a method to inherently pass this 
information via the headers.  Thats been hard to understand since we 
are already making a DMARC DNS lookup that perpetuates all this.   We 
are just not getting enough information to properly work with it.

> 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.

I fully concur with the "level of "experimentations" that would give 
all parties, a payoff they can realize and the capability to design a 
logical integrated system and negotiate3ed protocol without kludges 
and also apply some  "Deep Learning" to help with the indeterminate 
conditions.

We have determinate conditions with the strong policies.  These MUST 
be honored or nothing works. This is the DKIM POLICY LAYER MODEL. The 
indeterminate conditions are the relaxed policies leaving it up to the 
receiver to explore algorithms. This is the DKIM TRUST/REPUTATION 
LAYER MODEL.  The DKIM standard purposely removed the Policy Layer 
with the hope the trust layer would prevail.  Many folks did not like 
this decision. It was extremely rough and we didn't have other 
developers, such as yourself around.

But as expected, it didn't happen and the problems we are seeing is 
due to that separation.  That said, I still expect it to happen 
because Policy gives us the first level automation (thanks to DMARC), 
and Trust/Reputation is the 2nd level to help with the fuzzy 
conditions. This is where it will be a vendor-based added value 
component to DKIM, as it was designed to be and should be. But as it 
was always stated, not everyone is going to use the same 
"Trust/Reputation" databases.  I called that the "Batteries Required" 
dilemma.

-- 
HLS