Subject: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft

From: Alessandro Vesely <[email-masked]>
Date: Sun, 03 Jul 2011 12:13:22 +0200

On 31/Mar/11 09:09, Murray S. Kucherawy wrote:
> On 31/Mar/11 09:03, Hilda Fontana wrote:
>> On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy wrote:
>> 
>>> The consensus at our IETF 80 meeting was to divide the DKIM 
>>> reporting draft into smaller documents.  I believe the split 
>>> should go as follows:
>>> 
>>> -  Defining the auth-failure report type (someone besides me
>>>    should take up authorship of this, but I’ll do it if nobody 
>>>    steps up)
>> 
>> what does it mean "Defining the auth-failure report type" with
>> DKIM, SPF and Redaction not included?
>
> One document would register the changes to DKIM and ADSP (i.e. the
> updates to the registered lists of tags and values) and one would
> register the new ARF report type.  The two documents can be published
> simultaneously and refer to each other.

I should have raised this issue some months ago, but I hadn't clearly
understood the details of the splitting at the time.

One the one hand, the SPF and DKIM method-extensions include similar
text, thereby making it harder to change any of those parts.  On the
other hand, the ARF extension mentions DKIM and SPF details again and
again, resulting in tight coupling with each method-extension.

Alternatively, the ARF extension could list what a method extension
must do in order to define and register the details of
failure-reporting for the specific authentication method it addresses.
 I mentioned this possibility in a recent message of mines, but nobody
apparently cares.  I'm confused, or perhaps it's just July...

Which of the following, if any, is correct?

A       The ARF extension will gain in comprehensibility by removing
        any method-specific detail.  Since that's where admins may
        eventually look for deciding whether to enable such feature
        in their software, it is better to have it uncluttered.

        BTW, why don't we also split dkim-adsp from dkim?

B       The splitting is fine as it is, although not in a "normal
        form".  It is extremely unlikely that "iprev" or any other
        method will ever need a failure reporting mechanism.  The
        sooner we go to testing and deploying, the better.

---

From: "Hilda Fontana" <[email-masked]>
Date: Tue, 5 Jul 2011 09:11:58 -0700

Not sure I follow what your asking?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
Sent: Sunday, July 03, 2011 3:13 AM
To: [email-masked]
Subject: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft

On 31/Mar/11 09:09, Murray S. Kucherawy wrote:
>>> reporting draft into smaller documents.  I believe the split should 
>>> go as follows:
>>> 
>> what does it mean "Defining the auth-failure report type" with DKIM, 
>> SPF and Redaction not included?
>

I should have raised this issue some months ago, but I hadn't clearly understood the details of the splitting at the time.

One the one hand, the SPF and DKIM method-extensions include similar text, thereby making it harder to change any of those parts.  On the other hand, the ARF extension mentions DKIM and SPF details again and again, resulting in tight coupling with each method-extension.

Alternatively, the ARF extension could list what a method extension must do in order to define and register the details of failure-reporting for the specific authentication method it addresses.
 I mentioned this possibility in a recent message of mines, but nobody apparently cares.  I'm confused, or perhaps it's just July...

?? in what way are you suggesting?

?not in a normal form?
_______________________________________________
marf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/marf

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 05 Jul 2011 20:00:14 +0200

Hi Hilda,

> Not sure I follow what your asking?  

Hm... my English is what it is, please be patient :-)

>> Alternatively, the ARF extension could list what a method
>> extension must do in order to define and register the details of

Roughly, a section more or less like

   X.Y.Z.  Definition and Registration of Method-Specific Extensions

   The IANA maintains a registry of Email Authentication Methods
   along with their possible results.  A "method-specific extension"
   extends an authentication method by providing for the possibility
   to report its result using the ARF format specified in this
   document.  Any such extension must specify:

   *  which method(s) it addresses;

   *  which result(s) of the addressed method(s) deserve being
      reported;

   *  a list of one or more keywords to be used in the Auth-Failure
      field when reporting such results; and

   *  the location and the syntax of the report parameters whose
      semantic content is described in Section U.V.W.

   In addition, a method-specific extension may define further ARF
   header fields.  In case it does so, it shall also define the
   corresponding updates to ARF header field names in its IANA
   Considerations section.

