Subject: [marf] comments on draft-ietf-marf-authfailure-report-06

From: "John R Levine" <[email-masked]>
Date: 13 Dec 2011 22:37:15 -0500

I see there's a new version of authfailure-report.  Overall it's getting 
there, but it still has some severe confusion about RFC 2119 language. In 
2119-ese, MUST means that if you don't do that, it won't interoperate at 
all so don't even try.

In section 3.1 of the draft:

    Authentication-Results:  Syntax as specified in [ARF].  Furthermore,
       [ARF] specifies this field is OPTIONAL and appears at most once;
       for this extension, this field MUST be present if that value is
       available.  It MUST be formatted according to [AUTH-RESULTS], and
       MUST reflect only a single email authentication method failure.

The ARF RFC doesn't define Authentication-results, RFC 5451 does.

I don't understand what "MUST be present if that value is available" 
means.

Referring to 2119, it would mean that if you have cruddy software that 
doesn't record the auth results so the value isn't available, it's OK to 
send a report without it, but if do you have it available but don't want 
to send it, you can't send a report at all, which is silly.  I understand 
that some people really really REALLY want their reports to be unredacted, 
but as we discussed a month or two ago, reporters will send what they're 
willing to send and no more, regardless of what an RFC says.  In fact, an 
auth failure report without this info is often entirely usable, so just 
delete this paragraph.

       To report multiple failures for a single message, multiple reports
       MUST be generated.

That sentence says that if you have multiple failures you have to report 
all of them, or else don't report anything.  Move it to just above 
section 3.1 and change it to:

       A single report describes a single authentication failure.
       Multiple reports MAY be used to report multiple failures for a
       single message.

Then there are several sections like this one with the same MUST 
language:

    Original-Envelope-Id:  Syntax as specified in [ARF].  Furthermore,
       [ARF] specifies this field is OPTIONAL and appears at most once;
       for this extension, this field MUST be present if that value is
       available.

The next three similar paragraphs cover Original-Mail-From, Source-IP, and 
Reported-Domain.  Same problem, same solution, delete all four of them. 
I suppose you could say something like it is RECOMMENDED to include these 
items to help better diagnose the authentication failure.

In Section 4, the ABNF, the definition of auth-failure both says that a 
token is one of a list of types and that it's imported from [MIME]. 
Importing seems wrong since that suggests it can be any tokenish string, 
but there's nothing that says that unknown auth-failure types are ignored. 
Suggest removing the references to token and instead enumerate the failure 
types, similar to the list of delivery results just below it.

dkim-selector is also defined as a token, but actually it's a sub-domain.
Import it from [DKIM].

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Dec 2011 21:45:50 -0800

For the sake of expediency, I'm helping Hilda with some of these edits.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R Levine
> Sent: Tuesday, December 13, 2011 7:37 PM
> To: ARF mailing list
> Subject: [marf] comments on draft-ietf-marf-authfailure-report-06
> 
> I see there's a new version of authfailure-report.  Overall it's
> getting there, but it still has some severe confusion about RFC 2119
> language. In 2119-ese, MUST means that if you don't do that, it won't
> interoperate at all so don't even try.
> 

I imagine it's copied from the others.  The point there is that for SPF (for example), the client IP is needed to paint the whole picture, but for a DKIM report it isn't, and in either case it may not be available.  Same for the other parameters; different filtering points in the handling chain have access to different subsets of them.

> doesn't record the auth results so the value isn't available, it's OK
> to send a report without it, but if do you have it available but don't
> want to send it, you can't send a report at all, which is silly.  I
> understand that some people really really REALLY want their reports to
> be unredacted, but as we discussed a month or two ago, reporters will
> send what they're willing to send and no more, regardless of what an
> RFC says.  In fact, an auth failure report without this info is often
> entirely usable, so just delete this paragraph.

Do you really mean "delete this paragraph"?  Because we do want the field to be there.  RFC5451 gives a standard way to report this result, so it makes sense to either require that it be there, or don't send a report at all.

What about:

"Syntax as specified in <xref target="AUTH-RESULTS"/>.  Furthermore, <xref target="ARF"/> specifies this field is OPTIONAL and appears at most once; for this extension, this field MUST be present, but MUST reflect only a
single authentication method's result."

> That sentence says that if you have multiple failures you have to
> report all of them, or else don't report anything.  Move it to just
> above section 3.1 and change it to:
> 

That works.

