Subject: Re: [spfbis] Summary of issues for draft-ietf-spfbis-4408bis

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 1 Feb 2013 11:34:03 -0800

Is there a particular way the chairs would like us to tackle these on the
mailing list?  Are we waiting for Scott to propose changes to address each
of them for the next version?

Just wondering,

-MSK

On Thu, Jan 31, 2013 at 6:02 AM, S Moonesamy <[email-masked]> wrote:

> Hello,
>
> According to the SPFBIS WG Charter the working group was scheduled to
> submit draft-ietf-spfbis-4408bis for publication in December 2012.  Here is
> the list of open issues [1]:
>
> #22 RFC 4408: Section 2.5.7 PermError on invalid domains after macro
> expansion
>
> #24 RFC 4408: Reasonable DNS error limits
>
> #29 RFC 4408: Section 2.5.4 - mark on fail
>
> #34 Throw a temperror - Section 5.2
>
> #35 authorized_spf domain name - Section 9.1.1
>
> #36 RFC 2119 key words
>
> #37 spf classic
>
> #38 Deprecated
>
> #39 Temporary errors implied as only caused by DNS errors
>
> #40 Wildcard records
>
> #41 Multiple DNS errors
>
> #42 Record Evaluation
>
> #43 New requirement for mx: or ptr records
>
> #44 Section 5.4 does not mention requirement in section 4.6.4
>
> #45 Section 5.5 steps
>
> #46 DNS reply in Section 5.7
>
> #47 domain-spec
>
> #48 Section 8.1 - macro defs
>
> #49 IANA registry for SPF modifiers
>
> #50 Terminology
>
> #51 Remove A-R from 4408bis
>
> #52 Section 8.1 *Macro Definitions
>
> #53 Possible ABNF nit with Received-SPF
>
> #54 Section 9.2.1 of 4408bis
>
> #55 Section 9.2.2 Forwarding Services and Aliases
>
> #56 Section 9.2.2 Forwarding Services and Aliases
>
> #57 x-* fields in 4408bis
>
> #58 Local policy in 4408bis
>
> #59 Remove section 9.1.1 DNS Resource Considerations
>
> #6 RFC 4408 Section 10.1 - Processing limits needs clarification and
> reorganization
>
> #33 Marked Failed Mail Exposure
>
> Regards,
> S. Moonesamy
>
> 1. http://trac.tools.ietf.org/wg/**spfbis/trac/report/1<http://trac.tools.ietf.org/wg/spfbis/trac/report/1>
>
> ______________________________**_________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/spfbis<https://www.ietf.org/mailman/listinfo/spfbis>
>

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 01 Feb 2013 14:36:36 -0500

I had anticipated working through this issues next week and making proposals 
or asking for discussion as seemed appropriate.

Scott K

On Friday, February 01, 2013 11:34:03 AM Murray S. Kucherawy wrote:
> > 1.
> > http://trac.tools.ietf.org/wg/**spfbis/trac/report/1<http://trac.tools.ie
> > tf.org/wg/spfbis/trac/report/1>
> >

---

From: S Moonesamy <[email-masked]>
Date: Fri, 01 Feb 2013 11:52:58 -0800

Hi Murray,
At 11:34 01-02-2013, Murray S. Kucherawy wrote:
>Is there a particular way the chairs would like us to tackle these 
>on the mailing list?  Are we waiting for Scott to propose changes to 
>address each of them for the next version?

My individual opinion is to pick the issues you can help to solve, 
suggest text, and the working group can discuss about it.  I would 
suggest keeping it to one issue per thread as it makes it easier to 
track the discussion.

If everybody takes on a few issues it would help speed up the work.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 11:06:14 -0500

> #35 authorized_spf domain name - Section 9.1.1

Closed these as they were fixed in earlier drafts.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 11:07:57 -0500

> #36 RFC 2119 key words

I went back through and tried to address this before the reorg.  I would 
appreciate (using the 4408 -> 08 diff I posted) if someone would review this 
item.  The text of the issue is:

> Overall, when RFC 4408 was drafted, care was taken to capitalize RFC 2119
> keywords, and use the lower case words as regular English meaning. While
> most of the lower case words have been changed to synonyms, a few have been
> changed into RFC 2119 keywords. I think most (but sadly, not all) of these
> capitalizations are wrong.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 12:06:18 -0500

Issue:

