Subject: [marf] APPSDIR review of draft-ietf-marf-authfailure-report-05

From: S Moonesamy <[email-masked]>
Date: Fri, 02 Dec 2011 11:02:30 -0800

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on appsdir, please 
see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
).  The review is not being copied to the IESG as a Last Call has not 
been issued.

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-marf-authfailure-report-05
Title: Authentication Failure Reporting using the Abuse Report Format
Reviewer: S. Moonesamy
Review Date: December 2, 2011

Summary:

This draft is almost ready for publication as a Proposed Standard.

Major issues:

None.

Minor Issues:

In the Abstract Section:

   "This memo registers an extension report type to ARF for use in
    reporting messages that fail one or more authentication checks"

In the Introduction Section:

   "There is now also a desire to extend the ARF format to include
    reporting of messages that fail to authenticate using known
    authentication methods"

   "Thus, this memo presents such extensions to the Abuse
    Reporting Format to allow for detailed reporting of message
    authentication failures."

In Section 3:

   "The current report format defined in [ARF] lacks some specific
    features required to do effective sender authentication reporting."

The use of "authentication" is not consistent throughout the text 
quoted above.  This drafts builds upon RFC 5451 in which DKIM and SPF 
are referred to as email authentication methods.  I suggest using the 
term "email authentication method" for consistency.

The wording "presents such extensions" in the Introduction Section is 
not clear.  Section 3.1 of the draft defines a new feedback type of 
"auth-failure" as an extension to RFC 5965.  Is there more than one 
extension?  This memo should update RFC 5965.

In Section 3.1:

   "Original-Envelope-Id:  As specified in [ARF].  This field SHOULD be
    included exactly once if available to the entity generating the
    report."

RFC 5965 defines the field as optional and MUST NOT appear more than 
once".  The above is a rewording of a requirement level.  I suggest 
rewriting the last sentence to remove the key word:

   As specified in [ARF].  This field is included only once if available to the
   entity generating the report.

  "Original-Mail-From:"

Please see the comment above about "Original-Envelope-Id".

  "Source-IP:  As specified in [ARF].  This field SHOULD be included
     exactly once for SPF, or for other methods that evaluate
     authentication during the SMTP phase."

Please see the comment above about "Original-Envelope-Id".  Why is 
there a "SHOULD" for SPF?

   "Reported-Domain:  As specified in [ARF].  This field MUST appear at
      least once."

Is it the format which is being imported from RFC 5965 or is it also 
what is specified for the field?

   'The third MIME part of the message is either of type "message/rfc822"
    (as defined in [MIME-TYPES]) or "text/rfc822-headers" (as defined in
    [REPORT]) and contains a copy of the entire header block from the
    original message.  This part MUST be included (contrary to [REPORT]).'

I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04 
instead of RFC 3462 and removing the "(contrary to [REPORT])".

In Section 3.2.1:

   "Auth-Failure:  Indicates the type of authentication failure that is
      being reported.  The list of valid values is enumerated in
      Section 3.3."

What is being reported is the failure from an email authentication 
method and not an "authentication failure".

In Section 3.2.2:

   "policy:  The message was not delivered to the intended inbox due
      to authentication failure."

Please refer to my comment about the usage of "authentication failure".

Nits:

In Section 3.2.4:

   '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].'

I suggest replacing the word "bytes" with "octets" (RFC 6376).

   "If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body encode
    redacted data, they MUST NOT be included.  Otherwise, they SHOULD be
    included.  The data presented there have to be exactly the
    canonicalized header and body as defined by [DKIM] and computed at
    the verifier.  This is because these fields are intended to aid in
    identifying message alterations that invalidate DKIM signatures in
    transit.  Including redacted data in them renders the data unusable.
   (See also Section 5 and Section 7.6 for further discussion.)"

It is better to restate the above as "SHOULD be included" and mention 
that it is not applicable if the date has been modified.  If the 
working group wants to mention "redacted data", it can include an 
informative reference to draft-ietf-marf-redaction-03.