> The next three similar paragraphs cover Original-Mail-From, Source-IP,
> and Reported-Domain.  Same problem, same solution, delete all four of them.
> I suppose you could say something like it is RECOMMENDED to include
> these items to help better diagnose the authentication failure.

I'd prefer that last approach.  I didn't like the MUST either, but I appeared to be in the minority.

> Importing seems wrong since that suggests it can be any tokenish
> string, but there's nothing that says that unknown auth-failure types
> are ignored.
> Suggest removing the references to token and instead enumerate the
> failure types, similar to the list of delivery results just below it.

That works.

> dkim-selector is also defined as a token, but actually it's a sub-

Actually it's even easier to just import "selector" from [DKIM].

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Dec 2011 13:55:03 +0100

On 14/Dec/11 06:45, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of John R Levine
> 
> [...]  RFC5451 gives a standard way to report this result, so it
> makes sense to either require that it be there, or don't send a
> report at all.
> 
> What about:
> 
> "Syntax as specified in <xref target="AUTH-RESULTS"/>.
> Furthermore, <xref target="ARF"/> specifies this field is OPTIONAL
> and appears at most once; for this extension, this field MUST be
> present, but MUST reflect only a single authentication method's
> result."

+1, let me try to further improve that:

 <t hangText="Authentication-Results:">
  The syntax is as specified in <xref target="AUTH-RESULTS"/>.
  While <xref target="ARF"/> specifies this field is OPTIONAL
  and appears at most once, for this extension this field MUST be
  present: it MUST reflect the single email authentication method
  failure that is being reported, and only that.
 </t>

>> Move [the rest of the paragraph] to just above section 3.1 and
>> change it to:
>> 
>>    Multiple reports MAY be used to report multiple failures for
>>    a single message.
> 
> That works.

+1, but that way we loose the correlation with the A-R field.  In
addition, the document structure is not clear-cut.

Section 3.1 has a title of *New ARF Feedback Type* while it is
actually redefining header fields.  Indeed, its anchor is "arf-fields".

The first two-liner paragraph is the only justification for the
section's title.  It says "See Section 3.3 for details", which is
probably a typo as that reference is deceptive here --Section 3.3
defines the possible values of the new header field Auth-Failure,
whose name spells the same as the new value of Feedback-Type being
thus introduced.

I'd propose to slightly reorganize Section 3 like so:

* Change the title of current Section 3 (anchor="arf-extend") to
  something like "Definition of the Extension", i.e. not just the
  fields.

* Move the last subsection of Section 2 as the first one here,
  changing its title and wording, e.g. as follows:

   <section anchor="technologies" title="Semantics">
    <t>There are technologies in email security that provide
       authentication services and some that do authorization.
       These are often conflated.  A discussion of this that
       is useful for establishing context can be found in Section
       1.5.2 in <xref target="AUTH-RESULTS"/>.</t>

    <t>The failures that can be reported using this extension
       correspond to <xref target="AUTH-RESULTS"/>' methods appearing
       in the "Email Authentication Methods" IANA registry, or parts
       thereof.</t>

    <t>A single report describes a single authentication failure.
       Multiple reports MAY be used to report multiple failures for
       a single message.</t>
   </section>

* Change the title of the current Section 3.1 (anchor="arf-fields",
  which would be renumbered to 3.2) to something like "Modified Header
  Fields".

* Insert a new bullet for the type, e.g.

   <t hangText="Feedback-Type:"> Reports formatted according to this
    extension MUST have the new type "auth-failure".</t>

Please remove the last bullet from that list, Delivery-Result.  There
is already a paragraph devoted to it in the current Section 3.2.2
(anchor="arf-headers-2"), where it belongs.

For the other bullets, IMHO it makes more sense to specify precisely
what value for what method should be reported in which header field,
than trying to change their 2119 status.  In case we wish to defer
precise specifications to method-specific RFCs, we should defer to
them any related 2119 considerations as well.

Reported-URI is never mentioned in the document, except in the
example.  Please remove it from there too.

Lastly, in the *IANA Considerations* section the names are not exact:

In Section 5.1, s/Feedback Report Feedback Type Registry/"Feedback
Report Type Values" registry/ and s/Feedback Type:/Feedback Type Name:/.

In Section 5.2, s/Feedback Report Header Names Registry/"Feedback
Report Header Fields" registry/.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 10:55:56 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, December 14, 2011 4:55 AM
> To: [email-masked]
> Subject: Re: [marf] comments on draft-ietf-marf-authfailure-report-06
>
> [Section 2 and Section 3 stuff]

