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