Section U.V.W would discuss r, rf, and ri, and possibly mention ro and
rs too.  Not how they are syntactically encoded, just what they mean.

Does the above make sense?

>>         sooner we go to testing and deploying, the better.

"Normal" in the sense of orthogonal or perpendicular; that is, having
independent semantics along the "axes".  Basically, I mean loosely
coupled with the method extensions.

Indeed, I think authfailure-report can be written without mentioning
neither "dkim" nor "spf", except for possible examples.  I guess that
would enhance comprehensibility.  However, the WG should decide
whether to go this way _before_ delving into any finer tuning, if it's
not too late already.

---

From: "Hilda Fontana" <[email-masked]>
Date: Tue, 5 Jul 2011 11:25:48 -0700

> Section U.V.W would discuss r, rf, and ri, and possibly mention ro and rs
too.
> Not how they are syntactically encoded, just what they mean.
> 
So your saying it needs a rewrite - it was really meant to be a fairly
simple straightforward way to report auth failures in a useable way i.e.
extending what arf/marf already do - does it not to that in your opinion?
Or are you looking for it to do something else.

The current report format defined in [ARF] lacks some specific
features required to do effective sender authentication reporting.
This section defines extensions to ARF to accommodate this
requirement.
 
> independent semantics along the "axes".  Basically, I mean loosely coupled
> with the method extensions.

It is meant to be specific - I don't think "loosely" is a good track

---

From: "Hilda Fontana" <[email-masked]>
Date: Tue, 5 Jul 2011 11:21:35 -0700

> Indeed, I think authfailure-report can be written without mentioning
neither
> "dkim" nor "spf", except for possible examples.  I guess that would
enhance
> comprehensibility.  However, the WG should decide whether to go this way
> _before_ delving into any finer tuning, if it's not too late already.

The problem right now is that each arf message generated due to auth
failures are formatted differently and it makes automation very difficult -
if we don't tie the authfailure messages minimally to dkim and spf - I don't
think we have accomplished anything - at the very least I think they should
be the minimum with the option to extend for future.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Jul 2011 11:48:18 -0700

> Sent: Tuesday, July 05, 2011 11:00 AM
> To: Hilda Fontana
> Cc: [email-masked]
> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim-reporting draft
> 

We're adding DKIM and SPF reporting to ARF in this way because they both pre-date ARF in the official sense.  I think the current approach makes sense; this document extends ARF and the spf-reporting and dkim-reporting documents extend SPF and DKIM respectively, and they're all compatible with each other.

I think if the working group feels this is a good idea to write down for future extensions, we can produce another Informational document that explains the things one should consider in terms of creating a new email authentication method, including registering and defining reporting extensions both in terms of ARF and RFC5451.  Or, as a lesser approach, that could become an appendix of this one.

> whether to go this way _before_ delving into any finer tuning, if it's

Ignoring redaction for the moment, what we have now is:

- authfailure-report modifies ARF
- dkim-reporting modifies DKIM and ADSP
- spf-reporting modifies SPF

That seems nice and clean.  Your proposal changes it to:

- authfailure-report modifies ARF
- dkim-reporting modifies DKIM and ADSP, and also modifies authfailure-report
- spf-reporting modifies SPF, and also modifies authfailure-report

At a glance the first method seems cleaner to me.  On the other hand, the latter is a more clear demonstration of how future email authentication methods will need to create reporting hooks.

What do others think?  And let's try to make this the last revisit of the arrangement of this work so that we can make some progress.

Thanks,

-MSK

---

From: "Hilda Fontana" <[email-masked]>
Date: Tue, 5 Jul 2011 13:25:21 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murray S. Kucherawy
> Sent: Tuesday, July 05, 2011 11:48 AM
> To: [email-masked]
> We're adding DKIM and SPF reporting to ARF in this way because they both
> pre-date ARF in the official sense.  I think the current approach makes
sense;
> this document extends ARF and the spf-reporting and dkim-reporting
> documents extend SPF and DKIM respectively, and they're all compatible
> with each other.
> 
> I think if the working group feels this is a good idea to write down for
future
> extensions, we can produce another Informational document that explains
> the things one should consider in terms of creating a new email
> authentication method, including registering and defining reporting
> extensions both in terms of ARF and RFC5451.  Or, as a lesser approach,
that
> could become an appendix of this one.
> 
> At a glance the first method seems cleaner to me.  On the other hand, the
> latter is a more clear demonstration of how future email authentication
> methods will need to create reporting hooks.
> 
> What do others think?  And let's try to make this the last revisit of the
> arrangement of this work so that we can make some progress.
> 
> Thanks,
> 
> -MSK
+1

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 06 Jul 2011 12:12:43 +0200

