Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Oct 2011 10:45:37 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, October 08, 2011 11:43 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: New Version Notification - draft-ietf-marf-authfailure-report-03.txt
> 
> New version (-03) has been submitted for draft-ietf-marf-authfailure-report-03.txt.
> http://www.ietf.org/internet-drafts/draft-ietf-marf-authfailure-report-03.txt
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-marf-authfailure-report-03

<participant>
Going over the diff, I spot the following:

1. Introduction:

	s/use extend/extend/

	s/fail to authenticate/fail evaluation/

3.1. New ARF Feedback Type

	s/once if it/once if it is/ (or just "once if")

	s/3.2.1 is OPTIONAL, MUST NOT/3.2.1.  It is OPTIONAL, but MUST NOT/

3.2.3. Optional For DKIM Reports

	Move the descriptive paragraph to the end of the section rather than the beginning.

B.1. Example Use of ARF Extension Headers

	What was the reason for replacing the example that was there?

	Delivered-To isn't a known header field and should be deleted.

	The Received-SPF line isn't properly wrapped.  Also since SPF is planning to switch to
	Authentication-Results, it should possibly be removed as it's redundant to the line
	below it anyway.

	Change all the example domain names to end in "example", or be specifically "example.com",
	"example.net", or "example.org".

	The example is missing a MIME-Version header field.

	In the first MIME part, "(GMT)" should probably be preceded by a space.

	I'm not sure what "Content-Disposition: inline" means for the parts of an ARF message.
</participant>

Everyone else that weighed in, please review the new version and comment.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Oct 2011 10:46:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Murray S. Kucherawy
> Sent: Monday, October 10, 2011 10:46 AM
> To: [email-masked]
> Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure-report-03.txt
> 

See RFC2606 for further details.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 10 Oct 2011 23:12:02 +0200

> 	What was the reason for replacing the example that was there?

IMHO, the example in -03 is better than the previous one.  It would be
useful to see also examples with DNS records.

> 	Authentication-Results, it should possibly be removed as it's redundant to the line

The Authentication-Results is also badly wrapped.

> Everyone else that weighed in, please review the new version and comment.

The Auth-Failure field is missing from feedback-report.

Authentication-Results is also missing from feedback-record, which
might be alright since it is already in rfc822-headers.  The spec in
section 3.1 does not agree with this reasoning, though.

