Subject: [dmarc-ietf] ARC-Authentication-Results

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Apr 2017 16:49:39 -0700

The latest ARC base document says this about the ARC-Authentication-Results
field:

   ARC-Authentication-Results is a direct copy of the Authentication-
   Results header field [RFC7601
<https://tools.ietf.org/html/rfc7601>] created for archival purposes
by the
   each MTA outside of the trust boundary of the originating system
   which is contributing to the chain of ARC header fields.  The
   corresponding instance ("i=") tag value MUST be prefixed to the
   Authentication-Results.

Apart from the grammatical glitch ("the each"), this appears to me to be
saying:  "Collect the contents of the A-R fields that already exist and
re-record those results into a new A-A-R field."

Should that include the results computed by the ADMD that's doing this work?

Either way, is this even possible?  Since A-A-R is (apart from the "i="
tag) syntactically identical to an A-R (RFC7601) header field, and an A-R
field has a single authserv-id, and the authserv-id is presumably integral
to the final recipient deciding whether to trust the message, what does an
implementer do with this?:

A-R: admd1; dkim=pass header.d=example.com
A-R: admd2; dkim=fail header.d=example.com

What A-A-R am I supposed to generate from that?  Does order matter?  It
seems to me that, at a minimum, the name(s) of the ADMD(s) will be lost;
assuming that's okay, here's what I get:

A-A-R: i=N; my-authserv-id; dkim=pass header.d=example.com; dkim=fail
header.d=example.com

As a final recipient, I'd have no idea what to do with that.

Confused,

-MSK

---

From: Brandon Long <[email-masked]>
Date: Mon, 3 Apr 2017 17:21:45 -0700

My goal for this is that you would only collect the auth-res header for the
same admd and the same delivery step as is doing the arc-signing.

Ie, if you assumed that there was a single Auth-Res header added during the
smtp phase, you would copy that authres header.  I realize with the
milters, there are often multiple ones for each one, so you would collect
all the ones for this admd and hop.

So, in your example, if you are admd1, then you only include that one.

An interesting question is what to do when re-signing, ie on the outbound
side of mailing list expansion.  For us, we just copied the inbound aar to
the next "hop".  You could also imagine that an outbound hop could remove
and replace the inbound hop, and re-use the AAR.

Since you are only allowed one "set" of AuthRes per authserv-id, presumably
somewhere in the milter chain, all the existing authres headers for that
admd would be removed, prior to new ones being added, so if you collect all
of the existing ones for your admd, that should be fine.

Brandon

On Mon, Apr 3, 2017 at 4:49 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> The latest ARC base document says this about the
> ARC-Authentication-Results field:
>
>    Results header field [RFC7601 <https://tools.ietf.org/html/rfc7601>] created for archival purposes by the
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Apr 2017 17:21:56 -0700

> As a final recipient, I'd have no idea what to do with that.

I'd be happy to propose alternative text to what's there, but first I'd
like to understand what the downstream receivers want to get out of it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Apr 2017 17:25:16 -0700

On Mon, Apr 3, 2017 at 5:21 PM, Brandon Long <[email-masked]> wrote:

> My goal for this is that you would only collect the auth-res header for
> the same admd and the same delivery step as is doing the arc-signing.
>
> Ie, if you assumed that there was a single Auth-Res header added during
> the smtp phase, you would copy that authres header.  I realize with the

I'm wondering if I'm admd3 and there are A-Rs from admd1 and admd2, what do
I add?  Just mine?  Theirs and mine?  How do I combine them, especially if
they disagree?

> Since you are only allowed one "set" of AuthRes per authserv-id,
> presumably somewhere in the milter chain, all the existing authres headers
> for that admd would be removed, prior to new ones being added, so if you
> collect all of the existing ones for your admd, that should be fine.
>

OK so you're only adding your own here?  If that's the case then the
existing text is quite wrong because it's talking about collecting all the
results form "each MTA outside of the trust boundary of the originating
system" which to me means everything prior to you.

-MSK

---

From: Steven M Jones <[email-masked]>
Date: Mon, 3 Apr 2017 17:36:54 -0700

On 04/03/2017 16:49, Murray S. Kucherawy wrote:
> Apart from the grammatical glitch ("the each"), this appears to me to
> be saying:  "Collect the contents of the A-R fields that already exist
> and re-record those results into a new A-A-R field."
>

My POV, there is a strong 1:1 correlation between a set of ARC headers
and a given ADMD. In this world view, the A-A-R would *not* collect all
A-R values from all preceding ADMDs.

The A-A-R attached by a given ADMD is meant to include the A-R value
computed by that ADMD during receipt/validation of the message in
question. So I would suggest language more like the following for
5.1.3's first paragraph:

    "ARC-Authentication-Results is a copy of the Authentication-Results
    header field [RFC7601] created during the receipt/validation of the
    message by an ADMD from a source external to that ADMD. In other
    words, a message is received by an ADMD and has an A-R computed and
    attached to the message. When an ADMD is creating an A-A-R, it takes
    the contents of the A-R header created by the same ADMD, prefixes it
    with the appropriate instance ("i=") tag value, and records it in
    the A-A-R."

This probably needs language to handle the case where a given ADMD
creates multiple A-R headers, at minimum. But before tackling that,
let's have any objections to the general sense of the above paragraph,
or the assertions before it?

--S.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Apr 2017 17:42:53 -0700

On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones <[email-masked]> wrote:

> My POV, there is a strong 1:1 correlation between a set of ARC headers and
> a given ADMD. In this world view, the A-A-R would *not* collect all A-R
> values from all preceding ADMDs.
>

It depends on what the goal is.  If you only want to record what the ADMD
itself directly evaluated, your proposal is fine.  If you want to record
what the ADMD thinks prior ADMDs claimed (e.g., GMail saying "Yahoo! claims
this was fine when they got it"), then we must go deeper.  But I don't know
if that's what's actually needed, or would even be useful, or how one would
evaluate the meaning of such an indirect claim without a lot of reputation
data.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Apr 2017 00:47:24 +0000

>evaluate the meaning of such an indirect claim without a lot of

I'm also not clear why we need a new header field.  Why can ARC be a new method for A-R?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Apr 2017 18:16:23 -0700

> I'm also not clear why we need a new header field.  Why can ARC be a new

The idea, as I understood it, is for AAR to record what a particular ADMD
saw at ingress from DKIM and SPF (and maybe others), not to record what the
ARC result is.  The ARC result is in the ARC-Seal.

(How's that for acronym soup?)

-MSK

---

From: Steven M Jones <[email-masked]>
Date: Mon, 3 Apr 2017 19:04:04 -0700

On 04/03/2017 17:42, Murray S. Kucherawy wrote:
> On Mon, Apr 3, 2017 at 5:36 PM, Steven M Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     My POV, there is a strong 1:1 correlation between a set of ARC
>     headers and a given ADMD. In this world view, the A-A-R would
>     *not* collect all A-R values from all preceding ADMDs.
>
>
> It depends on what the goal is.  If you only want to record what the
> ADMD itself directly evaluated, your proposal is fine.  If you want to
> record what the ADMD thinks prior ADMDs claimed (e.g., GMail saying
> "Yahoo! claims this was fine when they got it"), then we must go deeper.

Results/claims by prior ARC participants in a given message are recorded
in their own ARC set ("i=N"), which they signed. Those are verified and
signed by subsequent ARC participants. This is how an intact ARC chain
provides the authentication results as observed by all/prior ARC
participants. The 2nd/3rd/Nth ARC participant is not saying "I believe
and trust the prior participants," just that "the signature(s) verified,
and I can tell you what I saw re: authentication when I was receiving
the message from hop N-1."

By contrast (and referring back to the start of the thread) I think it
would be unwise to include random A-R payloads one extracts from inbound
messages. Anybody handling the message can inject a random A-R. Trying
to extract only DKIM signed A-R headers from those messages can be
difficult - for example, because the correct inbound authserv-id for an
ADMD may not be clear to subsequent ADMDs, and where alterations may
have subsequently occurred in transit that break the signatures or
remove an A-R.

--S.

---

From: Steven M Jones <[email-masked]>
Date: Mon, 3 Apr 2017 19:19:25 -0700

On 04/03/2017 19:04, Steven M Jones wrote:
>
> Results/claims by prior ARC participants in a given message are
> recorded in their own ARC set ("i=N"), which they signed. Those are
> verified and signed by subsequent ARC participants.

Excuse me, too imprecise. "Those signatures are verified and all prior
ARC sets are signed by subsequent ARC participants."The subsequent ARC
participants cannot verify prior ARC participants' results/claims.

--S.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 04 Apr 2017 03:06:21 +0000

On April 3, 2017 9:16:23 PM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>> I'm also not clear why we need a new header field.  Why can ARC be a
>new
>> method for A-R?
>>
>

Lovely.  Thanks.

That makes more sense, but raises another concern then.  It seems misnamed.  A-A-R isn't an ARC result at all, it's part of the input to the ARC process.

Is the A-A-R intended to be used in normal ARC seal validation or is useful for forensic purposes?  If it's the former, then it might be better inside the ARC seal field rather than in a separate field.  Then the bit about correlation based on i= isn't necessary.  If the latter, I think a different name would be clearer.  Maybe ARC-seal-data (A-S-D) or ARC-authentication-input (A-A-I)?

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 4 Apr 2017 07:28:04 -0500

On Apr 3, 2017 7:22 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

-MSK

Attempting to reply to the chain as best I can from my phone (won't be back
to work and a real keyboard until next Monday)...

The grammar is indeed terrible and needs to be fixed. The intent is that
the AAR reflects the computed A-R at the time the message enters a trust
boundary. Only the A-R that it computes is put into its ARC set as the AAR.
Depending upon implementation, an ADMD may affix an ARC set both upon entry
and exit or may implement an ARC set that effectively spans the transit
through its domain.

I hope that helps...

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Tue, 4 Apr 2017 13:34:13 -0700

On Mon, Apr 3, 2017 at 5:42 PM, Murray S. Kucherawy <[email-masked]>
wrote:

>> and a given ADMD. In this world view, the A-A-R would *not* collect all A-R
Knowing what the previous ADMD thought is explicitly a goal of ARC.  The
theory is, the first hop said that it was from yahoo.com and DKIM signature
matched, and then the mailing list changed it so the DKIM signature is now
broken, but I believe that the first hop was accurate, so I will bypass
DMARC reject.

Does it need to be included at every hop?  Well, what if it goes through a
mailing list at @google.com which does rewrite it to @google.com and DKIM
signs it to pass, then another hop which rewrites all of the links to use
Proofpoint's "smart malware redirector", so it would fail DMARC for a
domain that wasn't the original domain or evaluation.

The proposal which led to this, X-Original-Authentication-Results, was
basically a way to pass a single AuthRes header forward (in our impl, it is
only believed if it is covered by our X-Google-DKIM-Signature, ARC extends
this to handling multiple hops.

Brandon

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Apr 2017 22:02:05 -0700

On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long <[email-masked]> wrote:

> theory is, the first hop said that it was from yahoo.com and DKIM
> signature matched, and then the mailing list changed it so the DKIM
> signature is now broken, but I believe that the first hop was accurate, so
> I will bypass DMARC reject.
>

This seems to be the classic illustration of the DMARC problem.  There are
three actors: An author/sender, an intermediary (MLM, say), and a receiver;
the MLM will invalidate the author's signature, so the receiver will bounce
it.  ARC fixes this by allowing the receiver to see what the MLM saw and
make a decision based on that.  It must either blindly or explicitly trust
the MLM, each of which deserves at least a paragraph of discussion in ARC,
but that's for another thread.

But how does this extend beyond three actors?  What if Yahoo! sends to an
IETF list, which sends to an alumni remailer, which re-sends to Gmail?  The
Yahoo! signature (which you might trust explicitly or by reputation) is now
one more hop away.  Does this still work?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Apr 2017 22:03:39 -0700

> and exit or may implement an ARC set that effectively spans the transit

So it's nothing more than an A-R with an instance number and a different
field name.  Presumably you want the new name specifically to permit
addition of the instance name, and to bind it to a specific ARC Set without
having to do the dance with the authserv-id.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Apr 2017 22:07:07 -0700

On Mon, Apr 3, 2017 at 8:06 PM, Scott Kitterman <[email-masked]>
wrote:

> That makes more sense, but raises another concern then.  It seems
> misnamed.  A-A-R isn't an ARC result at all, it's part of the input to the
> ARC process.
>

I think it's not named that way because it's conveying an ARC result, but
rather to make it more obvious that it's part of an ARC Set, where all
three header fields are added at the same time.

> Is the A-A-R intended to be used in normal ARC seal validation or is
> useful for forensic purposes?  If it's the former, then it might be better
> inside the ARC seal field rather than in a separate field.  Then the bit
> about correlation based on i= isn't necessary.  If the latter, I think a
> different name would be clearer.  Maybe ARC-seal-data (A-S-D) or
> ARC-authentication-input (A-A-I)?
>

No opinion there.  The current name makes its syntax and semantics
immediately recognizable, but mixing it into the ARC-Seal is plausible.

-MSK

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 5 Apr 2017 08:34:59 -0400

On 4/5/2017 1:02 AM, Murray S. Kucherawy wrote:
> On Tue, Apr 4, 2017 at 1:34 PM, Brandon Long <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Knowing what the previous ADMD thought is explicitly a goal of
>     ARC.  The theory is, the first hop said that it was from yahoo.com
>     <http://yahoo.com> and DKIM signature matched, and then the
>     mailing list changed it so the DKIM signature is now broken, but I
>     believe that the first hop was accurate, so I will bypass DMARC
>     reject.
>
>
> This seems to be the classic illustration of the DMARC problem.  There 
> are three actors: An author/sender, an intermediary (MLM, say), and a 
> receiver; the MLM will invalidate the author's signature, so the 
> receiver will bounce it.  ARC fixes this by allowing the receiver to 
> see what the MLM saw and make a decision based on that.  It must 
> either blindly or explicitly trust the MLM, each of which deserves at 
> least a paragraph of discussion in ARC, but that's for another thread.
>
In earlier (early?) discussions for the design of ARC, reputation of the 
MLM or other participants in the chain (which is outside the scope of 
the document) was an important part of the discussion. I think how well 
this works can only be determined once there are more ARC 
implementations in the wild.

> But how does this extend beyond three actors?  What if Yahoo! sends to 
> an IETF list, which sends to an alumni remailer, which re-sends to 
> Gmail?  The Yahoo! signature (which you might trust explicitly or by 
> reputation) is now one more hop away.  Does this still work?
>

Same as above. My sense is that it might be possible to game the system 
at very low volumes of abuse but bad (ARC) chains will be identified at 
larger volumes. What the thresholds are is anyone's guess.

> -MSK

Mike