On 05/Jul/11 20:48, Murray S. Kucherawy wrote:
> At a glance the first method seems cleaner to me.  On the other
> hand, the latter is a more clear demonstration of how future email
> authentication methods will need to create reporting hooks.

A more realistic advantage of the second method is to allow editing,
say, dkim-reporting without having to negotiate dkim-related
modifications with a given version of authfailure-report.

> What do others think?  And let's try to make this the last revisit
> of the arrangement of this work so that we can make some progress.

+1

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Wed, 06 Jul 2011 12:51:21 -0400

In <[email-masked]>, on 07/03/2011

>        any method-specific detail. 

That would be my preference.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 6 Jul 2011 15:53:59 -0400

On Wednesday, July 06, 2011 06:12:43 AM Alessandro Vesely wrote:
> > - dkim-reporting modifies DKIM and ADSP, and also modifies
> > authfailure-report - spf-reporting modifies SPF, and also modifies
> > authfailure-report
> > 

I'm happy either way.  I would like a decision to be made soon so we can get 
updated drafts in prior to the July 11 cutoff.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jul 2011 18:16:11 -0400

Hilda, when you put a "+1" at the end of a message like this, I can't
tell what you're agreeing with.  Murray didn't make a single statement
in his message -- in the end, he gave alternatives and asked what
people think.

Can you be specific about what you agree with?

Barry

---

From: "Hilda Fontana" <[email-masked]>
Date: Wed, 6 Jul 2011 15:18:49 -0700

I understand Barry - and I did re-respond specifying what I agreed with -
I'm just getting used to the process 

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Wednesday, July 06, 2011 3:16 PM
> To: Hilda Fontana
> Cc: Message Abuse Report Format working group
> Hilda, when you put a "+1" at the end of a message like this, I can't tell
what
> you're agreeing with.  Murray didn't make a single statement in his
message -
> - in the end, he gave alternatives and asked what people think.
> 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Murray S. Kucherawy
> >> Subject: Re: [marf] Cohesion of authfailure-report, was Split of
> >> dkim- reporting draft
> >>
> >> > Section U.V.W would discuss r, rf, and ri, and possibly mention ro
> >> > and rs too.  Not how they are syntactically encoded, just what they
> mean.
> >> >
> >> We're adding DKIM and SPF reporting to ARF in this way because they
> >> both pre-date ARF in the official sense.  I think the current
> >> approach makes
> > sense;
> >> documents extend SPF and DKIM respectively, and they're all
> >> compatible with each other.
> >>
> >> extensions, we can produce another Informational document that
> >> explains the things one should consider in terms of creating a new
> >> email authentication method, including registering and defining
> >> reporting extensions both in terms of ARF and RFC5451.  Or, as a
> >> lesser approach,
> > that
> >> > Indeed, I think authfailure-report can be written without
> >> > mentioning neither "dkim" nor "spf", except for possible examples.
> >> > I guess that would enhance comprehensibility.  However, the WG
> >> > should decide whether to go this way _before_ delving into any
> >> > finer tuning, if it's not too late already.
> >>
> >> authfailure- report
> >> At a glance the first method seems cleaner to me.  On the other hand,
> >> the latter is a more clear demonstration of how future email
> >> What do others think?  And let's try to make this the last revisit of
> >> the arrangement of this work so that we can make some progress.
> >>
> >> Thanks,
> >>
> >> -MSK
> > +1
> >

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jul 2011 18:19:00 -0400

> That would be my preference.

So, in terms of Murray's message (see below), which arrangement are
you agreeing with?

Barry

Murray said...
> What do others think?

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jul 2011 18:23:56 -0400

> methods will need to create reporting hooks.

I think I marginally prefer Alessandro's proposal.  But it's a very
marginal preference -- I think either arrangement will work fine.

Barry, as participant

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 6 Jul 2011 15:44:33 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Wednesday, July 06, 2011 3:24 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [marf] Cohesion of authfailure-report, was Split of dkim- reporting draft
> 

