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

From: Seth Blank <[email-masked]>
Date: Tue, 30 May 2017 10:14:08 -0700

The current spec defines an arc authres method (https://tools.ietf.org/html/
draft-ietf-dmarc-arc-protocol-03#section-8.1).

We believe there should also be registered ptypes and properties, that
should be stamped (but are not required, as they won't always be available).

As long as AR stamping happens at the end of chain validation, when an ARC
set gets created this stamp will be included in the AAR, and AAR
construction can be clean with no additional language or requirements
necessary in the spec.

What follows below is not sacred, we're just trying to start the
conversation.

Based upon previous threads (specifically, Brandon's reporting local_policy
thread from May 4th PST) surrounding the AAR and data the WG thought would
be valuable for final receivers and DMARC reports, it looks like stamping
header.b for each dkim signature on the message and smtp.client-id for the
ip address of the originating mail server (if available) would provide
nearly everything asked for with minimal implementation overhead (and no
change to spec except for the IANA registration, and an addition for
RECOMMENDED stamping if warranted).

To dig in to the reasoning behind these two properties:

1) header.b

At the end of an ARC chain, there might be many DKIM signatures on the
message, nearly all of which could be broken on receipt. Additionally,
since there have been multiple hops, it is possible to have several broken
DKIM signatures with the same header.d value that are representative of
different services at different hops.

If each hop stamps the https://tools.ietf.org/html/rfc6008 header.b of
every dkim key on the message, then it becomes super clear which keys were
added when, and which dkim pass/fail statuses correspond to which keys so
it can be determined when any individual signature broke.

This is extremely useful as a reporter to help identify broken services at
any stage of DMARC enforcement, and is probably useful for final receivers
reviewing the chain to determine final message disposition; without this
information all the DKIM-Signatures on a message that do not validate and
share the same header.d are indistinguishable.

This stamp removes this ambiguity and adds reporting and trace value.

2) smtp.client-id

The goal here is to track the originating source_ip for DMARC
categorization and reporting. Otherwise, all ARC messages will have a DMARC
report source_ip of the last forwarder, not the originating service. This
will be exceptionally confusing to consumers of DMARC reports.

We know that including an IP address in Authentication-Results has been
persona-non-grata in the past, as authentication results are supposed to
encapsulate the results of an authentication check, not information that
could be used to re-run the authentication downstream.

However, we believe that the client-id is vital trace information for ARC
and DMARC, is useful for categorizing senders within a DMARC report, and is
valuable at p=none, p=quarantine, and p=reject, and as such makes sense
within and contained to the ARC stamp.

Ultimately, if this stamp is wrong for the AR, the client-id could be added
directly in the AAR. The AR stamp is cleaner because it leaves the AAR
generation and spec untouched.

We know there will be disagreement about what to stamp, and welcome
discussion on what's best to track within an AR header as arc status.

I'm happy to suggest language once there's rough consensus in the group.

Seth

-- 

Bringing Trust to Email

Seth Blank | Head of Product for Open Source and Protocols
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 May 2017 14:43:45 -0400

> I'm happy to suggest language once there's rough consensus in the group.

When msk initially defined the Authentication Results header field, I was a 
strong proponent of including trace elements, but was in the rough as it comes 
to the consensus.  In retrospect, I think he was correct.

AAR can't truly be a trace header (you'd have to include the entire unmodified 
message with the original DKIM signature to make the DMARC inputs traceable).  
I'm not sure it's worth doing it half-way.

I'm particularly not convinced about source_ip.  DMARC reports are organized 
by 5322.From and when I'm reviewing reports what I care about is where the 
reporting receiver got it from.  That's already covered.

I don't see anything that might support trace uses that has to be in the 
initial specification.  It can be added later if there's a need.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Tue, 30 May 2017 13:34:50 -0700

> I'm not sure it's worth doing it half-way.

I don't want the AR payload to be about trace information; I want to make
sure it encapsulates the proper authentication results and statuses. So
that a DMARC report after an ARC message has been processed has the
appropriate information that's valuable to a report consumer.

- At p=none this means understanding the originating sender and if any
originating authentication mechanisms were broken. This means passing
through an smtp.client_id and the header.b's.

