Subject: Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF Authentication Failure Reporting using the Abuse Report Format) to Proposed Standard

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 09:09:49 -0500

> The MARF charter [1] does not contain any mention of "SPF Authentication
> Failure Reporting using the Abuse Report Format" as a deliverable.  There is
> no mention of SPF in the charter.

Keep in mind that the charter has these two items:

 2) The group will produce an informational document detailing
 guidelines for deploying and using ARF, including descriptions
 of current practices and their rationales.

 3) The group will specify the integration of ARF into DKIM-aware
 environments, with draft-kucherawy-dkim-reporting-06 as its input.
 It contains extensions to DKIM that are related to ARF as a means
 of reporting DKIM-related failures which include phishing
 ("fraud") and as such are relevant to the ARF effort. The group
 will produce Proposed Standard track specification for these
 ARF and DKIM extensions.

Then note this:
1. The reporting document originally included the SPF information,
since there's a lot of common aspects, and it makes sense to talk
about both.  The WG decided to split the document into four pieces,
for organizational purposes, with authfailure-report, redaction, dkim,
and spf as separate pieces.

2. SPF is widely deployed in the real world.  Information about
deploying and using ARF (item 2 in the charter) in such an environment
is absolutely part of the charter.

It's important to get this information out there in parallel with the
DKIM information.  If the output of the spfbis working group results
in a need for a revision to this document, such revision can be taken
up then.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Mar 2012 09:22:22 -0500

On Wednesday, February 29, 2012 10:26:41 PM SM wrote:
> At 16:46 29-02-2012, The IESG wrote:
> >The IESG has received a request from the Messaging Abuse Reporting Format
> >WG (marf) to consider the following document:
> >- 'SPF Authentication Failure Reporting using the Abuse Report Format'
> >
> >   <draft-ietf-marf-spf-reporting-08.txt> as a Proposed Standard
> >
> >The IESG plans to make a decision in the next few weeks, and solicits
> >final comments on this action. Please send substantive comments to the
> >[email-masked] mailing lists by 2012-03-14. Exceptionally, comments may be
> 
> [snip]
> 
> >Note that this document has a downward normative reference: This
> >document makes a normative reference to SPF (RFC4408), which is
> >Experimental.
> The MARF charter [1] does not contain any mention of "SPF
> Authentication Failure Reporting using the Abuse Report Format" as a
> deliverable.  There is no mention of SPF in the charter.
> 
> According to the Abstract Section of this document:
> 
>    "This memo presents extensions to the Abuse Reporting Format (ARF),
>     and Sender Policy Framework (SPF) specifications to allow for
>     detailed reporting of message authentication failures in an on-demand
>     fashion."
> 
> This extends a specification on which there hasn't been any
> conclusion yet.  I note that there is a downward normative reference
> to RFC 4408.  During discussions about RFC 4408, on which I don't
> have any opinion up to now, there have been comments about:
> 
>   (i)   The specification not being sufficiently clear.
> 
>   (ii)  A compelling case that there is, indeed, an error in RFC4408.
> 
>   (iii) Interoperability problems in the protocol due to DNS
> "incompatibility".
> 
> I suggest that the IETF waits for a migration or co-existence
> document which discusses about the non-standards track protocol on
> which there is a downward reference.

I'll limit my response to these aspects of your comment, since they are the 
most important to resolve.