I'll follow up shortly with a summary of who has to change what.  It would be great if we could all do so before the deadline on the 11th.

---

From: Hfontana <[email-masked]>
Date: Wed, 6 Jul 2011 16:22:43 -0700

My preference would be the first one seems clearer to me

>> authfailure-report modifies ARF

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 6 Jul 2011 21:19:28 -0700

+1

We can already see that the modifications to DKIM and ADSP are different from the modifications to SPF, so a draft which makes all modifications generic is unlikely to ever modify anything sufficiently by itself.  In other words, we'll have to do just as much work for each future authentication method (if indeed there ever are any) either way, so I think we should take the path of less work now.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jul 2011 10:15:13 -0400

> We can already see that the modifications to DKIM and ADSP are
> different from the modifications to SPF, so a draft which makes all
> modifications generic is unlikely to ever modify anything sufficiently
> by itself.  In other words, we'll have to do just as much work for each
> future authentication method (if indeed there ever are any) either way,
> so I think we should take the path of less work now.

J.D. has convinced me to shift my preference (I said it was close...).
 I agree with J.D.

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jul 2011 10:17:14 -0400

> I'll follow up shortly with a summary of who has to change what.
>  It would be great if we could all do so before the deadline on
> the 11th.

To be clear:
As chair, I see the consensus on leaving the split as originally
planned.  Alessandro has a good point, but I think WG consensus is
against going that way.

Barry, as chair

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 10:45:27 -0400

> planned.  Alessandro has a good point, but I think WG consensus is

Thanks.  I have had a few comments against my draft, so I'll post a -01 before 
the July 11 deadline.  If people have been waiting to review draft-ietf-marf-
spf-reporting-00, don't wait any longer.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Jul 2011 18:34:59 +0200

> planned.  Alessandro has a good point, but I think WG consensus is

I respect the WG decision.  However, I'd recommend that the discussion
of the meaning of r, rf, and ri be factored in the authfailure-report
anyway, as it's not yet final and updating it separately in four
occurrences would be a nuisance.  Currently, authfailure-report
proposes an exponential growth of the interval, while the other two
drafts account for three slightly different definitions of ri.  In no
case it is specified how a stateless verifier should behave.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 7 Jul 2011 09:44:42 -0700

> Sent: Thursday, July 07, 2011 9:35 AM
> To: [email-masked]
> occurrences would be a nuisance.

It seems to me there could be an authentication method declared later that doesn't want to support a reporting format other than "arf", or for which a reporting interval doesn't make any sense, so I don't think it's useful to make them universally-defined properties.

However, I suspect a section in the authfailure-report draft suggesting that future extensions will probably need <some set of properties here, including at least a reporting address>, as advisory text only, would not be harmful.

> Currently, authfailure-report
> drafts account for three slightly different definitions of ri.

I don't see the text you're referencing here about exponential growth in authfailure-report.  Can you point me to it?

I suppose it would be nice if all of the "ri" definitions had identical behavior (and I think they currently do), but I don't see a reason to require it.

> In no

Since participation in these extensions is not mandatory, I imagine one electing to honor what "ri" says can't be stateless, by definition.

-MSK [participant]

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 7 Jul 2011 12:57:16 -0400

On Thursday, July 07, 2011 12:44:42 PM Murray S. Kucherawy wrote:
...
> Since participation in these extensions is not mandatory, I imagine one
> electing to honor what "ri" says can't be stateless, by definition.
...
True.  I guess the question that ought to be defined is if it's appropriate to 
participate in only a subset of the extension?  I think it would be reasonable 
to say that if you are going to send auth failure FBRs, then you MUST honor 
"ri" if specified.  That leaves you two choices:

1.  Don't be stateless.
2.  Don't submit FBRs for any domain that specifices "ri".

I think participating in the extension, but ignoring the volume knob is not 
OK.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 07 Jul 2011 19:45:42 +0200

[Subject edited]

On 07/Jul/11 18:44, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>> 
>> I'd recommend that the discussion of the meaning of r, rf, and ri
>> be factored in the authfailure-report anyway, as it's not yet
>> final and updating it separately in four occurrences would be a
>> nuisance.
> 
> It seems to me there could be an authentication method declared
> later that doesn't want to support a reporting format other than
> "arf", or for which a reporting interval doesn't make any sense, so
> I don't think it's useful to make them universally-defined
> properties.

