Subject: [marf] DKIM reporting ARF extensions

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Apr 2010 11:37:28 -0700

One of our chartered items is to begin working on extensions to ARF to support reporting of DKIM and ADSP failures to senders.  The basis for this work will be draft-kucherawy-dkim-reporting, a new version of which I just posted since it was about to expire (thanks to JD Falk for his review help!).

Unless there's any objection, I'll soon ask the IESG to make it a document of the MARF WG so we can get busy working on it.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 Apr 2010 17:20:18 -0400

I am not sure how this fits in with ARF since ARF is for abuse
reporting specifically, and authentication failure seems to be a more
generic "multipart/report" extension.

On Thu, Apr 15, 2010 at 2:37 PM, Murray S. Kucherawy <[email-masked]> wrote:
> One of our chartered items is to begin working on extensions to ARF to
> support reporting of DKIM and ADSP failures to senders.  The basis for this
> work will be draft-kucherawy-dkim-reporting, a new version of which I just
> posted since it was about to expire (thanks to JD Falk for his review
> help!).
>
>
>
> Unless there’s any objection, I’ll soon ask the IESG to make it a document
> of the MARF WG so we can get busy working on it.
>
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Apr 2010 15:38:04 -0700

> -----Original Message-----
> From: Yakov Shafranovich [mailto:[email-masked]]
> Sent: Thursday, April 15, 2010 2:20 PM
> To: Murray S. Kucherawy
> Cc: Message Abuse Report Format working group
> Subject: Re: [marf] DKIM reporting ARF extensions
> 

The original impetus was phishing reporting, which clearly falls under the "abuse" category.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Apr 2010 13:51:16 +0200

> One of our chartered items is to begin working on extensions to ARF to support reporting of DKIM and ADSP failures to senders. The basis for this work will be draft-kucherawy-dkim-reporting, a new…

Neither your dkim-reporting draft nor rfc 5617 include SMTP as a 
normative reference. In facts, it is not clear how ADSP discarding and 
reporting should work, SMTP-wise. To wit, assuming a server rejects a 
discardable message, the transmitting client is held responsible for 
reporting such failure. Isn't it so?

If it is, the server should supply a machine-readable textstring in 
its rejecting reply, possibly using a special reply code after DATA. 
That would lead the transmitter into preparing an ARF rather than a 
regular DSN. This case is difficult, as it requires changes on both sides.

If it is not, the server should accept the message, silently discard 
it, and submit an ARF according to the specs. This case is easier, but 
less appealing from a server's POV.

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 16 Apr 2010 07:47:15 -0600

> The original impetus was phishing reporting, which clearly falls under the "abuse" category.

I agree.  It seems appropriate to the MARF charter and is certainly needed.  There is a lot of immediate interest in this spec.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 16 Apr 2010 10:17:52 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alessandro Vesely
> Sent: Friday, April 16, 2010 4:51 AM
> To: [email-masked]
> normative reference.

Quite right, and easily fixed.

> In facts, it is not clear how ADSP discarding and

Yes, the sending SMTP client would be responsible for handling the rejection according to specifications.

> regular DSN. This case is difficult, as it requires changes on both

I'm not sure that's a MUST, but I'd go for a SHOULD.  One could argue that the reason for the rejection might reveal to an attacker what has to be adjusted to get through the filter.

> less appealing from a server's POV.

The spec allows the "victim" domain to specify what action it would like receivers to take when an ADSP violation occurs.  This can include whether or not the receiver is requested to do either of the two things you suggest and can even request a specific SMTP reply string.  The receiver isn't compelled to do either; it's a request from the ADMD posting the ADSP record.

The one thing I think I could add based on your remarks is more affirmative text that the extensions proposed are optional for the receiver; they are requests from whoever used the extension, but the receiver is free to take whatever action is operationally appropriate in its environment.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 17 Apr 2010 17:00:16 +0200

On 16/Apr/10 19:17, Murray S. Kucherawy wrote:
>>  If it is, the server should supply a machine-readable textstring in its rejecting reply, possibly using a special reply code after DATA. That would lead the transmitter into preparing an ARF rather than a regular DSN. This case is difficult, as it requires changes on both sides.
>
> I'm not sure that's a MUST, but I'd go for a SHOULD.