I'll leave it to the MARF chairs to explain their view of how this is related 
to the charter.  This draft is, however, related to draft-ietf-marf-
authfailure-report, which is already through last call and approved by the 
IESG.  It includes SPF specifics (although it doesn't require a normative 
reference to RFC 4408, so there's no downref issue with it), so I think that 
in the context of authentication failure reporting this is already established 
to be in scope.  All the current draft does is provide an optional mechanism 
to make the desire for such reports discoverable.

This draft does not depend on any elements of RFC 4408 that are under review 
in SPFbis (in fact, it's not possible in the current scope of the SPFbis 
charter to change any of them), so the risk that the ongoing work in SPFbis 
will affect this body of work is nil.

I don't think it's efficient at all to put this draft on hold and revive it 
later for non-technical reasons.

Scott K

---

From: SM <[email-masked]>
Date: Thu, 01 Mar 2012 07:53:48 -0800

>Keep in mind that the charter has these two items:

Ok.

>2. SPF is widely deployed in the real world.  Information about

Is a protocol considered by the IETF to be widely deployed based on 
deployment of implementations?  For example, an IPv6 survey ( 
http://dns.measurement-factory.com/surveys/2011/IPv6/ ) used a a 
DNS-centric perspective to measure some basic statistics on IPv6 
deployment.  Are such statistics acceptable to the IETF to determine 
wide deployment of RFC 2460?

Quoting a report from 2010 about DNSSEC:

   "2010 has been a significant year for DNSSEC. On July 15th, the root zone
    was signed, removing one of the most significant barriers to broad DNSSEC
    deployment. However other obstacles remain:

    - The .com and .net zones are not yet signed.
    - Few registrars support DNSSEC.
    - Few resolvers have DNSSEC validation enabled.
    - The tools for managing signed zones are basic and typically entail a
      steep learning curve.

  Consequently DNSSEC deployment is still extremely limited."

The above mentions some of the factors that affects DNSSEC 
deployment.  If DNSSEC records are published in DNS but few resolvers 
have DNSSEC validation enabled, does that constitute wide deployment?

According to BCP 97:

   "In the IETF, it is a basic assumption that implementors must have a
    clear understanding of what they need to implement in order to be
    fully compliant with a standard and to be able to interoperate with
    other implementations of that standard".

Is the interoperability assessment based on implementations of a 
specification or are other ways to determine interoperability 
acceptable to the IETF?

>to be in scope.  All the current draft does is provide an optional mechanism

In the Last Call message issued by the IESG, it is mentioned that:

   "Note that this document has a downward normative reference: This document
    makes a normative reference to SPF (RFC4408), which is Experimental."

Is the downward normative reference in the draft incorrect?

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Mar 2012 11:53:35 -0500

On Thursday, March 01, 2012 07:53:48 AM SM wrote:
...
> >reference to RFC 4408, so there's no downref issue with it), so I think
> >that in the context of authentication failure reporting this is already
> >established
>    "Note that this document has a downward normative reference: This
> Experimental."

No.  The downref is correct.  Downrefs are allowed, but have to be reviewed 
(AIUI).  I was saying that I think the downref is safe and appropriate in this 
instance because the parts of RFC 4408 that are relevant to this draft are 
stable and it would be very, very, very unlikely for them to change in SPFbis.

The "no downref issue" was related to draft-ietf-marf-authfailure-report-10, 
not this one.

Scott K

---

From: SM <[email-masked]>
Date: Thu, 01 Mar 2012 10:00:56 -0800

>(AIUI).  I was saying that I think the downref is safe and appropriate in this

The question would be whether the downward reference is in accordance 
with BCP 97.  It is up to the IESG to consider whether a 
non-standards track protocol which has not received full IETF review 
is in line with BCP 97.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Mar 2012 10:18:48 -0800

> later for non-technical reasons.

+1

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 18:34:46 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Thursday, March 01, 2012 10:01 AM
> To: [email-masked]
> Subject: Re: Last Call: <draft-ietf-marf-spf-reporting-08.txt> (SPF
> Authentication Failure Reporting using the Abuse Report Format) to
> Proposed Standard
> 
> >No.  The downref is correct.  Downrefs are allowed, but have to be
> >reviewed (AIUI).  I was saying that I think the downref is safe and
> >appropriate in this
> 
> with BCP 97.  It is up to the IESG to consider whether a non-standards
> track protocol which has not received full IETF review is in line with
> BCP 97.

The citation you made from BCP 97 says that the standard needs to be clear and interoperable.  In this case, BCP 97 applies to the document under evaluation, not to RFC4408, as the latter is Experimental.

The specification contained in RFC4408 has flaws that have long been acknowledged and some new ones that have recently come to light, but despite these it is operationally stable and its output is deterministic, resulting in widespread deployment and numerous interoperating implementations.  Given that, I don't believe the proposed standard under consideration fails to meet the requirements of BCP 97.

If and when the spfbis working group produces an update that fixes RFC4408, and/or new versions of SPF come out that actually alter the output of SPF, an update to this document that accommodates those changes could be made to keep them aligned, as Barry has already pointed out.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 18:41:44 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, March 01, 2012 6:22 AM
> To: [email-masked]
> I don't think it's efficient at all to put this draft on hold and
> revive it later for non-technical reasons.

+1.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Mar 2012 19:14:20 +0000

> Sent: Wednesday, February 29, 2012 10:27 PM
> To: [email-masked]

As for your non-procedural concerns:

> I'll avoid commenting on the technical angle.  Here are some editorial
> comments:
> 
> In Section 3:
> 
>    "There exist cases in which a domain name owner employing [SPF] for
>     announcing sending practices may want to know when messages are
>     received via unauthorized routing."
> 
> I suggest not using the term "domain name owner" to side-step the
> question of domain "ownership".

Would "ADMD" and an informative reference to RFC5598 be more appropriate?

>    "particular because a message arrived via an unauthorized route.
>     To generate a complete address to which the report is sent, the
>     verifier simply appends to this value an "@" followed by the
>     SPF domain per paragraph 4.1 of [SPF]."
> 
> RFC 4408 uses the term "SPF-compliant domain".

That's fine with us.

> In Section 5.1:
> 
>    "New registrations or updates MUST be published in accordance with the
>     "Specification Required" guidelines as described in
>     [IANA-CONSIDERATIONS].  New registrations and updates MUST contain
>     the following information:"
> 
> I suggest not using RFC 2119 key words in the IANA Considerations
> section unless there are interoperability issues with IANA.

We'll change "MUST" to "are to be".

>    "current:  The field is in current use
> 
>     deprecated:  The field is in current use but its use is
>        discouraged"
> 
> The difference in "current use" can end up being problematic for the
> designated expert.

A number of registries are using this wording already and there's been no objection to date.  Do you have a better suggestion?

> In Section 6:
> 
>   "Security issues with respect to these reports are similar to those
>    found in [DSN]."
> 
> The reference to DSN could be normative.

Security Considerations are never normative, so I'm not sure I agree that this should be.

>    "The HELO/EHLO command SHOULD also be selected so that it
>     will pass [SPF] HELO checks."
> 
> I could not understand what to do about the above recommendation.
> FWIW, the command is specified in RFC 5321.  That specification is not
> referenced by this draft.

Yes, that needs to be clarified, the reference added, and the typo in the section title needs correction.

Thanks,
-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 16:01:20 -0500

> A number of registries are using this wording already and there's been no
> objection to date.  Do you have a better suggestion?

I suggest, "The field might still be in use, but its use is discouraged."

> Security Considerations are never normative, so I'm not sure I agree that this should be.

It should.  Just because the Security Considerations section doesn't
usually use normative language doesn't mean that it's not normative.
People reading the document and implementing the protocol certainly
have to read and understand the Security Considerations section, along
with any transitive sections in other documents.

Barry, MARF co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Mar 2012 16:15:05 -0500

On Thursday, March 01, 2012 04:01:20 PM Barry Leiba wrote:
...
> with any transitive sections in other documents.

The reason I didn't make it normative when I drafted that section is because 
this isn't a DSN, it's an ARF, thus the similar to.  If people think it should 
be normative, I think it's fine to change it.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Thu, 1 Mar 2012 16:47:43 -0500

> be normative, I think it's fine to change it.

Yes, but think about the difference between these two statements:

1. Security issues with respect to these reports are similar to those
found in [DSN].

2. Security issues with respect to these reports are similar to those
found in [DSN].  Specifically, X and Y.  Also Z, when that situation
is applicable.

In the second case, you can understand the security issues here
without going and reading [DSN].  It really is just saying that these
are similar to those, so the reference is informative.  In the first
case, how can you know *anything* about the security issues without
reading the referenced document?

If sections 6.1 and 6.2 really do say everything that needs to be
said, and the sentence in 6. could be removed without loss of
important information, then leave it as an informative reference.  If
one really has to go to [DSN] to see what some of the issues are, make
it normative.  That's the test.

Barry

---

From: SM <[email-masked]>
Date: Thu, 01 Mar 2012 14:31:40 -0800

>Would "ADMD" and an informative reference to RFC5598 be more appropriate?

   There exist cases in which the administrator of domain name employing
  [SPF] for announcing sending practices may want to know when messages are
   received via unauthorized routing.

>A number of registries are using this wording already and there's 
>been no objection to date.  Do you have a better suggestion?

It's not an objection.  The comments were labelled as editorial.

draft-nottingham-appsawg-happiana-00 contains some suggestions.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Mar 2012 10:22:57 -0500

On Thursday, March 01, 2012 04:47:43 PM Barry Leiba wrote:
> >> > Security Considerations are never normative, so I'm not sure I
> >> > agree
> >> > that this should be.
> >> 
> > The reason I didn't make it normative when I drafted that section is
> > because this isn't a DSN, it's an ARF, thus the similar to.  If people
> > think it should be normative, I think it's fine to change it.
> 

Makes sense.  Thanks for the clarification.

Today I reviewed RFC 3464 again.  It has the following security 
considerations:

4.1 Forgery
4.2 Confidentiality
4.3 Non-Repudiation

Of these, I think that only forgery is relevant to this draft.  The non-
repudiation issue is not applicable to authentication failure reporting.  The 
confidentiality issue should be addressed in the document that discusses 
creation and formatting of these reports.

draft-ietf-marf-authfailure-report-10 (which is already a normative reference 
and listed for included security considerations) covers forgeries in great 
detail, so to the extent the advice in 6.2 of this draft doesn't address it, I 
think it's addressed there.

Based on that, I think that the sentence in paragraph 6 could be lost without 
losing anything important, so I think it should stay as it is.

This discussion also caused me to re-read draft-ietf-marf-authfailure-
report-10 again since that's where report generations is described.  It is (I 
believe) silent on confidentiality, except to say:

6.  Security Considerations

   Security issues with respect to these reports are similar to those
   found in [DSN].

(the exact same text that caused comment in this draft)

It might be worth someone looking at draft-ietf-marf-authfailure-report-10 
again to see if that's really appropriate.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Mar 2012 12:02:06 -0500

> Would "ADMD" and an informative reference to RFC5598 be more appropriate?

I think it wouldn't.  As I read 5598, ADMD is the provider of services.  If 
you look at the examples in 5598, paragraph 2.3, only one of those, Enterprise 
Service Providers, is also the owner of the domain (and the one that controls 
policy).  For many small domains they use the services of ISPs or ESPs (the 
other two examples), but in no way should ISPs or ESPs be determining what 
goes into a domain's SPF record for domains they don't own (this has been 
tried, BTW, and it was a disaster).

Domain owners is the term used in RFC 4408 (see paragraph 1, introduction).  
I'm not sure what question of domain ownership we're trying to side step, but 
the term seems to me to be both literally correct and the same terminology 
already in use in related documents (also, I might add) a term no one has 
suggested should be changed in SPFbis).

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Mar 2012 12:19:09 -0500