- At p=quarantine|reject, for a failing message that passes arc, I think
the status quo works (although having header.b here to understand which
keys signed the message when could be useful).

- At p=quarantine|reject, for a failing message that fails arc, it's useful
to know where/why the message failed. Again, header.b's shine light on this
and can make the DMARC report useful for determining/fixing a broken
originating sender or intermediary.

Passing this information through (and to me it's not trace if it's there
for a user to interact with in a DMARC report - although there's definitely
additional trace value, that's not the primary purpose here) is extremely
valuable for the report consumer.

My concern is putting it anywhere other than the AR/AAR could creative
feature/spec creep, and waiting to see what happens and writing a spec for
stamping later just leaves room open for complaints that, even after ARC,
DMARC is still broken with respect to reporting on mailing list and
forwarders.

> reporting receiver got it from.  That's already covered.

I'm not certain I'm sold either. Especially because many implementations
won't even have access to the IP. For instance, Mailman3 does not have
access to the source_ip of the smtp connection (that data doesn't come over
LMTP), so no mailman software would ever be able to stamp this.

I think the source_ip is valuable to provide, especially for a final
consumer of a report, but 1) it's not always available, 2) it doesn't seem
perfect to put into an AR header.

Thoughts?

> initial specification.  It can be added later if there's a need.

I think stamping header.b has real value as outlined above.

I think smtp.client_id also has value, but definitely see the arguments
from both sides.

Seth

> Scott K
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

Bringing Trust to Email

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 30 May 2017 17:14:56 -0400

On Tuesday, May 30, 2017 01:34:50 PM Seth Blank wrote:
> > > The current spec defines an arc authres method (
> > 
> > https://tools.ietf.org/html/
> > 
> > > should be stamped (but are not required, as they won't always be
> > 
> > available).
> > 
> > > As long as AR stamping happens at the end of chain validation, when an
> > 
> > ARC
> > 
> > > Based upon previous threads (specifically, Brandon's reporting
> > 
> > local_policy
> > 
> > > thread from May 4th PST) surrounding the AAR and data the WG thought
> > 
> > would
> > 
> > > header.b for each dkim signature on the message and smtp.client-id for
> > 
> > the
> > 
> > > since there have been multiple hops, it is possible to have several
> > 
> > broken
> > 
> > > every dkim key on the message, then it becomes super clear which keys
> > 
> > were
> > 
> > > This is extremely useful as a reporter to help identify broken services
> > 
> > at
> > 
> > > any stage of DMARC enforcement, and is probably useful for final
> > 
> > receivers
> > 
> > > categorization and reporting. Otherwise, all ARC messages will have a
> > 
> > DMARC
> > 
> > > and DMARC, is useful for categorizing senders within a DMARC report, and
> > 
> > is
> > 
> > > Ultimately, if this stamp is wrong for the AR, the client-id could be
> > 
> > added
> > 

So header.b only gives an explicit way to link an (A)AR header field with a 
signature, so there's no need to guess what's related within the message.  Now 
that I've read your rationale and gone and read RFC 6008 again, I agree that 
makes sense to include in AAR.  It might even be a good idea to make it 
mandatory since there is (for the purposes of IETF standardization) no 
installed base to worry about.

Source IP, I still this is only for trace purposes and should be out of scope 
(I have a hard time justifying why it would be out of scope for SPF (which is 
what the working group and later IETF consensus was) and in scope here.

Scott K

---

From: Brandon Long <[email-masked]>
Date: Tue, 30 May 2017 16:43:24 -0700

I'm not clear, are you saying requiring the header.b for every dkim resinfo
in the AAR, or requiring it for the arc=result resinfo?

It has always seemed odd to me that the spf one didn't include the IP as
well, since it's certainly input, I guess I should go archive spelunking
again.

Brandon

On Tue, May 30, 2017 at 2:14 PM, Scott Kitterman <[email-masked]>
wrote:

> > > > added when, and which dkim pass/fail statuses correspond to which
> keys
> > > > so
> > > When msk initially defined the Authentication Results header field, I
> was
> > > a
> > > strong proponent of including trace elements, but was in the rough as
> it
> > > comes

---

From: Seth Blank <[email-masked]>
Date: Tue, 30 May 2017 17:06:29 -0700

I mean in the AR arc=result header.b=... header.b=...

And then this gets captured in the AAR when a message is signed.

Seth

On Tue, May 30, 2017 at 4:43 PM, Brandon Long <[email-masked]> wrote:

> I'm not clear, are you saying requiring the header.b for every dkim
> resinfo in the AAR, or requiring it for the arc=result resinfo?
>
>> > On Tue, May 30, 2017 at 11:43 AM, Scott Kitterman <[email-masked]
>> >
>> >
>> > wrote:
>> > > > information all the DKIM-Signatures on a message that do not
>> validate
>> > > > and
>> > > > However, we believe that the client-id is vital trace information
>> for
>> > > > ARC

-- 

Bringing Trust to Email

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 31 May 2017 09:46:47 +0800

Barry et al,

On Wed, May 31, 2017 at 1:14 AM, Seth Blank <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-03#section-8.1).
>

This area seems like something that would be productively explored in a F2F
since it is pretty undefined right now and there are some divergent
opinions kicking around... (see the thread with Brandon and Scott so far)

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 21:20:45 -0700

> > will be exceptionally confusing to consumers of DMARC reports.

When A-R came to be in RFC5451 there was a protracted debate (leading all
the way to an IESG appeal, and ultimately the text of Appendix C in that
document and in RFC7601) about this very thing.  The tl;dr is that we left
it out on purpose, for two reasons:

1) A-R is meant to relay properties of the message that were
authenticated/validated/whatever, and the IP address is not part of the
message or its envelope; and

2) A-R is meant to relay information about what
authentication/validation/whatever was done in a way that's meaningful to
users, and the IP address (especially now in a v6 world) is pretty much
never meaningful to users.