Section 5 is the IANA Considerations Section.  The draft does not 
contain a Section 7.6.

In Section 3.2.5:

   "DKIM-ADSP-DNS: Includes the ADSP record discovered and applied by the
      entity generating this report"

I suggest:

   DKIM-ADSP-DNS It is the ADSP record used to obtain the ADSP result.

I did not include a "MUST" as there is already one in Section 3.3 (adsp).

In Section 3.3:

   "The list of defined authentication failure types"

Please refer to my previous comments about the usage of 
"authentication failure".

   "Supplementary data MAY be included in the form of [MAIL]-compliant
    comments."

Why is there a "MAY"?

There should be a normative reference to RFC 5234 given the ABNF in Section 4.

In Section 6.2:

   "Perhaps the simplest means of mitigating this threat is to assert
    that these reports should themselves be signed with something like
    DKIM."

I suggest removing the "something like".

 From the example in Appendix B.1:

  "Received: from mail.example.com (mail.example.com [192.0.2.1])
     by mx.example.net (8.14.4/8.14.4) with ESMTP id c6cs67945pbm;
     Sat, 8 Oct 2011 13:16:24 +0000 (GMT)
   Return-Path: [email-masked]"

Isn't the Return-Path: mail header inserted before the Received: mail headers?

  "For more information about this format please see
    http://datatracker.ietf.org/doc/draft-ietf-marf-authfailure-report"

I suggest adding a comment for the RFC Editor to reference "this RFC".

  "Policy-Action: none"

That field has not been defined.  I suggest that the working group 
reviews the example for correctness.

Regards,
S. Moonesamy

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 02 Dec 2011 15:36:39 -0500

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

>rewriting the last sentence to remove the key word:

Why? The sense of the text is that it should not be omitted if the
data are available. Thr part about only once is secondary and is
alread implied. How about

   "Original-Envelope-Id:  As specified in [ARF].  This field SHOULD
be
    included if available to the entity generating the report."

INHO it is appropriate to echo the restriction in [ARF], but that's
less important.

>I suggest having a reference to draft-ietf-appsawg-rfc3462bis-04

Is that legitimate in a Standards Track RFC?

>I suggest removing the "something like".

What is the justification for precluding other types of digital
signatures? Wouldn't it be better to remain agnostic?

-- 
     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: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Dec 2011 12:37:00 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Friday, December 02, 2011 12:37 PM
> To: [email-masked]
> Subject: Re: [marf] APPSDIR review of draft-ietf-marf-authfailure-
> report-05
> 

Yes, it was approved for publication yesterday.  It will have an actual RFC number long before this one gets that far.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Dec 2011 12:39:28 -0800

Hi SM, thanks for the review.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Friday, December 02, 2011 11:03 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05
> 

Whew!

> term "email authentication method" for consistency.

Agreed.

There will probably be a few people concerned about the "authentication vs. authorization" matter, but I think RFC5451 dealt with this reasonably well, and the field in general has come to be known as "email authentication".  But you're right that "sender" is misleading in terms of roles, especially in the case of DKIM.  This draft has been around for a while and I guess this text hasn't matured as fast as its brethren.

If it would help, we could add a reference to RFC5451 Section 1.5.2, which talks about the differences and their effective union in this area.

> extension?  This memo should update RFC 5965.

I suppose it's worded that way because we created a new report type but had to make a number of changes to IANA registries to do so, hence the plural.  But it really is one omnibus extension action.  I don't have a preference as to wording; if the plural is confusing, we can change it.

>    entity generating the report.

The point of saying this is that RFC5965 allows for the absence or presence of the field, but proscribes multiple instances of it.  We want to say, for this report type, that Original-Envelope-ID should be there, further limiting the "absence" case.

Perhaps changing the SHOULD to a MUST above is better?

> Please see the comment above about "Original-Envelope-Id".

Ditto for me too.

> Please see the comment above about "Original-Envelope-Id".

Ditto for me too.

> Why is there a "SHOULD" for SPF?

The Source-IP is a key piece of information for reconstructing why an SPF evaluation failed.  It needs to be there if it's available, or the failure report is basically incomplete.

