[dmarc-ietf] Extracting AAR information

[Brandon Long <[e-mail]>]

On Tue, May 9, 2017 at 5:39 PM, Seth Blank <[e-mail]> wrote:

> I've got two follow ups from Gene's notes on the proposed draft:
>
> 1. I am also confused by section 5.2, specifically the penultimate
> sentence in the section. I think - but am not certain - that I understand
> what is meant. I've suggested new language below to clarify.
>
> Original:
>
> "Of particular importance is the recording of the "i=2" instance of this
> field, which is the first available opportunity in the handling chain of
> the message to evaluate its apparent validity since departing its
> originating ADMD."
>
> Suggested:
>
> "Of particular importance is the first AAR header after an ARC signed
> message leaves its originating ADMD, which is generally but not always the
> "i=1" instance of this field. This instance contains the authentication
> information of first receipt which the ARC chain is establishing custody of
> to a final receiver."
>

This and other comments I've heard seems to put an undue benefit on the
first receiver.  I'm not sure that's warranted.

Ie, if you're hoping through a group that right now rewrites the From
header, the auth information in the first hop isn't the useful data for
validating DMARC.

Message from a REJECT domain -> mailing list which rewrites From and is a
different REJECT domain -> anti-phishing vendor which rewrites all urls to
bounce through them

In this case, the final recipient doing a DMARC check would see the From of
the mailing list and would need the i=2 (or maybe i=3, depending on whether
the mailing list service adds one or two headers) AAR to validate that the
auth for the mailing list domain.

(in reality, the anti-phishing vendor should be an inbound gateway and
dmarc shouldn't be evaluated, but it could be a hop through a second
mailing list.  An example recently had the anti-phishing get forwarded from
the edu domain to a user's personal gmail, so more hops)

The logic I'm looking at is more complicated.  If you assume a whitelist
model, where you are willing to use any information provided by a
whitelisted domain, then you basically walk the hops backwards, taking any
DKIM auth info given as long as the hop is whitelisted.

SPF is a bit different, because you don't want a message "acquiring" SPF
auth when it's relayed (I spoof a mail from a non-reject GSuite domain
through any service hosted at Google and it'll acquire that domain's SPF
auth, for example). So, as you walk backwards, you want an SPF fail/neutral
to override a pass. (Theoretically, you could use ARC to override the
current SPF evaluation as well.  This also assume you wouldn't ARC sign
during an initial MSA or RELAY hop, only when it hits a new ADMD).

And if you reach a hop where the AMS doesn't verify any more, you have to
stop evaluating at the next unwhitelisted hop, since the message could have
been completely modified by an unwhitelisted hop and a replayed chain used.

Now, most mail we'll see will be a single hop through a mailing list, and
so any rewriting will be handled by the new dkim signature or spf, and any
non-rewrites will be from the i=1 AAR.  If that's all we cared about, that
would just be the original XOAR spec as implemented by Google, it only ever
handled one hop.

Brandon