Subject: [marf] DISCUSS on draft-ietf-marf-dkim-reporting

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 11 Mar 2012 17:32:22 +0000

The IESG has the following issue they'd like us to resolve on the DKIM reporting draft, and the result might also apply to the SPF reporting draft, before it can be approved for publication.

"- is rr=all a good default? If a bad-actor sends a supposedly signed mail with a DKIM-Signature with 1000  fields then what happens if the Signer's DNS has no rr tag? Maybe some special case for unknown DKIM-Signature tokens or a max on the number of reports for a single message? (Note: I'm assuming that a separate report can be, or is to be, generated for each DKIM-Signature token that fails, clarifying that only one report is ever sent for one inbound mail with a broken signature would also fix this.)"

It's my understanding that we would generate one report per failed signature, because a single message might bear multiple signatures from different domains that have different reporting requirements, so the parenthetical solution won't work for us.  A maximum on the number of reports per message is somewhat arbitrary given that a Verifier can do them in any order.

We have a few options here:

- require an "rr" tag, rather than having a default
- have some default other than "all", chosen from the set of available report requests

And we might in addition:

- add a report request for unknown signature tags

What does the WG think?  The telechat is this coming Thursday, so having this resolved by then would be ideal.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 11 Mar 2012 17:39:32 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Sunday, March 11, 2012 10:32 AM
> To: [email-masked]
> Subject: [marf] DISCUSS on draft-ietf-marf-dkim-reporting
> 
> The IESG has the following issue they'd like us to resolve on the DKIM
> reporting draft, and the result might also apply to the SPF reporting
> draft, before it can be approved for publication.

I just (re-)realized that the deadline for posting an update is 5pm Pacific time on Monday.  After that submissions are frozen until after the Paris meeting.

So a very quick resolution to this would be quite ideal.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Mar 2012 17:10:46 -0400

> draft, before it can be approved for publication.
...
If I understand the comment correctly, I don't think it applies to the SPF 
draft.  An email has exactly one mail from and one helo so there's no way to 
generate lots of arfs from a single messages.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 12 Mar 2012 02:44:50 -0000

>"- is rr=all a good default?

In this case I think it is.  Publishing the record says you want
reports, and it seems reasonable that you'd want all the reports until
you can narrow down the problem.  And if you accept any reports at
all, you better be prepared for a lot of reports, since it's pretty
easy for bad guys to send spam that fails in whatever way you do
accept.

> If a bad-actor sends a supposedly signed mail with a DKIM-Signature with 1000  fields
>then what happens if the Signer's DNS has no rr tag?

If you've published a _report._domainkey record, you get a lot of
reports.  If you haven't, you get no reports.  Seems reasonable to me,
it's opt-in.  If you publish a record inviting reports you don't want,
well, Don't Do That.

>- add a report request for unknown signature tags

That's not an error, but it could be an interesting way to see who's
delivering your mail, which is probably not what you intended.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Mar 2012 23:18:59 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:

>"- is rr=all a good default? If a bad-actor sends a supposedly signed
>mail with a DKIM-Signature with 1000  fields then what happens if the
>Signer's DNS has no rr tag? Maybe some special case for unknown
>DKIM-Signature tokens or a max on the number of reports for a single
>message? (Note: I'm assuming that a separate report can be, or is to
>be, generated for each DKIM-Signature token that fails, clarifying that
>only one report is ever sent for one inbound mail with a broken
>signature would also fix this.)"
>
>It's my understanding that we would generate one report per failed
>signature, because a single message might bear multiple signatures from
>different domains that have different reporting requirements, so the
>parenthetical solution won't work for us.  A maximum on the number of
>reports per message is somewhat arbitrary given that a Verifier can do
>them in any order.
>
>What does the WG think?  The telechat is this coming Thursday, so
>having this resolved by then would be ideal.

Since a domain doesn't have to publish a record asking for these reports and (as an added bonus) ra= doesn't have a default, there's no worry about reports being generated for domains that don't opt-in.

Typically, I think if I needed to moderate volume, rp= would be the right knob to turn anyway.