> what is specified for the field?

It is the same, except that RFC5965 makes it entirely optional.  For this report type, we want to see it at least once.

> instead of RFC 3462 and removing the "(contrary to [REPORT])".

I agree with the reference change, however the "contrary" part is correct because [REPORT] says the third MIME part in a report is optional, while for this specific instance of it, we want it to be there.  If it would help for illustration, we could say "(contrary to [REPORT], which makes it optional)".

> method and not an "authentication failure".

Fair enough.

> Please refer to my comment about the usage of "authentication failure".

Yes.

> I suggest replacing the word "bytes" with "octets" (RFC 6376).

OK.

> informative reference to draft-ietf-marf-redaction-03.

We actually had it the other way (as you suggest), and then changed it to this because we thought this description was more effective, i.e., having the strongest requirement first.

> Section 5 is the IANA Considerations Section.  The draft does not

Looks like they're hard references rather than soft ones.  I'll get the author to fix it.

>    DKIM-ADSP-DNS It is the ADSP record used to obtain the ADSP result.

How about:

	DKIM-ADSP-DNS: Includes the ADSP policy used to obtain the verifier's ADSP result.

("record" suggests an RRTYPE, and there isn't one specific to ADSP)

> I did not include a "MUST" as there is already one in Section 3.3

We didn't either.  :-)

> Please refer to my previous comments about the usage of "authentication
> failure".

Agree.

>    "Supplementary data MAY be included in the form of [MAIL]-compliant

SHOULD [NOT] and MUST [NOT] don't apply... :-)

Is there a problem with "MAY" there?

> There should be a normative reference to RFC 5234 given the ABNF in

Wow, I don't know how I missed that one.  We'll add it.

> I suggest removing the "something like".

I disagree, since one could also in theory use PGP or S/MIME for similar effect.  DKIM is just the most common example, and is actually in practical use in ARF terms.

> Isn't the Return-Path: mail header inserted before the Received: mail

Quite right.

> I suggest adding a comment for the RFC Editor to reference "this RFC".

Yes, that would be the right thing to do.

> reviews the example for correctness.

Right, it should be removed.  And given some other comments made within the WG, we'll be revisiting the example before it goes to the IESG.

Thanks again,
-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 02 Dec 2011 14:25:44 -0800

Hi Murray,
At 12:39 02-12-2011, Murray S. Kucherawy wrote:
>There will probably be a few people concerned about the 
>"authentication vs. authorization" matter, but I think RFC5451 dealt 
>with this reasonably well, and the field

Agreed.

>If it would help, we could add a reference to RFC5451 Section 1.5.2, 
>which talks about the differences and their effective union in this area.

That may help if you want to avoid getting into a discussion about 
authentication v/s authorization.  The draft already references RFC 
5451 normatively.  A reference could be added in the Introduction Section.

>I suppose it's worded that way because we created a new report type 
>but had to make a number of changes to IANA registries to do so, 
>hence the plural.  But it really is one omnibus extension action.  I 
>don't have a preference as to wording; if the plural is confusing, 
>we can change it.

It can be argued either way.  The Abstract Section mentions "an 
extension report type to ARF".

>The point of saying this is that RFC5965 allows for the absence or 
>presence of the field, but proscribes multiple instances of it.  We 
>want to say, for this report type, that Original-Envelope-ID should 
>be there, further limiting the "absence" case.
>

Yes.

As an editorial comment, Section 3.2 of RFC 5965 uses two key words 
for the six header fields.  Section 3.1 of this draft uses ten key 
words for six header fields.  Imperatives should not only be used 
with care and sparingly; it also helps if the reader can easily 
identify what is required versus what is recommended.

>The Source-IP is a key piece of information for reconstructing why 
>an SPF evaluation failed.  It needs to be there if it's available, 
>or the failure report is basically incomplete.

Your reply clarifies when the "SHOULD" does not apply.  If it is a 
key piece of information which is necessary for interoperability, 
specify it as a requirement.

>It is the same, except that RFC5965 makes it entirely optional.  For 
>this report type, we want to see it at least once.

There could be an explanation about that in the draft.

>I agree with the reference change, however the "contrary" part is 
>correct because [REPORT] says the third MIME part in a report is 
>optional, while for this specific instance of it, we want it to be 
>there.  If it would help for illustration, we could say "(contrary 
>to [REPORT], which makes it optional)".