>From a very general point of view, yes, even if I'm unable to imagine
why it would.  Those definitions are only relevant to the somewhat
restricted "universe" of email authentication failures, which is
exactly what the draft addresses.  Thus, it will make sense to update
it whenever unforeseen requirements arise.

> I don't see the text you're referencing here about exponential
> growth in authfailure-report.  Can you point me to it?

Section 7.5:

                                           One might even do something
   inverse-exponentially, sending reports for each of the first ten
   incidents, then every tenth incident up to 100, then every 100th
   incident up to 1000, etc. until some period of relative quiet after
   which the limitation resets.

Interesting, isn't it?

> I suppose it would be nice if all of the "ri" definitions had
> identical behavior (and I think they currently do), but I don't see
> a reason to require it.

I makes it easier to write and to read them.  To wit, expressing
identical behavior with different wording would be even worse.

> I think participating in the extension, but ignoring the volume knob is not 

I agree with Scott.  However, in some cases ri might be just a
preference (in a previous message I proposed "ri=10e+".)  Otherwise, a
stateless reporter could generate a random number and calculate a
given probability.  The incident count won't be exact in such cases.

An interval is not exactly the same as a volume knob, as different
domains do different volumes.  If one is less interested in an exact
count, it would make more sense to get the first report and then
nothing for the next 99, than completely missing failures that account
for less than 100 occurrences per domain.  The exponential approach
solves this issue nicely.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 07 Jul 2011 14:06:04 -0400

In
<CAC4RtVAag5AKG-jRsyQujNCVMCa7S1n8bjsW=[email-masked]>,
on 07/06/2011
   at 06:19 PM, Barry Leiba <[email-masked]> said:

>To: [email-masked]
>Cc: Message Abuse Report Format working group <[email-masked]>

Please don't do that. One copy is sufficient.

>So, in terms of Murray's message (see below), which arrangement are

Neither. I'm agreeing with moving details specific to particular
authentication messages into drafts other than the main draft or into
a registry[1] maintained by IETF or IANA. That imples that

 - authfailure-report modifies ARF
 - dkim-reporting refers to but does not modify authfailure-report
 - spf-reporting refers to but does not modify authfailure-report

[1] In particular, the two IANA registries mentioned in section 6
    of RFC 5965

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 10 Jul 2011 15:33:22 +0200

>    which the limitation resets.

I've been wandering about such period.  If we use the record's
Time-To-Live (TTL) we can specify stateless reporting like so:

On diagnosing a failure, the agent generates a random number R in the
interval [0, 1] (or sets R=0.5).  It then computes a value P using
numeric values from the retrieved RR and a formula to be specified in
authfailure-report.  If P >= R, then the agent generates and sends the
report, otherwise does nothing.

P may be computed so as to be near to 1 for newly retrieved records
and then decreasing more or less rapidly, according to the value of
ri.  The following gnuplot snippet displays suitably scaled Gaussian
curves (aka bump functions) for a few values of ri

-----8<----------8<-------cut-here-------8<----------8<-----
#! /usr/bin/gnuplot -p
reset
set title 'P = p(ri*(1 - TTL/TTLMAX)) for TTLMAX=86400'
set xrange [0:86400]
set key left
e=exp(1)
p(x) = abs(x)<1? e*exp(-1/(1-x**2)): 0
plot p(1*(1 - x/86400)), \
	p(2*(1 - x/86400)), \
	p(3*(1 - x/86400)), \
	p(4*(1 - x/86400)), \
	p(5*(1 - x/86400))
-----8<----------8<-------cut-here-------8<----------8<-----

pros:
* supports stateless agents,
* probability decreases exponentially,
* automatic period reset,
* leverages DNS cache, thus favoring reporting to "new" (not cached)
  domains, i.e. from infrequently targeted agents whose A-Rs are
  more likely to be yet unknown.

cons:
* Issuers might need a different TTL for reasons independent of
  failure reporting,
* agents using a resolver that may deliver second hand RRs would
  seldom get a TTL near to TTLMAX, and
* TTLMAX (or similar value) has to be explicitly written in the RR.

Thoughts?