Thanks for your suggestions.  However, I think the layout of the sections whose revisions you proposed are sufficient as-is.  After two working group last calls and too many revisions, I think we're long past the point where we should be worried about arrangement of the material unless it's actually seriously wrong.

> Reported-URI is never mentioned in the document, except in the example.
> Please remove it from there too.

I disagree that this is necessary.  We're not saying other ARF fields aren't allowed here, are we?  If they're allowed in ARF, they're allowed here (unless we've explicitly said otherwise, and we haven't).

> Report Header Fields" registry/.

Quite right; fixed both.

If there's nothing else, I plan to get Hilda to post -07 soon and I'll have it over to the IESG shortly thereafter.  We should turn our editing energy to the remaining documents.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 14 Dec 2011 20:31:12 +0100

On 14/Dec/11 19:55, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>>
> Thanks for your suggestions.  However, I think the layout of the
> sections whose revisions you proposed are sufficient as-is.  After
> two working group last calls and too many revisions, I think we're
> long past the point where we should be worried about arrangement of
> the material unless it's actually seriously wrong.

The proposed layout change is minimal, in spite of my lengthy
description of it.  As it retains the role of A-R fields, the result
is more semantically similar to -06 than accomplishing John's move
otherwise --unless you have a better solution, of course.  However,
Section 3.1's title and its reference to Section 3.3 /are/ seriously
wrong.

> I disagree that this is necessary.  We're not saying other ARF
> fields aren't allowed here, are we?

By omitting to exemplify them we don't imply they are not allowed.

ARF mentions "a suspect URI that was found in the message that caused
the report to be generated", not a synthesized URI, e.g. obtained by
prepending "http://www." to a random domain-like string :-/

