On 8/11/2017 8:19 PM, Bron Gondwana wrote:
On Sat, 12 Aug 2017, at 10:04, Dave Crocker wrote:


by 'strategy DKIM uses' what do you mean exactly?  I'm guessing you mean
having the signature cover more of the header and all of the body, but
please confirm or clarify.

Sorry - yes, to clarify...

DKIM signs the entire body plus parts of the header.

In the strategy I am proposing, site "X" modifying a message in
transit (e.g. a mailing list) would add their own DKIM-like header
(ARC-Message-Signature is a perfectly fine name for it) which signed
the new "body and parts of the header", including a statement that
site "X" had verified the message authentication before modifying it
(ARC-Authentication-Results is a perfectly fine name for that statement).

That gives a complete chain of custody.

Its a great idea.... but it still suffers from the long time 3rd party signature registration problem. This is why we are here. All the DKIM policy models, including DMARC with a p=reject policy) suffered this issue. ARC is suppose to save 3rd party signed indirect messages.

The "Arc-Authentication-Results" header can claim this but it still be phishing, forged mail -- no trust at the downlink receiver level and/or MUA client when DMARC p=reject rejection results are seen.

What is needed is the Originating Domain making this claim that authorizes X as a legitimate modifier. We can either lookup that information (ATPS, https://tools.ietf.org/html/rfc6541) or we pass it as a new DKIM-signature. Levine had a DKIM Conditional proposal that does this. It wasn't a lookup concept, which I prefer, but Levine's idea was the next best option that touches base with a "3rd Party Authorization" concept:

   https://tools.ietf.org/html/draft-levine-dkim-conditional-02
   Abstract

   This experimental specification proposes a modification to DomainKeys
   Identified Mail (DKIM) allowing advertisement of third-party
   signature authorizations that are to be interpreted as equivalent to
   a signature added by the administrative domain of the message's
   author.

I'm not against ARC other than it seems like complex, overhead that doesn't address the main issue of authorized 3rd party routes. 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.

--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to