The most I would do is say something like SHOULD NOT generate more than one report to a single domain per message.  To the extent there's an issue here, I think that addresses it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 04:07:04 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Sunday, March 11, 2012 8:19 PM
> To: [email-masked]
> Subject: Re: [marf] DISCUSS on draft-ietf-marf-dkim-reporting
> 
> The most I would do is say something like SHOULD NOT generate more than
> one report to a single domain per message.  To the extent there's an
> issue here, I think that addresses it.

I think this is my preferred response, given Scott and John's remarks and further comments from the IESG:

- Add the idea Scott mentioned above
- Add the reporting request to indicate unrecognized tags
- Add a paragraph saying someone adding a _report DNS record ought to anticipate receiving a lot of reports

Any objections, or other comments?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 00:14:13 -0400

On Monday, March 12, 2012 04:07:04 AM Murray S. Kucherawy wrote:
...
> - Add the reporting request to indicate unrecognized tags
..
> Any objections, or other comments?

So is "all" now all recognized tags (so to get all recognized tags one would 
ask for "all" and to get everything recognized or not one would need to ask 
for "all" and "unrecognized") or all tags recognized and unrecognized (and to 
get only all the recognized tags they'd have to be individually specified)?

What problem does asking for unrecognized tags solve?  I don't think either of 
those are ideal.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 04:22:38 +0000

> Sent: Sunday, March 11, 2012 9:14 PM
> To: [email-masked]
> So is "all" now all recognized tags (so to get all recognized tags one
> would ask for "all" and to get everything recognized or not one would
> need to ask for "all" and "unrecognized") or all tags recognized and
> unrecognized (and to get only all the recognized tags they'd have to be
> individually specified)?

"all" would now include reports for signatures seen by Verifiers that don't understand at least one tag, plus anything else in the list we've defined as possible events of interest.

> What problem does asking for unrecognized tags solve?  I don't think
> either of those are ideal.

We could also remove the default, making "rr" mandatory so that an implementer has to specify explicitly what report types are of interest.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 00:28:34 -0400

On Monday, March 12, 2012 04:22:38 AM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Scott Kitterman Sent: Sunday, March 11, 2012 9:14 PM
> > To: [email-masked]
> "all" would now include reports for signatures seen by Verifiers that don't
> understand at least one tag, plus anything else in the list we've defined
> as possible events of interest.
> We could also remove the default, making "rr" mandatory so that an
> implementer has to specify explicitly what report types are of interest.

That seems somewhat orthogonal to unrecognized tags.  If we add unrecognized 
tags, that's the default?  I think unrecognized tags probably make sense so 
this draft doesn't have to be updated for each new tag that gets identified, 
but I'm still not understanding how it contributes to resolution of the 
discuss.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 04:44:00 +0000

> Sent: Sunday, March 11, 2012 9:29 PM
> To: [email-masked]

Me either, now that you mention it.  I'll ask.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 07:28:57 +0000

> Sent: Sunday, March 11, 2012 9:44 PM
> To: [email-masked]
> > That seems somewhat orthogonal to unrecognized tags.  If we add
> > unrecognized tags, that's the default?  I think unrecognized tags
> > probably make sense so this draft doesn't have to be updated for each
> > new tag that gets identified, but I'm still not understanding how it
> > contributes to resolution of the discuss.
> 

Got a reply: He found the text ambiguous about whether the report is generated per signature, or per tag within a signature that went awry somehow.

The one-report-per-domain-per-message thing satisfies his concern and will clear the DISCUSS.  The other one is indeed orthogonal.  I'd be fine with leaving it in, however, unless someone sees a problem with doing so.

Any other comments or objections?  If not, I'll post a -13 version in time to beat the embargo late on Monday.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 12 Mar 2012 09:30:18 +0100

On 12/Mar/12 08:28, Murray S. Kucherawy wrote:
> 
> Got a reply: He found the text ambiguous about whether the report
> is generated per signature, or per tag within a signature that went
> awry somehow.
>
> The one-report-per-domain-per-message thing satisfies his concern
> and will clear the DISCUSS.

The correct clarification is one report per /signing/ domain per
message.  If a domain includes multiple signatures in a given message,
they may get a report for each failed one.

> The other one is indeed orthogonal. I'd be fine with leaving it in,
> however, unless someone sees a problem with doing so.

I agree unrecognized tags might be interesting, e.g. as a tool to
monitor verifiers' adoption of new tags.  However, if a domain decided
to add such tag, there's nothing they can do about those reports,
except encouraging verifiers to upgrade their software.

Perhaps, it makes sense to keep "all" the default, but require
rr=all:u to also get unrecognized tags reports.

Would those reports need to be routed to a different team/script?

Should they be tagged, say, Feedback-Type: auth-feedback, rather than
auth-failure?

Just fancying...

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 07:01:48 -0400

>they may get a report for each failed one.

Since reports are generated based on the purported signing domain it doesn't matter either way.

>Should they be tagged, say, Feedback-Type: auth-feedback, rather than

In the context of this draft, it must be about auth failure. If the signature verified, then it's something else.

Absent a compelling reason (and I see no compelling reason), I think altering the definition of all is a mistake. Any future drafts that add new tags can update this one to extend the list off allowable tags (and thus the definition of all).  I'd leave unknown tags out.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 13:54:40 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, March 12, 2012 1:30 AM
> To: [email-masked]

Yes, that's the change I'm proposing.

> Perhaps, it makes sense to keep "all" the default, but require rr=all:u
> to also get unrecognized tags reports.

That's not very "all" then...

> Would those reports need to be routed to a different team/script?

I sure hope not!

> Should they be tagged, say, Feedback-Type: auth-feedback, rather than

It's way too late to try that now, I think.  Bogus tags could indeed be a sign of attempts to confound verifiers, so I think for now they're fine to include as abuse reporting, the same as our various other possible requests.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 13:57:49 +0000

> Sent: Monday, March 12, 2012 4:02 AM
> To: [email-masked]
> Absent a compelling reason (and I see no compelling reason), I think
> altering the definition of all is a mistake. Any future drafts that add
> new tags can update this one to extend the list off allowable tags (and
> thus the definition of all).  I'd leave unknown tags out.

I think if that's the case, then "all" changes meanings depending on the version being implemented, and that's begging for either a "v=" tag in the _report record, or the removal of "all" and no default so the full set has to be listed explicitly.

Given the choice, I'd opt for the latter.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 10:00 -0400

On Monday, March 12, 2012 01:57:49 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Monday, March 12, 2012 4:02 AM
> > To: [email-masked]
> I think if that's the case, then "all" changes meanings depending on the
> version being implemented, and that's begging for either a "v=" tag in the
> _report record, or the removal of "all" and no default so the full set has
> to be listed explicitly.
> 

Option 3: Leave all as the default and say to ignore unknown tags.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 14:02:01 +0000

> Sent: Monday, March 12, 2012 7:00 AM
> To: [email-masked]

So define "all" to mean "all but not u"?

Or something like "If 'all' is listed first, anything else listed means 'all except...'"?

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 10:40:21 -0400

On Monday, March 12, 2012 02:02:01 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Monday, March 12, 2012 7:00 AM
> > To: [email-masked]

I'd been thinking all means all known.  Unless we can specify processing for 
unknown tags in advance, I think it's the best we can do.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 15:42:30 +0000

> Sent: Monday, March 12, 2012 7:40 AM
> To: [email-masked]
> I'd been thinking all means all known.  Unless we can specify
> processing for unknown tags in advance, I think it's the best we can
> do.

Ah, I thought you meant "ignore unknown tags" means "ignore 'u'", not "ignore rr= elements you don't know about".

We already say the latter, so I think we're in agreement.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 15:55:53 +0000

The diff of what's included in -13 compared to what's posted now can be seen at http://www.blackops.org/~msk/marf-dkim.html.  Please let me know if there are any concerns about this before about 16:00 PDT today, at which time I'll prepare and post the revision.

Thanks,
-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 12 Mar 2012 15:59:37 +0000

Hi Murray,

That looks great and fine for me to clear.

Thanks
S

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2012 02:28:43 -0000

>Yes, that's the change I'm proposing.

Seems reasonable to me.

R's,
John