> in section 4.6.4, there is a new requirement that there must not be more
> than 10 records for mx: or ptr:. This completely wrong for ptr: because a
> spammer could choose to send spam from a host with more than 10 PTR
> records, thus forcing a domain's SPF record to return permerror, instead of
> fail. If anything, more than 10 PTR records should cause the ptr: mechanism
> to automatically not-match. It should also be made clear that the %{p}
> macro is valid no matter how many PTR records are returned.

Proposed new text for 4.6.4 (in my local copy):

>  When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
>  there MUST be a limit of no more than 10 MX or PTR RRs looked up
>  and checked.  If more than 10 "mx" records are returned for this
>  further lookup, a permerror MUST be returned.  If more than 10 "ptr"
> records are returned for this further lookup (either due to use of
> a "ptr" mechanisms, or the %{p} macro) processing MUST be terminated
> after 10 records.  This limit is per mechanism or macro in the
> record and in addition to the lookup limits above.

Comments please.  If no one objects, I'll include it.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 13:35:55 -0800

Doesn't the same attack exist if one lists >10 MX records?

Just wondering why MX isn't getting the same treatment as PTR in the
proposed new text.

-MSK

On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <[email-masked]> wrote:

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

---

From: Tim Draegen <[email-masked]>
Date: Tue, 5 Feb 2013 16:41:53 -0500

I'm reading that it does get the same treatment..

=- Tim

On Feb 5, 2013, at 4:35 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

> Just wondering why MX isn't getting the same treatment as PTR in the proposed new text.
> 
> -MSK
> 
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 18:02:58 -0500

The difference is that the contents of the MX record are under control of the 
domain owner.  The number of PTR records are under control of the owner of the 
IP address actually making the connection.  If we allow for permerror on too 
many PTR, then that gives someone trying to avoid SPF fail an easy way to turn 
a fail into a permerror.  A similar risk does not exist with MX.

Scott K

On Tuesday, February 05, 2013 01:35:55 PM Murray S. Kucherawy wrote:
> > > records, thus forcing a domain's SPF record to return permerror, instead
> > 
> > of
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 19:08:35 -0800

Got it.  Could we massage that paragraph in to explain the context of the
rule being imposed?

-MSK

On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman <[email-masked]> wrote:

> > > > than 10 records for mx: or ptr:. This completely wrong for ptr:
> because
> > > > a

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 05 Feb 2013 22:13:32 -0500

Sure.  Do you have a suggestion?

Scott K

On Tuesday, February 05, 2013 07:08:35 PM Murray S. Kucherawy wrote:
> > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <[email-masked]>
> > 
> > wrote:
> > > > > in section 4.6.4, there is a new requirement that there must not be
> > 
> > more
> > 
> > > > > records, thus forcing a domain's SPF record to return permerror,
> > 
> > instead
> > 
> > > > of
> > > > 
> > > > > to automatically not-match. It should also be made clear that the
> > 
> > %{p}
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 20:14:13 -0800

How about:

When evaluating the "mx" mechanism, the number of MX resource records
queried MUST NOT exceed 10.  If the evaluation of an "mx" mechanism results
in more than 10 resource records being <returned? queried?>, the "mx"
mechanism MUST produce a "permerror" result (see Section xxx).

When evaluating the "ptr" mechanism, the number of PTR resource records
queried MUST NOT exceed 10.  If the evaluation of a "ptr" mechanism results
in more than 10 resource records being returned, all records other than the
first 10 MUST be ignored.

The reason for the disparity is that the set of and contents of the MX
record are under control of the domain owner, while the set of and contents
of PTR records are under control of the owner of the IP address actually
making the connection.

These limits are per mechanism or macro in the record, and are in addition
to the lookup limits specified above.

<snip>

Could we change "10" to "a fixed but possibly configurable limit", and
indicate that most implementations use 10 as that limit?  10 is effectively
arbitrary, unless studies have shown that it's the best answer.

Also, the ignoring of PTR replies beyond the first 10 renders the protocol
non-deterministic given that replies come back in a random order.  Are we
okay with that?

-MSK

On Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman <[email-masked]> wrote:

> > > The difference is that the contents of the MX record are under control
> of
> > > the
> > > domain owner.  The number of PTR records are under control of the
> owner of
> > > the
> > > IP address actually making the connection.  If we allow for permerror
> on
> > > too
> > > many PTR, then that gives someone trying to avoid SPF fail an easy way
> to
> > > turn

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 20:17:11 -0800

...except with the %{p} stuff folded in, sorry about that.

On Tue, Feb 5, 2013 at 8:14 PM, Murray S. Kucherawy <[email-masked]>wrote:

