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

From: [email-masked]
Date: Mon, 23 Jan 2012 21:41:23 -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-04.txt
	Pages           : 18
	Date            : 2012-01-23

   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-04.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-04.txt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 21:49:07 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 23, 2012 9:41 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.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.
> 

Changes since the previous version:

- some language tightening with respect to "sender", "signer", etc.

- don't reference the SPF reporting document; they may evolve separately, and there's no need for them to hold each other up

- move all the broken signature reporting into the signature itself by making them extension DKIM-Signature tags, rather than putting them in the key records in the DNS; the revised design doesn't require DNS queries for failed signatures that don't otherwise need them

- remove "rf" (report format) tag for both DKIM and ADSP; assume all generated reports will use ARF

- rename "ri" (report interval) to "rp" (report percentage) for both DKIM and ADSP

- move report generation normative stuff out of Security Considerations and into its own section that covers report generation syntax and transport issues; reference draft-ietf-marf-authfailure-report accordingly

- other minor copy editing

Fresh reviews and other comments are most welcome.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2012 13:29:35 -0000

>- move all the broken signature reporting into the signature itself by making them
>extension DKIM-Signature tags, rather than putting them in the key records in the
>DNS; the revised design doesn't require DNS queries for failed signatures that
>don't otherwise need them

Let's say I put this line in the header of a bazillion messages in a
spam run:

DKIM-Signature: v=1; d=blackops.org; s=bogus; b=foo; bh=bar; h=baz; r=murray;

I've just indirectly mailbombed you.  Oops.  The domain has to publish
something about its willingness to get reports, not unlike the way that
ADSP publishes a record about what to do if there's no signature that matches
the From: domains.  Perhaps something like this:

_report._domainkey.blackops.org TXT "r=sendreportshere"

It doesn't belong in the key record since, among other things, that
would make it hard to debug failures due to missing or malformed key
records.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 09:53:23 -0500

On Monday, January 23, 2012 09:49:07 PM Murray S. Kucherawy wrote:
...
> - rename "ri" (report interval) to "rp" (report percentage) for both DKIM
...

It looks like sig-ri-tag and adsp-ri-tag in the ABNF are still needing 
renaming.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 10:00:10 -0500

On Tuesday, January 24, 2012 01:29:35 PM John Levine wrote:
> >- move all the broken signature reporting into the signature itself by
> >making them extension DKIM-Signature tags, rather than putting them in
> >the key records in the DNS; the revised design doesn't require DNS
> >queries for failed signatures that don't otherwise need them
> 
> ADSP publishes a record about what to do if there's no signature that
> matches the From: domains.  Perhaps something like this:

I agree with it going in a DNS record, not in the signature for exactly the 
reasons you state.

> would make it hard to debug failures due to missing or malformed key

Isn't this perhaps overkill?  As long as the key record isn't so broken one 
can't extract r=$STRING out of it, I think it's sufficient.  OTOH, for key 
records that are missing entirely either because either someone forgot to 
publish it or the wrong selector is being used (I've seen both happen), 
there's no way around a separate record like this.  I'm not sure what's best.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Jan 2012 08:30:13 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scott Kitterman
> Sent: Tuesday, January 24, 2012 7:00 AM
> To: [email-masked]
> Subject: Re: [marf] I-D Action: draft-ietf-marf-dkim-reporting-04.txt
> 
> > >- move all the broken signature reporting into the signature itself
> > >by making them extension DKIM-Signature tags, rather than putting
> > >them in the key records in the DNS; the revised design doesn't
> > >require DNS queries for failed signatures that don't otherwise need
> > >them
> >
> > something about its willingness to get reports, not unlike the way
> > that ADSP publishes a record about what to do if there's no signature
> > that matches the From: domains.  Perhaps something like this:
> 
> I agree with it going in a DNS record, not in the signature for exactly
> the reasons you state.

The bottom part of Section 8.4 talks about not sending these automatically, which is kind of in line with what we tell people about FBLs.  Should this just be normative?  It's the same as the DNS idea except the indication is explicit rather than something published, and we're not putting yet another record in the DNS.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2012 19:20:58 -0000

>The bottom part of Section 8.4 talks about not sending these automatically, which
>is kind of in line with what we tell people about FBLs.  Should this just be
>normative?  It's the same as the DNS idea except the indication is explicit rather
>than something published, and we're not putting yet another record in the DNS.

The next question has to be: if you have an external source telling
whose signatures to report, why wouldn't that source also tell you
where to send the reports and how many to send?

If it's supposed to be automatic, then I think it has to be reasonably
resistant to abuse by hostiles, which in this case requires a
hard-to-fake indication of whether you want reports.  If it's manual,
what's the point of a standard?

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Tue, 24 Jan 2012 11:32:10 -0800

> The bottom part of Section 8.4 talks about not sending these automatically, which is kind of in line with what we tell people about FBLs.  Should this just be normative?  It's the same as the DNS i…

Over in draft-ietf-marf-as we are telling people it's OK to send unsolicited reports automatically due to authentication failures. We should be consistent about that, in one direction or the other.

Cheers,
  Steve

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 24 Jan 2012 14:45:29 -0500

On Tuesday, January 24, 2012 11:32:10 AM Steve Atkins wrote:
> > The bottom part of Section 8.4 talks about not sending these
> > automatically, which is kind of in line with what we tell people about
> > FBLs.  Should this just be normative?  It's the same as the DNS idea
> > except the indication is explicit rather than something published, and
> > we're not putting yet another record in the DNS.
> Over in draft-ietf-marf-as we are telling people it's OK to send unsolicited
> reports automatically due to authentication failures. We should be
> consistent about that, in one direction or the other.

In draft-ietf-marf-spf-reporting as well.

I think that the specification needs to be reasonable for automatic reporting 
even if there will often be out of band discussion about it.

Scott K

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, January 24, 2012 11:45 AM
> To: [email-masked]
> I think that the specification needs to be reasonable for automatic
> reporting even if there will often be out of band discussion about it.

OK, I'll work on something like the DNS verification thing John suggested and get a diff or new version out shortly.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Jan 2012 13:34:56 -0800

> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, January 24, 2012 11:21 AM
> To: [email-masked]
> Cc: Murray S. Kucherawy

Wait, isn't that what I had in the last version, where the reporting address was in the key record in the DNS?

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 25 Jan 2012 14:48:08 +0100

On 24/Jan/12 22:34, Murray S. Kucherawy wrote:
>> From: John Levine
> Wait, isn't that what I had in the last version, where the
> reporting address was in the key record in the DNS?

Not exactly, John suggests a separate record like:

Scott notes this solution allows to notify missing or misspelled
selectors.  So, as long as the ADMD don't change both records
simultaneously, this way provides for more stable reporting than
otherwise.  In addition:

 * "_report" is not a valid selector, so there's no conflict, and

 * for a range of [report data] X [key data] sizes, this solution
   may allow to use UDP rather than TCP.

For the consistency problem, and also in order to avoid redefining
report modalities at every turn, I make an appeal to treat them all
together, in reporting-discovery.