Subject: [marf] DKIM reporting

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Dec 2011 12:12:00 -0800

[as participant]

As I've mentioned before, the idea of doing forensic reporting of messages that fail DKIM verification has been a very valuable tool in terms of interoperability testing between DKIM implementations.  It's got value as well in showing signers how their mail is being altered in transit even when the signer and verifier are working properly (i.e., unanticipated mangling en route).

What's in draft-ietf-marf-dkim-reporting is essentially what I've developed and implemented almost since the beginning of the DKIM effort.  The DKIM working group didn't pick it up, but since the forensic reports themselves are actually ARF-based, I brought the work here.  It used to be part of draft-ietf-marf-authfailure-report but was broken out into its own document at (I think) our meeting in Maastricht.

I haven't had much in the way of feedback on it except through targeted requests for reviews.  When I finally got those, the suggestions I got were radically different from what I've implemented.  Given that, I'd like to invite the working group to consider it from the ground up in order to build something that has consensus.

So let's talk requirements.  The idea is to enable a signer to request that a verifier, on finding a message that fails verification testing, send a message back showing the canonicalized forms of the header and body, the idea being that the signer would keep a copy of the same and thus be able to see what changed in transit.  The mechanism of advertising that this is wanted needs to be simple and not add much burden to the existing system.  (That's why I grafted it on to the key record in the DNS, which has to be retrieved anyway.)  The authfailure-report draft creates the syntax for the report, so this draft only needs to be able to communicate the request for the report and its parameters.

There are some obvious security considerations, such as being able to cause a storm of report mail if a lot of mail goes out all of which fails to validate.  The interval stuff is in there to make it possible for the signer to mitigate such damage.

There's an adjunct ADSP angle, which requests a report if ADSP says "this should be signed by the author domain" and it wasn't, even if all the signatures passed.  The same requirements apply.

I think it's really as simple as that.

So if you don't like the dkim-reporting draft as it's written, how would you design something within those requirements?

I think Steve and John commented on this before.  I'll go dig up their old emails and comment on them as well, but I'll try to do so on this thread so it's all in one place.

-MSK

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 8 Dec 2011 02:28:56 +0100

On 7 December 2011 21:12, Murray S. Kucherawy <[email-masked]> wrote:

> I haven’t had much in the way of feedback on it except through targeted
> requests for reviews.

Some quick observations:  s/4871/6376/, s/sender/signer/ (or whatever is
state of the art in DKIM terminology), and maybe say "alleged author" if
that is the correct ADSP term.  It was straight forward to find _where_
the marf-reporting-discovery will find its TXT, for marf-dkim-reporting
it took me some time to check RFCs 6376 + 5617.  I think (could be wrong)
that I understand the ADSP part, but I'm less sure about the DKIM part.

The SPF draft has an example where example.org wants reports at another
domain r=[email-masked]  That makes me nervous, the opposition
could publish malicious DNS records for some kind of indirect attack.

I don't see why that's necessary for SPF or ADSP.  It might be different
for broken or forged DKIM signatures, but generally I think that anybody
"doing something" with mail at a domain where they can add TXT records
can also arrange a postmaster@ or similar mailbox at this domain.

For ri=1 (non-zero) how long are receivers expected to wait for another
incident?  If you want ri=9, and I get only 8 broken signatures within
a day, does this mean that you want no report because 8 is less than 9?

Or do you want no second report before I got 2*9 broken signatures, no
matter how long it takes?  It is not clear for me why receivers would
ever wish to follow detailed instructions about their reports, even
including MUSTs and MUST NOTs in section 5.

For ADSP ro=u I'm not sure what it is, is this simply "all minus ro=s"?
Should the ADSP ro=u explanation (5.2) say "and" instead of "but"?

The rf=smtp + rs=... magic is apparently something in the direction of
the SPF exp= magic.  Or maybe not, please add more than one example for
rf=smtp + rs=... tricks (or a pointer if this is explained elsewhere.)

For ADSP + DKIM the marf-reporting stuff should fit into the relevant
TXT records, for SPF I'm not sure.  If you (= the WG) intend to create
a general _report discovery mechanism it would be confusing to create
additional specific ADSP + DKIM + SPF mechanisms, and vice versa, but I
have no idea or opinion what's better (specific vs. general _report).

-Frank

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 08 Dec 2011 09:52:40 -0500

> could publish malicious DNS records for some kind of indirect attack.

One of the comments that I'll resolve in the next update to the draft
will do away with that.  We debated it back and forth and reached
essentially this conclusion.

Scott K

---

From: Dotzero <[email-masked]>
Date: Thu, 8 Dec 2011 09:54:05 -0500

I plead mea culpa in only sort of following the marf work without
providing input. This is of interest to me but I'm feeling that I am
spread kind of thin these days. I will try to give a deeper read and
give more meaningful input based on Murray's request. One comment
inline.

Mike

> can also arrange a postmaster@ or similar mailbox at this domain.

Some organizations (such as my own) use a 3rd party service for
handling authentication FBL emails. We don't use ADSP and the mail
flows involved are (all) DKIM signed. I recognize the risk you
indicate but I think there are much easier attack vectors than this.

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

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 09 Dec 2011 13:15:41 +0100

>> can also arrange a postmaster@ or similar mailbox at this domain.

This seems to be the same conclusion that the thread started by Murray
in August reached
http://www.ietf.org/mail-archive/web/marf/current/msg01246.html