Or even a MAY. The server has no way to know whether the client 
supports the special formatting required. However, the format of the 
textstring has to be spelled out. (It might be something similar to

Reply-line     = *( Reply-code "-" [ textstring ] CRLF )
                   Reply-code [ SP textstring ] CRLF
Reply-code     =  "556" ; say
textstring     =  dkim-hdr-name ":" dkim-hdr-value
dkim-hdr-name  =  "DKIM-ADSP-DNS" /
                   ; ...
                   "DKIM-Selector-DNS"
dkim-hdr-value =  token)

More importantly, the server has no way to know whether the client 
will send a report to the domain name owner. An attacker obviously 
won't. For security-critical applications (B below), it may make sense 
to ask that a server sends an abuse report even if it is going to 
reject (or has just rejected) the reported message.

The following are two different scenarios:

A: The domain owner wants to know where signatures get broken in order 
to fix their sending policies. They rely on forwarders and receivers 
cooperation for the common advantage of having reliable email services.

B: A bank or similar institution wants to know the IPs of attackers 
who use their domain name in order to catch and prosecute them. Here, 
the advantage of the bank is the disadvantage of the attacker, and no 
cooperation is possible.

Could a server infer which case to apply, from the ADSP record?

> One could argue that the reason for the rejection might reveal to an attacker what has to be adjusted to get through the filter.

In ordinary conditions, adjusting the content until the hash matches 
would require a huge number of attempts. Anyway, attackers can test 
their forgeries on their own, before attempting to send them.

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 19 Apr 2010 13:36:10 -0600

On Apr 17, 2010, at 9:00 AM, Alessandro Vesely wrote:

> More importantly, the server has no way to know whether the client will send a report to the domain name owner. An attacker obviously won't. For security-critical applications (B below), it may make sense to ask that a server sends an abuse report even if it is going to reject (or has just rejected) the reported message.

I'd expect that the most common scenario will be that the message is rejected AND a report is sent -- but we'll see.

Unlike the original ARF effort, the community appears to be asking for a standard format /before/ they start exchanging data -- which makes it difficult to guess all the possible use cases at this stage.

One use case which isn't addressed in the current draft is where a set of signers ask a third party to collect & aggregate authentication success/failure data on their behalf, and the third party has relationships with verifiers who've agreed to provide that data.  For this, the DKIM reporting extensions to ARF are applied, but the policy and discovery parts of the draft are not -- instead it's an out-of-band agreement, just like marf-base.

I suppose we should mention that in the draft, but I'm not sure how to word it.

> A: The domain owner wants to know where signatures get broken in order to fix their sending policies. They rely on forwarders and receivers cooperation for the common advantage of having reliable email services.
> 
> B: A bank or similar institution wants to know the IPs of attackers who use their domain name in order to catch and prosecute them. Here, the advantage of the bank is the disadvantage of the attacker, and no cooperation is possible.
> 

How would it change their response if they knew?

--
J.D. Falk <[email-masked]>
Return Path Inc

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Apr 2010 09:52:27 +0200

> I'd expect that the most common scenario will be that the message is rejected AND a report is sent -- but we'll see.

That behavior makes lots of sense. However, it is different from 
traditional SMTP behavior. I think the spec should explicitly ask that 
servers take such action in the relevant circumstances. IMHO, the 
likelihood that it will emerge spontaneously is negligible.

> Unlike the original ARF effort, the community appears to be asking for a standard format /before/ they start exchanging data -- which makes it difficult to guess all the possible use cases at this…

Possibly, if paypal launched an appeal to report any rejected phishing 
attempt, someone would do so. Its format has to be specified, though.

> One use case which isn't addressed in the current draft is where a set of signers ask a third party to collect&  aggregate authentication success/failure data on their behalf, and the third party has relationships with verifiers who've agreed to provide that data.  For this, the DKIM reporting extensions to ARF are applied, but the policy and discovery parts of the draft are not -- instead it's an out-of-band agreement, just like marf-base.
>

Marf-base doesn't word out very well that state of affairs either.

> How would it change their response if they knew?

Case B is similar to the paypal appeal hypothesized above. I wouldn't 
take the burden to write (or enable) software that sends such stuff 
upon rejection, unless the would-be recipients say they'll appreciate it.