Subject: [marf] Suggested changes to draft-ietf-marf-authfailure-report

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Oct 2011 21:53:22 -0700

To aid Hilda in preparing an update, here are some of the changes I think consensus appears to support with respect to a revision of draft-ietf-marf-authfailure-report.  Please let me know if I have any of it wrong.  Some of these are point notes and not exact text changes, but should be enough for her to make the edits.

Abstract

-          New text: "This memo registers an extension report type to ARF for use in reporting 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."

Section 1

-          New text: "[ARF] defines a message format for sending reports of abuse in the messaging infrastructure, with an eye towards automating both the generation and consumption of those reports.  There is now also a desire to use extend the ARF format to include reporting of messages that fail to authenticate using known authentication methods, as these are sometimes evidence of abuse that can be detected and reported through automated means.  The same mechanism can be used to convey forensic information about the specific reason the authentication method failed.  Thus, this memo presents such extensions to the Abuse Reporting Format to allow for detailed reporting of message authentication failures."

Section 3.1

-          Authentication-Results MUST appear at least once, and SHOULD report all methods that were tested by the entity generating the report.  It MUST be formatted according to [AUTH-RESULTS].

-          Original-Envelope-Id SHOULD be included exactly once if it is available to the entity generating the report.

-          Original-Mail-From and Source-IP SHOULD be included exactly once for SPF, or for other methods that evaluate authentication during the SMTP phase.  Remove the stuff about 0.0.0.0.

-          Delete Message-ID, as it is available in the third part of the report.

-          Delete Arrival-Date, as it's not relevant to DKIM or SPF specifically, and can be inferred from both report generation time and the Received fields in the third part of the report.

-          Reported-Domain MUST appear at least once (not exactly once).

-          Delivery-Result is OPTIONAL, MUST NOT appear more than once.  If present, it SHOULD indicate the outcome, etc.

Section 3.2.2

-          Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body to new section 3.2.3.

New Section 3.2.3: Optional for DKIM reports

-          Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body here.

-          Add a paragraph that says DKIM-Canonicalized-Header and DKIM-Canonicalized-Body MUST NOT include redacted data.  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.)

New Section 3.2.4: Required for ADSP Reports

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

-
New Section 3.2.5: Required for SPF Reports

-          SPF-DNS MUST appear once for every query to an SPF record that was done, to enable the reporting of included fields and where they came from.  The ABNF in Section 4 changes; see below.

Section 3.3

-          The new set of failure modes is: dkim-adsp, dkim-bodyhash, dkim-revoked, dkim-signature, spf-fail, spf-softfail, spf-permerror.  "granularity" is no longer a valid DKIM result, so it should be deleted.  The descriptive text can stay for the DKIM ones, and the SPF ones can be copy-and-pasted accordingly (should be fairly straightforward).

Section 4

-          SPF-DNS ABNF changes to: { "txt" / "spf" } [FWS] ":" [FWS] domain [FWS] ":" [FWS] quoted-string

Section 5

-          Delete the second paragraph.  This seems to be a sufficient paring down given the other new text about it that I've suggested here.

Section 7.1

-          Correct spelling of "implementers".

Section 7.4

-          Replace with: "In the case of transmitted reports in the form of a new message, it is necessary to consider the construction and transmission of the message so as to avoid amplification attacks, deliberate or otherwise.  See Section 5 of [ARF] for further information."

New Section 7.6: Redaction Of Data In DKIM Reports

-          Suggested text: "This memo requires that the canonicalized header and body be returned without being subject to redaction when a DKIM failure is being reported.  This is necessary to ensure that the returned canonicalized forms are useful for debugging as they must be compared to the equivalent form at the signer.  If a message is altered in transit, and the returned data are also redacted, the redacted portion and the altered portion may overlap, rendering the comparison results meaningless.  However, unredacted data can leak information the reporting entity considers to be private.  It is for this reason the return of the canonicalized forms is rendered optional."

Appendix A

-          Add the names of people that contributed to this feedback, although they get wrist-slapped for waiting until the last minute to do so.  :)