Ok.

>We actually had it the other way (as you suggest), and then changed 
>it to this because we thought this description was more effective, 
>i.e., having the strongest requirement first.

Ok.

>("record" suggests an RRTYPE, and there isn't one specific to ADSP)

I used "record" as that is the term I found in RFC 5617.  The above sounds Ok.

>Is there a problem with "MAY" there?

No. :-)

>I disagree, since one could also in theory use PGP or S/MIME for 
>similar effect.  DKIM is just the most common example, and is 
>actually in practical use in ARF terms.

Ok.

>Right, it should be removed.  And given some other comments made 
>within the WG, we'll be revisiting the example before it goes to the IESG.

Please note that the review is semi-formal.  The Application Area 
Directors may or may not agree with me about the issues identified in 
the review.

Regards,
S. Moonesamy

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Sat, 03 Dec 2011 21:56:34 -0500

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

>extension report type to ARF".

How about making it singular but adding a phrase "affecting multiple
registries"?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 4 Dec 2011 11:06:59 -0800

> Sent: Saturday, December 03, 2011 6:57 PM
> To: [email-masked]
> Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05
> 

That would probably be fine too.

---

From: Hilda Fontana <[email-masked]>
Date: Mon, 5 Dec 2011 09:24:46 -0800

> >That would probably be fine too.

ok so
... an extension report type to ARF
affecting multiple entries for use in reporting messages
that fail one or more authentication checks performed
on receipt of a message...

would that work?

>
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Dec 2011 10:00:44 -0800

I suggest putting commas around "affecting multiple registries", but otherwise it's fine.

From: Hilda Fontana [mailto:[email-masked]]
Sent: Monday, December 05, 2011 9:25 AM
To: Murray S. Kucherawy
Cc: Message Abuse Report Format working group
Subject: Re: [marf] [apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05

On Sun, Dec 4, 2011 at 11:06 AM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Shmuel Metz
> To: [email-masked]<mailto:[email-masked]>
> In <[email-masked]<mailto:[email-masked]>>, on 12/02/2011
>    at 02:25 PM, S Moonesamy <[email-masked]<mailto:[email-masked]>> said:
>

ok so

would that work?

_______________________________________________
marf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/marf

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Dec 2011 09:50:25 +0100

> on receipt of a message...

Excuse me if this question is trivial, but doesn't the verb "to report
a message" imply that the message was received?  This is also present
in the current wording:

   reporting messages that fail one or more authentication checks
   performed on receipt of a message

Would "performed on their reception" be grammatically better?

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Tue, 06 Dec 2011 05:55:27 -0500

In <[email-masked]>, on 12/06/2011
   at 09:50 AM, Alessandro Vesely <[email-masked]> said:

>Excuse me if this question is trivial, but doesn't the verb "to
>report a message" imply that the message was received? 

How about

Abstract

   This memo registers an extension report type to ARF, affecting
   multiple IETF registries, for use in reporting attempts to send
   messages that fail one or more authentication checks performed
   on receipt of a message, with the option to include forensic
   information describing the specifics of the failure.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Dec 2011 10:04:57 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Tuesday, December 06, 2011 12:50 AM
> To: Hilda Fontana
> Cc: [email-masked]
> > affecting multiple entries for use in reporting messages that fail one
> > or more authentication checks performed on receipt of a message...
> >
> > would that work?
> 

"to report a message" indicates intent, and "on receipt of a message" states clearly when it is intended that this be used.  Otherwise, you could report a message long after receipt occurs (for some reason).

If we're really keen to common factor the language, we could use:

"...an extension report type to ARF, affecting multiple registries, for use in generating receipt-time reports about messages that fail one or more email authentication checks."