[apps-discuss] APPSDIR review of draft-ietf-marf-authfailure-report-05

[S Moonesamy <[e-mail]>]

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: [e-mail]"

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