Appendix B

-          Replace the URL in the example with "RFC5965".

-MSK

---

From: "Hilda Fontana" <[email-masked]>
Date: Fri, 7 Oct 2011 08:34:24 -0700

Thanks Murray and everyone for your input.  I shall put a draft together
with these changes and get it posted as soon as I can.  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murray S. Kucherawy
Sent: Thursday, October 06, 2011 9:53 PM
To: Message Abuse Report Format working group
Subject: [marf] Suggested changes to draft-ietf-marf-authfailure-report

To aid Hilda in preparing an update, here are some of the changes I think
consensus appears to support with respect to a revision of
draft-ietf-marf-authfailure-report.  Please let me know if I have any of it
wrong.  Some of these are point notes and not exact text changes, but should
be enough for her to make the edits.

Abstract

-          New text: "This memo registers an extension report type to ARF
for use in reporting 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."

Section 1

-          New text: "[ARF] defines a message format for sending reports of
abuse in the messaging infrastructure, with an eye towards automating both
the generation and consumption of those reports.  There is now also a desire
to use extend the ARF format to include reporting of messages that fail to
authenticate using known authentication methods, as these are sometimes
evidence of abuse that can be detected and reported through automated means.
The same mechanism can be used to convey forensic information about the
specific reason the authentication method failed.  Thus, this memo presents
such extensions to the Abuse Reporting Format to allow for detailed
reporting of message authentication failures."

Section 3.1

-          Authentication-Results MUST appear at least once, and SHOULD
report all methods that were tested by the entity generating the report.  It
MUST be formatted according to [AUTH-RESULTS].

-          Original-Envelope-Id SHOULD be included exactly once if it is
available to the entity generating the report.

-          Original-Mail-From and Source-IP SHOULD be included exactly once
for SPF, or for other methods that evaluate authentication during the SMTP
phase.  Remove the stuff about 0.0.0.0.

-          Delete Message-ID, as it is available in the third part of the
report.

-          Delete Arrival-Date, as it's not relevant to DKIM or SPF
specifically, and can be inferred from both report generation time and the
Received fields in the third part of the report.

-          Delivery-Result is OPTIONAL, MUST NOT appear more than once.  If
present, it SHOULD indicate the outcome, etc.

Section 3.2.2

-          Move DKIM-Canonicalized-Header and DKIM-Canonicalized-Body to new
section 3.2.3.

-          Add a paragraph that says DKIM-Canonicalized-Header and
DKIM-Canonicalized-Body MUST NOT include redacted data.  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.)

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

-           

-          SPF-DNS MUST appear once for every query to an SPF record that
was done, to enable the reporting of included fields and where they came
from.  The ABNF in Section 4 changes; see below.

Section 3.3

-          The new set of failure modes is: dkim-adsp, dkim-bodyhash,
dkim-revoked, dkim-signature, spf-fail, spf-softfail, spf-permerror.
"granularity" is no longer a valid DKIM result, so it should be deleted.
The descriptive text can stay for the DKIM ones, and the SPF ones can be
copy-and-pasted accordingly (should be fairly straightforward).

Section 4

-          SPF-DNS ABNF changes to: { "txt" / "spf" } [FWS] ":" [FWS] domain
[FWS] ":" [FWS] quoted-string

Section 5

-          Delete the second paragraph.  This seems to be a sufficient
paring down given the other new text about it that I've suggested here.

Section 7.1

Section 7.4

-          Replace with: "In the case of transmitted reports in the form of
a new message, it is necessary to consider the construction and transmission
of the message so as to avoid amplification attacks, deliberate or
otherwise.  See Section 5 of [ARF] for further information."

-          Suggested text: "This memo requires that the canonicalized header
and body be returned without being subject to redaction when a DKIM failure
is being reported.  This is necessary to ensure that the returned
canonicalized forms are useful for debugging as they must be compared to the
equivalent form at the signer.  If a message is altered in transit, and the
returned data are also redacted, the redacted portion and the altered
portion may overlap, rendering the comparison results meaningless.  However,
unredacted data can leak information the reporting entity considers to be
private.  It is for this reason the return of the canonicalized forms is
rendered optional."