On Thursday, March 01, 2012 07:14:20 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > SM Sent: Wednesday, February 29, 2012 10:27 PM
> > To: [email-masked]

Replied seprately.  I think it should stay as it is.

> > RFC 4408 uses the term "SPF-compliant domain".

Done in my local copy

> We'll change "MUST" to "are to be".

Done in my local copy

> > The difference in "current use" can end up being problematic for the

Done in my local copy.

> > The reference to DSN could be normative.

Replied separately.  I think it should stay the way it is.

> section title needs correction.

I agree I should add the reference to 5321.  Is informative sufficient (I don't 
think any detailed understand of Mail From or EHLO/HELO is necessary to 
implement this spec).

I can see the construction is awkward, but I'm not sure how to make it better.  
I'd appreciate suggestions.

> I suggest, "The field might still be in use, but its use is discouraged."

Done in my local copy.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Mar 2012 18:16:47 +0000

> Sent: Friday, March 02, 2012 9:02 AM
> To: [email-masked]
> I think it wouldn't.  As I read 5598, ADMD is the provider of services.

It's an MTA operator (RFC5598, 2.2.1), but basically the term is used to indicate a separate organization that might own one or more domains.  Google, for example, owns gmail.com and google.com (and googlers.com now), but that's all one ADMD.  This is how the term is used in several other documents.  It's obvious that this is the ADMD that will be the one setting SPF (or any) policy for mail use with respect to those domains, regardless of who actually handles the mail.

