Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt

From: [email-masked]
Date: Mon, 30 Jan 2012 11:36:49 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Messaging Abuse Reporting Format Working Group of the IETF.

	Title           : Extensions to DKIM for Failure Reporting
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-marf-dkim-reporting-07.txt
	Pages           : 23
	Date            : 2012-01-30

   This memo presents extensions to the DomainKeys Identified Mail
   (DKIM) specification to allow for detailed reporting of message
   authentication failures in an on-demand fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-marf-dkim-reporting-07.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 30 Jan 2012 11:39:14 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 30, 2012 11:37 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-marf-dkim-reporting-07.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Messaging Abuse Reporting
> Format Working Group of the IETF.
> 

- addresses Alessandro's last point about fraudulent signature detection

- fix up the examples, and split the first one since DKIM reporting is now split into two parts

- change "rd=domain" to "r=y" in the signature

- add "policy" and "other" report types

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 31 Jan 2012 20:08:34 +0100

On 30/Jan/12 20:39, Murray S. Kucherawy wrote:
> 
>> From: ietf.org On Behalf Of [email-masked]
>

Does this I-D update RFCs 5617 and 6376?  I'm just trying to learn...

1. *Introduction*

How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too?

2. *Definitions*

I'd add a short section to define /report generator/, e.g.

  A report generator is an entity that generates and sends reports.
  For the scope of this memo, the term refers to Verifiers, as
  defined in Section 2.2 of [DKIM], designed to also generate
  authentication failure reports according to this specification.

3.2. *DKIM Reporting TXT Record*

s/The Verifier (if it supports this extension)/A report generator/ if
you inserted that definition.  (For capitalization, I found eight
occurrences of "Verifier" and just four of "verifier".)

In the definition of rp=, maybe s/The value is an integer value/The
value is a decimal integer/.  If you do, the same applies to Section 4.

In the definition of rr=, you need to add "d", "p", and "o" to
rep-rr-type.  Same applies to Section 4.

In the definition of rs=, it may be worth noting that the reply code
should not be part of the string.

BTW, why isn't the rs= string actionable even in the absence of ra=?

3.3. *DKIM Reporting Algorithm*

Typo: "on a message fails".  If you added the above definition, you
may replace this text:

  The following algorithm, or one semantically equivalent to it, MUST
  be applied when an implementation is equipped to generate reports in
  compliance with this specification and its evaluation of the DKIM-
  Signature header field (see [DKIM]) on a message fails for some
  reason.

with something like

  Report generators MUST apply the following algorithm, or one
  semantically equivalent to it, on each DKIM-Signature header field
  whose verification fails for some reason.

The last paragraph of this section is rather convoluted.  In order to
simplify it, I would modify the first step of the algorithm to read
like so:

  1.   If the DKIM-Signature field did not contain a valid "r=" tag
       and if there are no different out-of-band arrangements,
       terminate.

I don't attempt to actually simplify that paragraph, but note that it
might refer to Section 8.5 (Automatic Generation) for out-of-band
arrangements.

Murray, the "previous implementations" that the subsequent paragraphs
refer to are a rather obscure entity.  They seem to be internal notes
that somehow happened to make their way into the published spec.

4. *Optional Reporting Address for DKIM-ADSP*

See notes above for rp= and rr=.

5. *Requested Reports*

s/this these/these/

5.2. *Requested Reports for DKIM ADSP Failures*

s/[ADSP]-related reason/[ADSP]-related failure reason/

6.2. *Envelope Sender Selection*

In our case, mail loops may occur among _report addresses.  For
example, bad signature => dkim-report with bad SPF => spf-report with
bad DKIM-Signature =>  dkim-report with bad SPF...

Perhaps, the I-D could say that, for ARF messages of any kind, the r=
tag of a DKIM-Signature MUST be ignored and automatic report
generation MUST NOT take place.  Out-of-band arrangements can still
provide for manual ways to report failures of the reporting mechanism
itself.

Typo: s/wil pass/will pass/

8.1. *Inherited Considerations*

[I-D.MARF-AUTHFAILURE-REPORT] is missing here.

8.5. *Automatic Generation*

The last paragraph, about out-of-band arrangements, seems to defy this
I-D's very purpose of automating reporting.  Considering what marf-as
is going to say on unsolicited reports, I'd s/create/persist sending/.
 The resulting wording implies an upper limit for reports generated
automatically that are destined to a given domain.  That, in turn,
implies maintaining a domain-indexed database of what's going on with
the email.  In this case we may count the overall number of reports
sent with no out-of-band arrangement.

8.6. *Reporting Multiple Incidents*