Appendix A

-          Add the names of people that contributed to this feedback,
although they get wrist-slapped for waiting until the last minute to do so.
J

Appendix B

-MSK

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 7 Oct 2011 23:36:24 +0200

On 7 October 2011 17:34, Hilda Fontana wrote:

> Thanks Murray and everyone for your input.  I shall put a draft
> together with these changes and get it posted as soon as I can.

>> Please let me know if I have any of it wrong.

>> New text: “This memo registers an extension report type to ARF
>> for use in reporting messages that fail one or more authentication
>> checks performed on receipt of a message
[...]

Maybe s/suthentication/authorization or authentication/ to address
one concern of Doug Otis.  I'd really prefer to stay out of these
terminology nits, but if adding 20 characters helps to get rid of
one recycled vintage 2006 dispute...

-Frank

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 07 Oct 2011 18:26:41 -0500

> one recycled vintage 2006 dispute...

The header field we are basing this on is called authentication results.  That 
ship already sailed.

Changing it to something else will be more confusing for everyone !Doug.

-1

Scott K

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 8 Oct 2011 01:56:46 +0200

On 8 October 2011 01:26, Scott Kitterman wrote:

> The header field we are basing this on is called authentication
> results.  That ship already sailed.

ACK.  Besides RFC 4408 always uses the "correct term" for everyone
including Doug.  His broken record^W^Wsuggestion to change "policy"
into "script" can be evaluated for 4008bis.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 7 Oct 2011 20:22:49 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Friday, October 07, 2011 4:27 PM
> To: [email-masked]
> Subject: Re: [marf] Suggested changes to draft-ietf-marf-authfailure-report
> 

I agree.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 12 Oct 2011 00:50:56 -0700

> into "script" can be evaluated for 4008bis.

Nothing has changed.  Bulk senders don't care about risks, just turning 
a profit.  But...

10 macro mechanisms x 10 resolutions per connection represents a hazard, 
especially when confronting IPv4 in a growing IPv6 world.  How can 
defensive strategies deal with shared translation mechanisms without 
causing significant disruption?  Distributing the potential of SPF 
derived transactions emitted by libraries applying script-like macro 
expansions represent a real risk of enabling distributed denial of 
services.  The underlying mechanism of such attacks will be difficult to 
identify and impossible to defend against, that can target any domain 
not even present within the message.

Also too many forget SPF is _not_ an Authentication mechanism.  SPF can 
offer pass results unrelated to the source IP address also not captured 
in Authentication-Results headers.  Those making use of SPF need to be 
repeatedly reminded of SPF limitations and risks.  For example, SPF 
selected by Mail From or PRA can not be used to validate receivers of 
feedback.

Requiring DKIM headers not be redacted also provides spammers a sure 
place to encode spamtrap locations.  Another don't care for bulk senders.

Lack of SPF authentication and lack of sender/recipient information 
applied against DKIM signatures means a system based on these two 
protocols will make it impossible for smaller domains to receive 
equitable treatment.  Equitable treatment demands _all_ accountable 
sources be authenticated as having sourced the message directed to a 
recipient that considered it to be unsolicited and undesired.  Larger 
domains are naturally protected by complaints making them "too big to 
block" and immune against reputation attacks.

-Doug

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Wednesday, October 12, 2011 12:51 AM
> To: [email-masked]

Concerns about SPF aren't appropriate fodder for discussion of this draft.  Both this draft and RFC5451 make it clear that those issues belong to those protocols, and don't need to be re-hashed yet again in this forum.  They are off-topic.

> selected by Mail From or PRA can not be used to validate receivers of

This is covered in RFC5451, to which this draft already refers.

> place to encode spamtrap locations.  Another don't care for bulk

This, however, is something this group should consider and comment on.

Please stick to reviewing the specific content of this draft.  Concerns you have with SPF or DKIM should be addressed elsewhere.

-MSK, as co-chair