> I'm not sure what question of domain ownership we're trying to side
> step, but the term seems to me to be both literally correct and the
> same terminology already in use in related documents (also, I might
> add) a term no one has suggested should be changed in SPFbis).

I don't feel strongly about changing to ADMD except inasmuch as I suspect it might resolve the comment and is a more commonly used term.  I'm actually fine with "domain owner" because that's also an implicit property of the ADMD.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Mar 2012 18:28:32 +0000

> Sent: Friday, March 02, 2012 9:19 AM
> To: [email-masked]
> > > FWIW, the command is specified in RFC 5321.  That specification is
> > > not referenced by this draft.
> >
> I agree I should add the reference to 5321.  Is informative sufficient
> (I don't think any detailed understand of Mail From or EHLO/HELO is
> necessary to implement this spec).
> 

I suggest:

OLD:
   In addition to the advice in security considerations of
   [I-D.IETF-MARF-AS] the additional consderations apply to [SPF] auth
   failure reports.  If the MAIL FROM command is not the NULL return
   address, i.e., "MAIL FROM:<>", then the selected MAIL FROM address
   MUST pass [SPF] MAIL FROM checks on receipt.  The HELO/EHLO command
   SHOULD also be selected so that it will pass [SPF] HELO checks.

NEW:
	In addition to the advice in the Security Considerations section of
	[I-D.IETF-MARF-AS], these additional considerations apply to
	generation of [SPF] authentication failure reports:

	o If the return address to be used will not be the NULL return
	  address, i.e., "MAIL FROM:<>", then the selected return address
	  MUST be selected such that it will pass [SPF] MAIL FROM checks
	  upon initial receipt.

	o If the report is passed to the Mail Submission Agent (MSA)
	  using [SMTP], the HELO/EHLO command parameter SHOULD also be
	  selected so that it will pass [SPF] HELO checks.