Another way to look at it: A-R is meant to be a channel to record what
authentication was done and what thing in the visible message got
authenticated so, say, an MUA could show the domain name in green next to a
spinning gold key or whatnot to show that it was safe, based on
<method-of-choice>.  It was not meant to provide enough information that an
MUA or internal MTA could re-perform authentication, say, when the message
was opened by a user.

What we're seeking to do here is add it to A-R as a way to get that
information through to a place where DMARC can get it to include in
reports.  If we want to redefine what A-R is to meet that requirement, then
that's something consensus could certainly do, but if not, I'd prefer not
to use it as a substrate against its stated purpose.

We could also, however, standardize "X-Source-IP" (without the "X-", of
course) and use that, as it already has numerous consumers and other
applications well beyond ARC and DMARC.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Wed, 31 May 2017 22:30:01 -0700

> to use it as a substrate against its stated purpose.

Absolutely understood, and agreed.

> applications well beyond ARC and DMARC.
Okay.

My original point for smtp.client-id was simply to transfer the source_ip
for a DMARC report, because it is valuable for a final report consumer. I
suggested the AR because it seemed like the cleanest way without needing to
modify the spec. Clearly transmission via the AR/AAR is the wrong way to do
this based on the purpose of the AR.

So I guess returning to the original thread, there are two matters:

1) Should we stamp header.b in the A-R? (consensus seems to be yes)

2) How should we transmit the source_ip for the DMARC report?

Murray, does your suggestion mean a separate doc regarding a signed
Source-IP header that would then be referenced in ARC and covered by...
what, the AS? Or is there a cleaner way?

Thanks for the context and suggestion!

Seth

-- 

Bringing Trust to Email

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 May 2017 23:08:43 -0700

> 1) Should we stamp header.b in the A-R? (consensus seems to be yes)

It's defined, may as well use it.

> what, the AS? Or is there a cleaner way?

Source-IP was just one suggestion.  If we do decide to do that, I would do
it in a separate document, and then the ARC work can just recommend its use
and require covering it in the AMS or AS if it's present.

We could also risk some wormy can opening and discuss the idea of expanding
the scope of A-R to include this use case rather than strictly supporting
MUAs, thereby enabling your original idea.

Both of those ideas are valid, and there may be others.

-MSK