> On Tue, Feb 5, 2013 at 7:13 PM, Scott Kitterman <[email-masked]>wrote:
>
>> > > The difference is that the contents of the MX record are under
>> control of
>> > > the
>> > > many PTR, then that gives someone trying to avoid SPF fail an easy
>> way to
>> > > turn
>> > > > On Tue, Feb 5, 2013 at 9:06 AM, Scott Kitterman <[email-masked]
>> >
>> > >
>> > > wrote:
>> > > > > > fail. If anything, more than 10 PTR records should cause the
>> ptr:
>> > > > > mechanism
>> > > > >

---

From: "John Levine" <[email-masked]>
Date: 6 Feb 2013 04:29:34 -0000

>arbitrary, unless studies have shown that it's the best answer.

It's an interop issue.  If your limit is 10 and my limit is 15,
there's going to be mail where you'll get a permerror and I'll get a
pass or fail.

It's been 10 since forever, and it hasn't been a problem in practice.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 5 Feb 2013 21:09:37 -0800

Since the list of open issues has been seriously trimmed by someone since
SM posted this (only 16 left), I'll open a thread for each of the open ones
now with a comment on each based on the current draft version (-09).

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 01:31:37 -0500

> non-deterministic given that replies come back in a random order.  Are we

I see John Levine already answered the why 10 pat of the question.  Ignoring 
replies over 10 is the 4408 behavior, so we're making it deterministic for MX, 
because we can and leaving PTR as is because there's no better option 
available.  I'm not particularly OK with non-determinism for PTR, but I don't 
have a better idea.

I think your proposed text is good.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 02:01:30 -0500

...
> mechanism MUST produce a "permerror" result (see Section xxx).
...

What section is xxx meant to be?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 02:08:14 -0500

I adjusted a bit.  Here's what I have locally now:

> queried MUST NOT exceed 10.  If the evaluation of an "mx" mechanism
> results in more than 10 A resource records to be queried, the "mx"
> mechanism MUST produce a "permerror" result.
> 
> When evaluating the "ptr" mechanism or the %{p} macro, the number of
> PTR resource records queried MUST NOT exceed 10.  If the evaluation
> of a "ptr" mechanism results in more than 10 hostnames returned to
> be queried, all records other than the first 10 MUST be ignored.
> 
> The reason for the disparity is that the set of and contents of the
> MX record are under control of the domain owner, while the set of
> and contents of PTR records are under control of the owner of the IP
> address actually making the connection.
> 
> These limits are per mechanism or macro in the record, and are in
> addition to the lookup limits specified above.

Let me know if that works.

Scott K

On Tuesday, February 05, 2013 08:14:13 PM Murray S. Kucherawy wrote:
> > > On Tue, Feb 5, 2013 at 3:02 PM, Scott Kitterman <[email-masked]>
> > 
> > wrote:
> > > > > > > in section 4.6.4, there is a new requirement that there must not
> > 
> > be
> > 
> > > > more
> > > > 
> > > > > > > spammer could choose to send spam from a host with more than 10
> > 
> > PTR
> > 
ptr:
> > > > > > >  When evaluating the "mx" and "ptr" mechanisms, or the %{p}
> > 
> > macro,
> > 
> > > > > > > records are returned for this further lookup (either due to use
> > 
> > of
> > 
> > > > > > > a "ptr" mechanisms, or the %{p} macro) processing MUST be
> > 
> > terminated
> >

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 06 Feb 2013 02:13:50 -0500

On Thursday, January 31, 2013 06:02:53 AM S Moonesamy wrote:
> submit draft-ietf-spfbis-4408bis for publication in December
> 2012.  Here is the list of open issues [1]:
> 
> 1. http://trac.tools.ietf.org/wg/spfbis/trac/report/1

Quite a number of issues were not up to date in the tracker.  I've gone 
through and statused issues.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 06 Feb 2013 00:46:13 -0800

At 21:09 05-02-2013, Murray S. Kucherawy wrote:
>Since the list of open issues has been seriously trimmed by someone 
>since SM posted this
>  (only 16 left), I'll open a thread for each of the open ones now 
> with a comment on each based on the current draft version (-09).

The working group is making progress if open issues are 
resolved.  Thanks, Murray, for the separate threads.  It does make it 
easier for me to track the discussions.

A reading of the entire draft is needed at some point.  That could be 
done during the WGLC.  I have read all the comments posted by WG 
participants.  I may ask questions once in a while to understand the arguments.

Regards,
S. Moonesamy