If needed, MSA is defined in RFC5598, so maybe this is another argument for adding it as an informative reference and changing to use ADMD as discussed in the other thread.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 2 Mar 2012 18:43:32 +0000

> Sent: Friday, March 02, 2012 7:23 AM
> To: [email-masked]
> Based on that, I think that the sentence in paragraph 6 could be lost
> without losing anything important, so I think it should stay as it is.

Yes, I suggest that the sentence that comprises Section 6 proper can be dropped.  The text currently in 6.1 can be moved up to 6, and the current 6.1 thus removed.

> again to see if that's really appropriate.

I'll take a second look.

-MSK, MARF co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Mar 2012 19:27:35 -0500

On Friday, March 02, 2012 06:43:32 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Friday, March 02, 2012 7:23 AM
> > To: [email-masked]
> Yes, I suggest that the sentence that comprises Section 6 proper can be
> dropped.  The text currently in 6.1 can be moved up to 6, and the current
> 6.1 thus removed.

Done in my local copy.

> > It might be worth someone looking at
> > draft-ietf-marf-authfailure-report-10 again to see if that's really
> > appropriate.
> 
> I'll take a second look.

Thanks.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Mar 2012 19:54:40 -0500

On Friday, March 02, 2012 06:28:32 PM Murray S. Kucherawy wrote:
> > Scott Kitterman Sent: Friday, March 02, 2012 9:19 AM
> > To: [email-masked]
> > > Yes, that needs to be clarified, the reference added, and the typo
> > > in
> > > the section title needs correction.
> > 
> > I can see the construction is awkward, but I'm not sure how to make it
> > better. I'd appreciate suggestions.
> 
> I suggest:
> 
> OLD:
> If needed, MSA is defined in RFC5598, so maybe this is another argument for
> adding it as an informative reference and changing to use ADMD as discussed
> in the other thread.

Thanks.  Done (including replacing domain owner) in my local copy.

Scott K

---

From: Hector <[email-masked]>
Date: Sat, 03 Mar 2012 00:53:55 -0500

Murray S. Kucherawy wrote:
> If needed, MSA is defined in RFC5598, so maybe this is another argument 
> for adding it as an informative reference and changing to use ADMD as 
> discussed in the other thread.

If applicable, I would like to provide the following implementation note:

MSA - what kind?

The PORT 587 kind or a Port 25 kind with a user using ESMTP AUTH?

Why?

Since use RFC6409 (formerly 4409) has a PORT 587 and ESMTP AUTH 
requirement which the public SMTP port does not, it was as a indicator 
and method to skip the strong EHLO checking requirement.

In practice this became necessary with the growth of the SOHO and home 
use NAT market with now Mommy and Daddy had their PCs on the home 
network and the MUA they used exposed the private side IP literal and 
the Connection IP was that of the NAT.

It was a problem for the SUBMISSION protocol with strong EHLO checking 
requirements.

The solution was to get the MUA (in this case Thunderbird) to offer 
flexibility in its MTA setting for the EHLO command and in the mean 
time, relaxed a port 587 connection to delay or skip any initial EHLO 
checking until the required ESMTP AUTH was completed.

With a public port SMTP session, the ESMTP AUTH (MSA like behavior) is 
not required so any EHLO checking can apply when first presented.

Thanks

--
HLS