> If they're allowed in ARF, they're allowed here (unless we've
> explicitly said otherwise, and we haven't).

Agreed.  But if we are unable to imagine any plausible value for that
field, we'd better not to mention it at all, IMHO.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Dec 2011 11:56:48 -0800

> Sent: Wednesday, December 14, 2011 11:31 AM
> To: [email-masked]
> description of it.  As it retains the role of A-R fields, the result is
> more semantically similar to -06 than accomplishing John's move

The creation of this new ARF type comprises a bunch of extension fields and their definitions, and little else.  Therefore, "Extension ARF Fields for Authentication Failure Reporting" seems perfectly good.  Similarly, the document recognizes five specific types of authentication failures about which reports can be generated, and thus the title "Authentication Failure Types" seems a perfectly good title for a section in which to enumerate them.

I fail to see how either of these are wrong at all, let alone seriously.

My solution is to use John's suggestion and make no other changes, absent any consensus that pushes for what you're suggesting.  Otherwise, we can die nitting on this minor stuff and never get it out the door.

> prepending "http://www." to a random domain-like string :-/

The third part of the report only contains the header of the message causing the report to be generated, which RFC5965 allows.  Presumably, then, the reported URI came from someplace in the body of the message, which isn't shown here (and doesn't need to be, by ARF's definitions).

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 15 Dec 2011 20:05:24 +0100

On 14/Dec/11 20:56, Murray S. Kucherawy wrote:
> The creation of this new ARF type comprises a bunch of extension
> fields and their definitions, and little else.  Therefore,
> "Extension ARF Fields for Authentication Failure Reporting" seems
> perfectly good.

The last two paragraphs of Section 3.1 are not related to any specific
field.  In addition, since you agreed to move the sentences that
describe the failure-to-report relationship "to just above section
3.1" --thereby decoupling them from the A-R field-- Section 3 will
host one more statement which is about the overall semantics rather
than any specific field.  That title is at least misleading.

> Similarly, the document recognizes five specific types of
> authentication failures about which reports can be generated, and
> thus the title "Authentication Failure Types" seems a perfectly
> good title for a section in which to enumerate them.

Yes it is.  I meant the second sentence in the first paragraph of
Section 3.1:

   A new feedback type of "auth-failure" is defined as an extension to
   Section 8.2 of [ARF].  See Section 3.3 for details.

> I fail to see how either of these are wrong at all, let alone seriously.

That quoted paragraph says that the details of "auth-failure" consist
of the possible values of Auth-Failure.  Isn't it wrong?

BTW, Section 8.2 of [ARF] is about the *Interpretation* of the report
format.  You probably mean Section 7.3 (but shouldn't such reference
belong to the IANA Considerations section?)

After those two lines, the section continues with several fields
specifications.  Not all fields, just some.  A reader may wander why
Delivery-Result is listed here while Auth-Failure itself is not.  A
title of "New ARF Feedback Type" doesn't help.

BTW, the specification of Delivery-Result is in Section 3.2.2, not 3.2.1.

> My solution is to use John's suggestion and make no other changes,
> absent any consensus that pushes for what you're suggesting.
> Otherwise, we can die nitting on this minor stuff and never get it
> out the door.

My purpose is not to delay the publication.  I'm replying because I
think you misunderstood what I said.  If I had been nitting, I would
have contested the entanglement of defining a field in Section 3.2.1
postponing the discussion of its content to Section 3.3, while it
would have made for easier reading (and writing) to have that field
defined and discussed in a single place.

> The third part of the report only contains the header of the
> message causing the report to be generated, which RFC5965 allows.
> Presumably, then, the reported URI came from someplace in the body
> of the message, which isn't shown here (and doesn't need to be, by
> ARF's definitions).

For that to hold, you may want to add l=53 to the DKIM-Signature, or
replace the following field

DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9ke
 SB0aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIH
 NhbWUgdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJ
 pZnksIHRoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVz
 aXZlIG9mIHBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoa
 W50cy4gIEluZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdG
 hlIGZvbGxvd2luZyB0ZXh0CgogICBQbGVhc2UgZW50ZXIgeW91ciB
 mdWxsIGJhbmsgY3JlZGVudGlhbHMgYXQKICAgaHR0cDovL3d3dy5z
 ZW5kZXIuZXhhbXBsZS8KCldlIGFyZSBpbXBseWluZyB0aGF0LCBhb
 HRob3VnaCBtdWx0aXBsZSBmYWlsdXJlcwpyZXF1aXJlIG11bHRpcG
 xlIHJlcG9ydHMsIGEgc2luZ2xlIGZhaWx1cmUgY2FuIGJlCnJlcG9
 ydGVkIGFsb25nIHdpdGggcGhpc2hpbmcgaW4gYSBzaW5nbGUgcmVw
 b3J0Lgo=

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Dec 2011 14:06:59 -0800

> Sent: Thursday, December 15, 2011 11:05 AM
> To: [email-masked]
> field.

The section is entitled "New ARF Feedback Type", and those last two paragraphs are discussing the report type and its structure.  Seems legitimate to me.

> In addition, since you agreed to move the sentences that
> describe the failure-to-report relationship "to just above section 3.1"
> --thereby decoupling them from the A-R field-- Section 3 will host one
> more statement which is about the overall semantics rather than any
> specific field.  That title is at least misleading.

We aren't defining a whole new report format here.  We're defining a new report type that has a few new fields but otherwise has the same format as any other ARF message.  And the new report type itself is referenced in an existing field.  It's all about fields.

But if it will get us to publication, how about calling it "ARF Extension for Authentication Failure Reporting"?

> > authentication failures about which reports can be generated, and thus
> > the title "Authentication Failure Types" seems a perfectly good title
> > for a section in which to enumerate them.
> 

We can just remove the reference then.

> belong to the IANA Considerations section?)

Yes, "per Section 7.3" is probably more precise.

> title of "New ARF Feedback Type" doesn't help.

I don't agree.  Section 3.1 defines the new feedback type and augments [ARF]'s field requirements.  The latter is part of the former.

> BTW, the specification of Delivery-Result is in Section 3.2.2, not

Right, fixed.

> > The third part of the report only contains the header of the message
> > causing the report to be generated, which RFC5965 allows.
> > Presumably, then, the reported URI came from someplace in the body of
> > the message, which isn't shown here (and doesn't need to be, by ARF's
> > definitions).
> 
> [...]

I updated it (had some typos), and replaced it in -07.  Thanks.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 16 Dec 2011 11:50:12 +0100

On 15/Dec/11 23:06, Murray S. Kucherawy wrote:
> 
> We aren't defining a whole new report format here.  We're defining
> a new report type that has a few new fields but otherwise has the
> same format as any other ARF message.  And the new report type
> itself is referenced in an existing field.  It's all about fields.
> 
> But if it will get us to publication, how about calling it "ARF
> Extension for Authentication Failure Reporting"?

Sounds great!  Indeed, as a new type it will have its own semantics,
usage, and FBL-setup criteria, albeit we don't want/merit to specify them.