(And the User-Agent's /version looks different than Version:)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Oct 2011 14:20:43 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, October 10, 2011 2:12 PM
> To: [email-masked]

What's important here (to my mind) is that A-R has to be present in the report not just in the included message/header, because there might be more than one in the latter.   The one(s) generated by the reporting host are the ones that need to be in the second MIME part of the report.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 Oct 2011 09:20:33 +0200

On 10/Oct/11 23:20, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>> 
> What's important here (to my mind) is that A-R has to be present in
> the report not just in the included message/header, because there
> might be more than one in the latter.   The one(s) generated by the
> reporting host are the ones that need to be in the second MIME part
> of the report.

Good point.  As an alternative, we could identify the
report-triggering results by reference, letting generators declare
their authserv-id.  For example, adding the following line in the
second part of the current example:

   Authentication-Server-Id: mta1011.mail.tp2.someisp.com

This alternative may allow a generator to piecewise write the A-R
fields directly to the relevant stream, rather than building them in
memory.  At the recipient's, this alternative just prevents the
embarrassment of choice; e.g., what if the second part's A-R fields
seem to differ from their third part's correlatives?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 11 Oct 2011 08:18:49 -0500

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

>> 	"example.net", or "example.org".

AFAIK, "example" is defined only as a SLD, so the example domain names
should end in "example.*" or "invalid".

>>or be specifically "example.com", "example.net", or 
>>"example.org".

But *not* "example".

-- 
     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: "John Levine" <[email-masked]>
Date: 11 Oct 2011 15:28:00 -0000

>But *not* "example".

Sigh.  Please read RFC 2606.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 11 Oct 2011 10:39:42 -0700

> Sent: Tuesday, October 11, 2011 12:21 AM
> To: [email-masked]

There's nothing requiring a verifier to affix an A-R field in the first place, nor is there any guarantee that the verifier has properly stripped forgeries.  Thus, what's in the second part is exactly what you're suggesting, and is possibly more reliable than what's in the third part.  Moreover, the copy that's in the third part might be extracted before the local one is even added.

It's right where it is, and doesn't need modification.

---

From: "John Levine" <[email-masked]>
Date: 12 Oct 2011 04:11:12 -0000

This draft is a great improvement.

I would strongly suggest changing the text to say there must be exactly
one authentication-results header in the report.  If there's more than
one, particularly if there are multiple DKIM failures, there's no way
to tell which other parts of the report go with which a-r header.

Note that multiple DKIM failures could easily have multiple reported domains,
multiple auth-failure, dkim-domain, dkim-identity, dkim-selector,
dkim-canonicalized-header, and dkim-canonicalized body.  (Remember that
there are two different ways to canonicalize each.)

Rather than inventing complex rules about which item goes with which
report, if you have three failures, send three reports.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Oct 2011 12:05:29 -0700

> From: John Levine [mailto:[email-masked]]
> Sent: Tuesday, October 11, 2011 9:11 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

An Authentication-Results field can list several different DKIM failures if the message was multiply defined.  That makes the other DKIM-* fields important, as they make it clear which one the report is covering.

It would be easy to group repeated DKIM-* fields together, separated by blank lines, to allow relaying DKIM forensics about each, but separately.  Is that too complex?

---

From: "John Levine" <[email-masked]>
Date: 13 Oct 2011 06:14:55 -0000

>An Authentication-Results field can list several different DKIM
>failures if the message was multiply defined.  That makes the other
>DKIM-* fields important, as they make it clear which one the report
>is covering.

>It would be easy to group repeated DKIM-* fields together, separated
>by blank lines, to allow relaying DKIM forensics about each, but
>separately.  Is that too complex?

Hmmn.  We already allow multiple groups each consisting of an auth-res
header each followed by some other stuff.  I suppose we could define
subgroups consisting of auth-failure, then dkim-domain, then other
stuff.  But I worry that people will get it wrong.  Presumably an a-r
could report multiple failures but you only send a report for
the one that is likely to be of interest to the report target, so
we need to be sure that the target can tell which failure all the
subgroup stuff refers to.

I see that the ABNF in section 4 of the draft doesn't update the
feedback-report ABNF in section 3.5 of RFC 5965.  It better do that
or there's no place in an ARF report where the new lines can occur.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Oct 2011 23:24:38 -0700

> Sent: Wednesday, October 12, 2011 11:15 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

The other idea I had borrows from a MIME extension:

Authentication-Results*0: ...
DKIM-Domain*0: ...
DKIM-Selector*0: ...

Authentication-Results*1: ...
DKIM-Domain*1: ...
DKIM-Selector*1: ...

Not pretty, but it would work.

I'm a little worried about the "send one report per authentication failure" because if I send a message with twenty bogus signatures bearing your domain name, that's an amplification attack.

> or there's no place in an ARF report where the new lines can occur.

It's covered by "ext-field" in Section 3.5 of RFC5965, isn't it?

---

From: "John Levine" <[email-masked]>
Date: 13 Oct 2011 06:31:28 -0000

>Not pretty, but it would work.

Yuck.

>I'm a little worried about the "send one report per authentication
>failure" because if I send a message with twenty bogus signatures
>bearing your domain name, that's an amplification attack.

I suppose, although if I want to mailbomb you indirectly, it's not
noticably harder to send 20 messages each with one bogus signature.
Until now, all of the major use of ARF was to send back mail to the
actual sender, so you could never get more reports than you sent mail.
This thing solicits reports of mail sent by other people so the risk
of indirect mailbomb is in inherent in it.

>It's covered by "ext-field" in Section 3.5 of RFC5965, isn't it?

Not if they're supposed to go into the repeating groups.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Oct 2011 00:15:38 -0700

> Sent: Wednesday, October 12, 2011 11:31 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy

Sounds like fodder for Security Considerations then.

> Not if they're supposed to go into the repeating groups.

Oops, right.

---

From: "Hilda Fontana" <[email-masked]>
Date: Thu, 13 Oct 2011 09:50:59 -0700

" Rather than inventing complex rules about which item goes with which
report, if you have three failures, send three reports"

I think there is going to be a lot of push back for multiple failure reports
per email - would definitely be better to find the best way to specify the
multiple failures within one email for the email that had the failures in
it. - i.e. one to one

> John Levine
> Subject: Re: [marf] New Version Notification -
draft-ietf-marf-authfailure-
> report-03.txt
one
> authentication-results header in the report.  If there's more than one,
> particularly if there are multiple DKIM failures, there's no way to tell
which
> other parts of the report go with which a-r header.
> 
> Note that multiple DKIM failures could easily have multiple reported
> domains, multiple auth-failure, dkim-domain, dkim-identity, dkim-selector,
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf

---

From: "John R Levine" <[email-masked]>
Date: 13 Oct 2011 13:41:35 -0400

> per email

Keeping in mind that these are primarily intended for computers rather 
than people to read, what problem does multiple reports cause?  They all 
contain a copy of the same message, if you want to correlate them, the 
programming is trivial.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Oct 2011 17:43:50 +0200

> Authentication-Results*1: ...

If we stick to the "exactly one" A-R record, why would we need more
fields?  Each "resinfo" line already has all the information we need,
already correctly grouped --except for selectors, we miss header.s if
we don't want to retrieve s= from the third part, in the signature
having the corresponding header.b.

The only other data is the TXT RRs the verifier found.  We ought to
devise a format that allows as many of these as needed, with each
repeated field including the query as well.  It'd be a nuisance to
require different formatting according to the purpose of each RFC 1035
packet.

jm2c

---

From: "Hilda Fontana" <[email-masked]>
Date: Fri, 14 Oct 2011 12:07:47 -0700

> Keeping in mind that these are primarily intended for computers rather
than
> people to read, what problem does multiple reports cause?  They all
contain
> a copy of the same message, if you want to correlate them, the programming
> is trivial.

I totally agree I was thinking more of the push back from those generating
them rather than those receiving them.

> From: John R Levine [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 10:42 AM
> To: Hilda Fontana
> Cc: ARF mailing list
> Subject: RE: [marf] New Version Notification -
> > I think there is going to be a lot of push back for multiple failure
> > reports per email
> 
than
> people to read, what problem does multiple reports cause?  They all
contain
> a copy of the same message, if you want to correlate them, the programming
> is trivial.
> 
> R's,
> John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Oct 2011 12:33:12 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hilda Fontana
> Sent: Friday, October 14, 2011 12:08 PM
> To: 'John R Levine'
> Cc: 'ARF mailing list'
> > Keeping in mind that these are primarily intended for computers rather than
> > people to read, what problem does multiple reports cause?  They all contain

Can we get some commentary from others on this?  I'd like to get a measure for where consensus falls.  Since this is the only current point of discussion, we might be close to being able to WGLC it again.

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 14 Oct 2011 12:42:25 -0700

> Can we get some commentary from others on this?  I'd like to get a measure for where consensus falls.  Since this is the only current point of discussion, we might be close to being able to WGLC it…

I'd like to see what happens in the real world before we start inventing complex, ugly kludges that only apply to what I expect will be extremely rare edge cases.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Oct 2011 12:43:27 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Friday, October 14, 2011 12:42 PM
> To: ARF mailing list
> I'd like to see what happens in the real world before we start
> inventing complex, ugly kludges that only apply to what I expect will
> be extremely rare edge cases.

Is that a vote in favour of just sending one report for each type of failure?

---

From: "John R Levine" <[email-masked]>
Date: 14 Oct 2011 17:23:38 -0400

> them rather than those receiving them.

Well, OK.  Given that ARF messages are invariably generated by software 
rather than by people, what problem is caused by them generating two or 
three messages to report multiple failures rather than one?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 14 Oct 2011 17:01:26 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
> Sent: Friday, October 14, 2011 2:24 PM
> To: Hilda Fontana
> Cc: 'ARF mailing list'

I have to say I agree that the idea of sending one report for every DKIM/SPF failure on a message is un-pretty, but it's less un-pretty than the two syntactical alternatives that have been put forward in this thread.

-MSK, as participant

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 15 Oct 2011 14:45:59 +0200

On 15/Oct/11 02:01, Murray S. Kucherawy wrote:
> 
> I have to say I agree that the idea of sending one report for every
> DKIM/SPF failure on a message is un-pretty, but it's less un-pretty
> than the two syntactical alternatives that have been put forward in
> this thread.

I'm not clear on what two syntactical alternatives you mean, since I
proposed two myself
http://www.ietf.org/mail-archive/web/marf/current/msg01403.html
http://www.ietf.org/mail-archive/web/marf/current/msg01418.html

My concept of un-pretty is having redundant data, as it brings
uncertainty on how to process it.  Thus, my first proposal was to drop
A-R from the second part.  John then proposed to have exactly one A-R
in the second part.  You then proposed to store the other data in
repeating groups of fields.  My second proposal then was to have
exactly one A-R field that includes one "resinfo" stanza for each
failed check, dropping the three method-specific multiple fields
defined in Section 3.2.2, since the values that they convey can be
stuffed in the relevant resinfo.  For example:

  Authentication-Results: authserv-id.example;
    dkim=fail
      header.d=DKIM-Domain-0.example
      header.i=[email-masked]
      header.s=DKIM-Selector-0.example;
    dkim=fail
      header.d=DKIM-Domain-1.example
      header.i=[email-masked]
      header.s=DKIM-Selector-1.example
      header.b=MAynEEdThis/asWeLL==;
    (...)

Except header.s, all that is already specified, especially the
grouping.  DKIM-Canonicalized-Header/Body don't need to be repeated,
and any DNS entry can be recognized by its query part.

What's wrong with this?

Rather than specifying those fields (DKIM-Domain, DKIM-Identity, and
DKIM-Selector) Section 3.2.2 can define header.s and recall the other
required tags for DKIM resinfos, while Section 3.1 can further
constrain how the second part's A-R should be composed, for example

  The "authserv-id" token of the Authentication-Results field in
  the second part SHOULD match the corresponding token of any
  Authentication-Results field in the third part that was added by
  the reporting verifier, and MUST NOT match the corresponding
  token of any Authentication-Results fields in the third part that
  had been added by some other verifiers.

(Ouch, this text is /really/ un-pretty...)

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 15 Oct 2011 11:30:56 -0400

> three messages to report multiple failures rather than one?

The one complication I can think of is that if there is the potential 
for getting multiple messages, there's no way to tell if you are going 
to get more.

I agree that correlating multiple reports about a single message into a 
single "meta-report" for local use would not be a problem.  The problem 
might be knowing when you had gotten all the reports you were going to 
get so you could do that processing.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 15 Oct 2011 17:12:06 -0000

>for getting multiple messages, there's no way to tell if you are going 

If that were really a problem (it's not clear to me why it would be),
it wouldn't be hard to invent a line like Group-Count: with a hint of
how many related reports were sent to the same target at about the
same time.

My impression is that you're more likely to want to correlate multiple
reports about similar failures to different messages rather than
different failures to one message.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 15 Oct 2011 14:52:36 -0400

>different failures to one message.

In my experience it's generally about trying to associate failure types and sources. Having information about multiple authentication types can be helpful in this.

Having all the facts about one message arrive together feels right from an system perspective. It's either arrived or not and there's no need to consider partial availability of data. OTOH, it may just be a minor corner case.

I suspect that all the information in one mail makes this RFC a bit more complicated, but it will make some types of implementations that make use of this data less complex and subject to race conditions.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 15 Oct 2011 20:09:20 -0700

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Saturday, October 15, 2011 5:46 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Maybe I'm just not understanding it, but this one doesn't seem to address the question we're discussing.

> http://www.ietf.org/mail-archive/web/marf/current/msg01418.html

This one does, but it doesn't take into consideration the canonicalized DKIM content fields, which might need to be repeated.

> and any DNS entry can be recognized by its query part.

You're right, we'd have to register "header.s" as something Authentication-Results can report.  But you're also right that this would be enough to indicate results for multiple signatures, since that's what "header.b" was added to do.

However, the canonicalized fields might need to be repeated, depending on whether different signatures use different canonicalizations or whether "l=" is in use.  That's the complicated part.

>   had been added by some other verifiers.

I'm not clear on why we'd need to say this.  Isn't the specification of the authserv-id already sufficiently clear, and it's obvious you'd need to use it properly and consistently for it to be meaningful?

Then again, if the recipient of this reports trusts who sent it, then the authserv-id doesn't really matter.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 16 Oct 2011 15:59:54 +0200

On 16/Oct/11 05:09, Murray S. Kucherawy wrote:
>> From: Alessandro Vesely
>  [...]
> However, the canonicalized fields might need to be repeated,
> depending on whether different signatures use different
> canonicalizations or whether "l=" is in use.  That's the
> complicated part.

Correct, I missed different canonicalizations.  Body canonicalizations
are not signature-specific and at most two of them are needed, thus we
can get away with something like

  DKIM-Canonicalized-Body: relaxed:
    BLAHBLAH....
  DKIM-Canonicalized-Body: simple:
    blahblah....

Tag l= doesn't play, unless we want to report hashes too.

Instead, header canonicalization depends on both the h= and c= tags.
Quoting the sig-h-tag is cumbersome, and makes it difficult for
recipients to find the canonicalization they are looking for.  A
possible solution may be to repeat the value of header.b, as a pointer
into the relevant signature

  DKIM-Canonicalized-Header: 12345678:
    BLAHblah....

If we don't need to optimize for reporting many signatures, we can use
the latter syntax also for the body, for the sake of uniformity.
Actually, we can as well use this syntax for any DKIM field.

> I'm not clear on why we'd need to say this.

Nor am I, honestly.  I just point out that some similar consideration
ought to be addressed.

> Isn't the specification of the authserv-id already sufficiently
> clear, and it's obvious you'd need to use it properly and
> consistently for it to be meaningful?

Yes, you're right, RFC 5451, Section 2.3 says

  The authentication identifier field provides a unique identifier
  that refers to the authenticating service within a given ADMD.  The
  uniqueness of the identifier MUST be guaranteed by the ADMD that
  generates it and must pertain to exactly that one ADMD.

But what are the relationships among authenticating service, verifier,
and reporter?

> Then again, if the recipient of this reports trusts who sent it,
> then the authserv-id doesn't really matter.

It's only use, AFAICS, is to relate the A-R in the second part with
one or more A-Rs in the reported message, which may be not obvious in
some edge cases.  While the generation of debugging reports --those
sporting DNS RRs-- has to be integrated within the verifier, reports
sent for policy tracking purposes can also be sent by agents further
down a message's path.  Policy methods, such as SPF, VBR, and ADSP,
are more plausible than DKIM for policy tracking purposes.  A
reporting agent of this kind probably relies on existing A-R fields,
part of which it copies to the second part's A-R.  However, it may or
may not wish to disclose the id(s) of those report-triggering A-R fields.

In that scenario, since RFC 5451's "authenticating service" may relate
to either the actual verifier or to a service that uses it, the
reporting agent is entitled to either reuse the authserv-id in the
message's A-R it relies on, or set its own unique id.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 18 Oct 2011 16:20:10 -0700

> Sent: Sunday, October 16, 2011 7:00 AM
> To: [email-masked]

That's not true; if "l=" is there in one signature and not in another, then those two will produce different canonicalized bodies, even if they use the same canonicalization.

> some edge cases.

Actually in the context of the report, I would trust the report's A-R and none of the quoted ones.  I know for certain where it originated.  And in that sense, the "authserv-id" doesn't really matter here.

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Oct 2011 13:07:25 +0200

On 19/Oct/11 01:20, Murray S. Kucherawy wrote:
> That's not true; if "l=" is there in one signature and not in
> another, then those two will produce different canonicalized
> bodies, even if they use the same canonicalization.

Not formally.  Section 3.4 of RFC 6376 specifies canonicalization with
no mention of l=.  OTOH, Section 3.7 says

 In hash step 1, the Signer/Verifier MUST hash the message body,
 canonicalized using the body canonicalization algorithm specified in
 the "c=" tag and /then/ truncated to the length specified in the "l="
 tag.  [emphasis added]

Does the definition of DKIM-Canonicalized-Body in Section 3.2.3 have
to specify that "the canonicalized body MAY be truncated to a length
greater or equal to the value of (the highest) l="?

>> [Authser-id]'s only use, AFAICS, is to relate the A-R in the second
>> part with one or more A-Rs in the reported message, which may be not
>> obvious in some edge cases.
> 
> Actually in the context of the report, I would trust the report's
> A-R and none of the quoted ones.  I know for certain where it
> originated.  And in that sense, the "authserv-id" doesn't really
> matter here.

I agree that it is sound to have the results of apposite checks in the
report's A-R.  That really depends on how the report's A-R is going to
be specified.  One possibility is to implement a meaning of "here's
why I'm sending this report".  Such semantics would exclude, for
example, spf=pass if the reported failure is a broken signature.
Indeed, that's not relevant for debugging, and for generic policy
tracking it might be as good to know as, say, Received: fields.

In any case, the contents of the report's A-R ought to be specified
and exemplified in the I-D, IMHO.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Oct 2011 06:56:31 -0700

> Sent: Wednesday, October 19, 2011 4:07 AM
> To: [email-masked]

I don't see how that emphasis is important.  The canonicalized form is truncated by whatever "l=" says, if it's present.  If two signatures use the same canonicalization and have the same "l=" value (or absence thereof), then the body canonicalization is the same.  In any other case, they're different.  For the common factoring you're after to work, you'd need a way to say "this canonicalized for applies to this set of signatures, but not the others".  That sounds like it could get horribly messy.

> and exemplified in the I-D, IMHO.

Isn't it safe to assume any negative result in the A-R portion is the reason for sending the report?  For example, if you give me one in this context that's "spf=pass dkim=fail", I'll know why you're sending it.

Maybe you can craft an example that shows what ambiguity you're trying to resolve?

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 19 Oct 2011 20:24:59 +0200

On 19/Oct/11 15:56, Murray S. Kucherawy wrote:
> 
> The canonicalized form is truncated by whatever "l=" says, if it's
> present.  If two signatures use the same canonicalization and have
> the same "l=" value (or absence thereof), then the body
> canonicalization is the same.  In any other case, they're
> different.  For the common factoring you're after to work, you'd
> need a way to say "this canonicalized for applies to this set of
> signatures, but not the others".  That sounds like it could get
> horribly messy.

DKIM-Canonicalized-Body is not required, but that is not the same as
saying that the first part of it suffices.  For example, if l=0 or the
body is empty, the spec says it should be canonicalized to a CRLF.

> Isn't it safe to assume any negative result in the A-R portion is
> the reason for sending the report?

Sure, but "negative" ought to be defined, and it should be comparable
with the ro= values defined by the relevant per-method specs (which
may change between report generation and reception.)

With multiple reports, can the Auth-Failure field help determining why
a report was generated?  It is important for people who need to fine
tune their ro=.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Oct 2011 11:37:43 -0700

> Sent: Wednesday, October 19, 2011 11:25 AM
> To: [email-masked]

If it's included, it has to be complete or it's not useful.  If "l=0" or the body is empty, DKIM-Canonicalized-Body (if included) must be the base64 encoding of a CRLF, because that's the canonicalized body in that instance.  Section 3.2.3 in the -03 draft talks about this.

The content of that field is the canonicalized form of the body specified per the signature that's being reported.  DKIM specifies how to do that; this document doesn't have to, other than to require the base64 encoding of it for transport.

> may change between report generation and reception.)

I suppose that can't hurt.  Something like this:

3.1:

   Authentication-Results:  MUST appear exactly once.  It MUST be formatted according to
      [AUTH-RESULTS], and MUST reflect only a single authentication failure.  To report
      multiple failures for a single message, multiple reports MUST be generated.

We could also include a note that says "failure" doesn't include stuff like temp-failures, but I don't think that's really necessary.

> a report was generated?  It is important for people who need to fine

Indeed, Auth-Failure is the only way to know why the report was generated, as far as I can tell.

We can't reference the other drafts from this one as it'll be published first, unless there's some reason that they all need to go out together.

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 20 Oct 2011 17:44:22 +0200

On 19/Oct/11 20:37, Murray S. Kucherawy wrote:
> If it's included, it has to be complete or it's not useful.  If
> "l=0" or the body is empty, DKIM-Canonicalized-Body (if included)
> must be the base64 encoding of a CRLF, because that's the
> canonicalized body in that instance.

All right, I think the amount of guesswork is minimal (e.g. what if
l=1?) and the recipient should be prepared to "massage" the datum
anyway, according to what format was saved on signing, for comparison.

> We could also include a note that says "failure" doesn't include
> stuff like temp-failures, but I don't think that's really
> necessary.

However, SPF reporting (sect 4.1) has the following for ro=

  e  Reports are requested for messages that produced an SPF result of
     "TempError" or "PermError.

> generated, as far as I can tell.

Yes, if "Auth-Failure: spf" and "spf=temperror" in A-R, then the
recipient knows it was ro= in their SPF record to trigger the report.

Constraining A-R further would only make sense if we wanted to avoid
multiple reports.

> We can't reference the other drafts from this one as it'll be
> published first, unless there's some reason that they all need to
> go out together.

There is also no reason why the drafts should be published
independently, since defining further failure types, e.g. VBR, will
need to redefine stuff in authfailure-report anyway.  IMHO, we should
feel free to reference the drafts from one another if that improves
clarity.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 20 Oct 2011 11:16:55 -0700

> Sent: Thursday, October 20, 2011 8:44 AM
> To: [email-masked]

So you're saying DKIM-Canonicalized-Body should always be the complete body, and receivers of these reports should apply the truncation based on the "l=" found in the third MIME part?  That seems a little convoluted to me.

> feel free to reference the drafts from one another if that improves

I disagree.  This format is completely useful even if none of the reporting extensions drafts ever get published.  The opposite is not true.  That was one of the advantages of breaking the omnibus draft into these four or five smaller pieces.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 21 Oct 2011 13:40:11 +0200

On 20/Oct/11 20:16, Murray S. Kucherawy wrote:
> So you're saying DKIM-Canonicalized-Body should always be the
> complete body, and receivers of these reports should apply the
> truncation based on the "l=" found in the third MIME part?  That
> seems a little convoluted to me.

However convoluted it may seem, that's the formal definition that DKIM
gives of the body canonicalization algorithms.  Of course, both
signers and verifiers know it is useless to canonicalize parts of the
body that don't contribute to the hash.  By skipping useless parts,
they obtain the same result "as if" they had carried out a full body
canonicalization and then truncation.

Report generators are in a different position, because what used to be
an intermediate result is now visible.  Pedantic programmers may
conclude that they need to send the whole body by reasoning as I did
above (uh... does that mean I'm pedantic?)  You yourself adapted to
write CRLF for an empty body, l=0 notwithstanding.

What I'm saying is that if we want it to be clear and indisputable
that DKIM-Canonicalized-Body may/must be limited to the amount of text
that contributes to the hash, we have to say so.

> This format is completely useful even if none of the reporting
> extensions drafts ever get published.  The opposite is not true.

Admitted.  That may be an advantage, even though it comes at the
expenses of method-orientation.

---

From: "Hilda Fontana" <[email-masked]>
Date: Fri, 21 Oct 2011 08:09:56 -0700

All,

I'd really like to get a final consensus of the changes for the next draft.
So far I have the minor changes, including the updates needed to the
example.  

Is it fair to say we have consensus on the one report per failure?  

What is the final verdict on the DKIM-Canonicalized-Body?  How should it be
phrased in the doc?

Thanks
H

> Alessandro Vesely
> Sent: Friday, October 21, 2011 4:40 AM
> To: [email-masked]
> > So you're saying DKIM-Canonicalized-Body should always be the complete
> > body, and receivers of these reports should apply the truncation based
> > on the "l=" found in the third MIME part?  That seems a little
> > convoluted to me.
> 
> gives of the body canonicalization algorithms.  Of course, both signers
and
> verifiers know it is useless to canonicalize parts of the body that don't
> contribute to the hash.  By skipping useless parts, they obtain the same
> result "as if" they had carried out a full body canonicalization and then
> truncation.
> 
> Report generators are in a different position, because what used to be an
> intermediate result is now visible.  Pedantic programmers may conclude
that
> they need to send the whole body by reasoning as I did above (uh... does
> that mean I'm pedantic?)  You yourself adapted to write CRLF for an empty
> body, l=0 notwithstanding.
> 
> What I'm saying is that if we want it to be clear and indisputable that
DKIM-
> Canonicalized-Body may/must be limited to the amount of text that
> contributes to the hash, we have to say so.
> 
> Admitted.  That may be an advantage, even though it comes at the expenses
> of method-orientation.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 21 Oct 2011 12:30:54 -0700

> canonicalization and then truncation.

I agree that you can do it either way; the hash is the same through either method.  However, determining the "l=" (truncation point) for hash computation by diving into the third MIME part of the report is probably not a good design.  To mitigate this, we either specify that DKIM-Canonicalized-Body is truncated per "l=", or we have to add a DKIM-Canonicalized-Length field to tell the report recipient where to truncate the canonicalized body when using the result (or both, though that's redundant).  I'd be fine with either.

> write CRLF for an empty body, l=0 notwithstanding.

The implementation I have holds the canonicalized header and body in their entirety, but the latter is truncated per "l=" if present.  It handles "l=0" and the empty body per the RFC.

> that contributes to the hash, we have to say so.

I'm fine with that; I think it's simpler, and it's extremely convenient for my implementation.  :-)

So I suggest the DKIM-Canonicalized-Body description be amended like so:

   DKIM-Canonicalized-Body:  A base64 encoding of the canonicalized body
      of the message as generated by the verifier.  The encoded content
      MUST be limited to those bytes that contribute to the DKIM body
      hash (i.e., the value of the "l=" tag; see Section 3.7 of [DKIM]).

Does that work for you?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 21 Oct 2011 12:32:52 -0700

> Sent: Friday, October 21, 2011 8:10 AM
> To: 'Alessandro Vesely'; [email-masked]

I believe there's rough consensus supporting one report per failure.

> What is the final verdict on the DKIM-Canonicalized-Body?  How should it be

I just proposed a replacement description.  If there are no objections, we can run with it.

I'll start a second WGLC on your -04 when I see it, but please wait a few days in case anyone else wants to chime in on either issue.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 22 Oct 2011 13:52:36 +0200

> So far I have the minor changes, including the updates needed to the

Is it ok for the example to start at the first column?  Usually lines
start with three spaces...

> Is it fair to say we have consensus on the one report per failure?  

There are different cases, e.g:

*straight case*
The sending domain signs twice, e.g. to experiment different
parameters, but it uses the same selector.  Hence the r= address is
the same for both failures.  If both signatures fail, the report
generator can tell how many messages it is going to send.

*possibly unrelated*
The sending domain defines SPF, DKIM, and ADSP.  If some of them fail,
the report generator would have to compare the relevant email
addresses in order to tell if reports are destined to the same operator.

*modular case*
The receiving domain performs multiple checks, but they are all
handled by different software modules, and thus result in multiple A-R
fields.  Possibly, generators should be configured to send reports to
an internal mailbox where they are reassembled, modified, or counted.

Such report-tweaking internal mailbox can also be used for setting
fields like Delivery-Result.  For example, the MX server that carries
out the checks can be configured to send the reports to the MDA that
decides about delivery; the MDA then forwards the report to the final
destination, which is still written in the included DNS records.

> What is the final verdict on the DKIM-Canonicalized-Body?  How should it be

I'm happy with the text Murray proposed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 22 Oct 2011 08:27:50 -0700

> Sent: Saturday, October 22, 2011 4:53 AM
> To: [email-masked]

Yes, the examples should be indented slightly inside the <figure> and <artwork> tags.

> There are different cases, e.g:

I'm not really sure what you're going after here.  Do you have specific text changes you want to propose?

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 22 Oct 2011 19:57:43 +0200

On 22/Oct/11 17:27, Murray S. Kucherawy wrote:
> I'm not really sure what you're going after here.  Do you have
> specific text changes you want to propose?

I don't.  We only discussed reporting multiple broken signatures, and
apparently concluded that it is too much of a complication for a case
that ordinarily does not happen.  (Some domains sometimes sign twice;
you may want to run something like this to find out:

  SELECT d.name, s1.domain, count(*)
  FROM signatures AS s1, signatures AS s2, domains AS d
  WHERE s1.message = s2.message
    AND s1.domain = s2.domain
    AND s1.id != s2.id
    AND d.id = s1.domain
  GROUP BY s1.domain;
)

However, having two separate reports for a DKIM failure and the
consequent ADSP failure, provided the r='s match, looks overly
verbose.  What do we want to do in such cases?

In addition, forwarding from a central host may be a technique worth
being mentioned, although it's quite expensive compared to syslog.  It
may be used for vetting and internal auditing, besides updating
delivery-results, reckoning ri=, and the like.  Worth?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 22 Oct 2011 14:43:39 -0700

> Sent: Saturday, October 22, 2011 10:58 AM
> To: [email-masked]

I have no doubt that there are some domains that sign twice, either on purpose or accidentally.  The DKIM RFC even contains allusions to the practice.  But I don't see how that leads to changes to the text we have now.

> verbose.  What do we want to do in such cases?

Send three reports.  Consensus appears to be that this is easier than coming up with some crazy syntax to try to keep it all contained in one report, especially when these are meant to be machine-processed and not handled by humans; it's not much of a burden.

> delivery-results, reckoning ri=, and the like.  Worth?

We haven't prevented that kind of design with the text that's there now, so I don't think any changes are needed there either.  It would be an odd thing to do, but the current text doesn't block it.

I think we're ready for another WGLC, unless you have other cases you'd like to explore.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 23 Oct 2011 16:27:46 +0200

On 22/Oct/11 23:43, Murray S. Kucherawy wrote:
> 
> Send three reports.  Consensus appears to be that this is easier
> than coming up with some crazy syntax to try to keep it all
> contained in one report, especially when these are meant to be
> machine-processed and not handled by humans; it's not much of a
> burden.

Agreed, even though some cases don't need a different syntax.

> We haven't prevented that kind of design with the text that's there
> now, so I don't think any changes are needed there either.  It
> would be an odd thing to do, but the current text doesn't block
> it.

Perhaps it looks odd because I conflated a number of things.  Let's
postpone delivery-results, reassembling, and ri=.  Would it be helpful
to have some text like the following appended to Section 7.3?

  Alternatively, report generators can accept a configuration
  parameter that instructs them to generate reports only in certain
  cases and/or to send them to a mailbox different than the one
  discovered in the DNS.  The latter is supposedly an internal
  mailbox whose operator, either human or automatic, can examine what
  data is being sent to whom before allowing or denying the report to
  proceed.  The destination address discovered in the DNS is still
  available in the relevant header field saved in the second MIME
  part of the report, thus forwarding-after-vetting can be
  automatically assisted.

> I think we're ready for another WGLC, unless you have other cases

I'm looking forward to -04.