This section seems disconcerting, especially the middle paragraph.
Since the rp= tag is specified with utter sharpness, implementations
of the logarithmic approach seem to be out of the way.  Perhaps, we
can recommend a switch-to-manual upper limit instead, counting the
number of reports sent per day (or per hour), using the same database
as above.

To suspend report generation for some time after an RCPT rejection of
the reporting address might also provide for a safe approach.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Jan 2012 12:00:41 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, January 31, 2012 11:09 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-07.txt
> 

No.  Someone implementing those isn't encouraged to be familiar with this work.  It's purely an optional extension.

> How about mentioning [I-D.MARF-AUTHFAILURE-REPORT] here too?

Seems reasonable; same for the spf-reporting draft.  Scott?

>   authentication failure reports according to this specification.

Seems reasonable; same for the spf-reporting draft.  Scott?

> occurrences of "Verifier" and just four of "verifier".)

OK, and capitalized the four lowercase instances.

> value is a decimal integer/.  If you do, the same applies to Section 4.

I just dropped the second "value".  Saying "the value is an integer" is fine.

> In the definition of rr=, you need to add "d", "p", and "o" to rep-rr-
> type.  Same applies to Section 4.

Fixed.

> should not be part of the string.

It says "included", which to me makes it clear that it goes in the reply, not that it is the reply.

> BTW, why isn't the rs= string actionable even in the absence of ra=?

Good point; fixed.

> Typo: "on a message fails".  If you added the above definition, you may
> replace this text:
> 

Done.

> might refer to Section 8.5 (Automatic Generation) for out-of-band

I think that falls under "semantically equivalent", so I'd prefer not to change it.

> that somehow happened to make their way into the published spec.

They're there deliberately to explain the choices made with this algorithm, especially when the people reading it might be familiar with pre-RFC implementations of DKIM reporting.

> See notes above for rp= and rr=.

Fixed.

> s/this these/these/

It's one list, so "this" is correct.

> s/[ADSP]-related reason/[ADSP]-related failure reason/

I think that's redundant, but harmless, so sure.

> tag of a DKIM-Signature MUST be ignored and automatic report generation
> MUST NOT take place.  Out-of-band arrangements can still provide for
> manual ways to report failures of the reporting mechanism itself.

I think the existing text in this section already covers that case, especially the first SHOULD.  I also think a general admonishment of this type is not appropriate in this subsection because it has nothing at all to do with the envelope sender.  So I'll add it in its own subsection.

> Typo: s/wil pass/will pass/

Fixed.

> [I-D.MARF-AUTHFAILURE-REPORT] is missing here.

Fixed.

> sent with no out-of-band arrangement.

What this section is trying to say is that people should not implement systems that do this kind of reporting work by default.  It can create a ton of traffic due to simple infrastructure problems at the signer/sender, for example.  The obvious mitigation, rate limiting the generation of reports, isn't an ideal solution for various reasons.

I don't think this harms what -as is saying about unsolicited reports.  This document discusses a specific kind of feedback and thus this is not a statement about ARF in general.

> Since the rp= tag is specified with utter sharpness, implementations of
> the logarithmic approach seem to be out of the way.  Perhaps, we can
> recommend a switch-to-manual upper limit instead, counting the number
> of reports sent per day (or per hour), using the same database as
> above.
> 

Since it's Security Considerations, none of this is normative.  It's just a suggestion for handling large volumes of reports.  Your two are equally viable, so it would be fine to add them as well, especially since the latter one talks about a way to do rate limiting at the report receiver rather than relying on the report generator to do it all.  So I'll add this:

                        <t> Other rate limiting provisions might be considered,
                            including detection of a temporary failure
                            response from the report destination and thus
                            halting report generation to that destination
                            for some period, or simply imposing or negotiating
                            a hard limit on the number of reports to be sent
                            to a particular receiver in a given time
                            frame. </t>

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 00:13:42 -0500

On Tuesday, January 31, 2012 12:00:41 PM Murray S. Kucherawy wrote:
...
> Seems reasonable; same for the spf-reporting draft.  Scott?
...

It's really late and I'm very tired.  Just tell me which ones you did in your 
new draft and I'll follow your lead.  I'm sure it will be fine.  On the off 
chance it's not, I'll let you know.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 31 Jan 2012 21:21:26 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, January 31, 2012 9:14 PM
> To: [email-masked]
> It's really late and I'm very tired.  Just tell me which ones you did
> in your new draft and I'll follow your lead.  I'm sure it will be fine.
> On the off chance it's not, I'll let you know.

So do it tomorrow.  :-)

The easiest thing to do is probably to pull it up in the datatracker, click the History tab, and request a diff from the -07 version.

The datatracker link is http://datatracker.ietf.org/doc/draft-ietf-marf-dkim-reporting/.

-MSK