Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization

From: S Moonesamy <[email-masked]>
Date: Wed, 07 Mar 2012 15:10:51 -0800

At 13:04 07-02-2012, spfbis issue tracker wrote:
>#6: RFC 4408 Section 10.1 - Processing limits needs clarification and
>reorganization
>
>  Message from Scott Kitterman on 6 Feb 2012:
>
>  As I understand it, security considerations aren't generally supposed to
>  give
>  normative protocol implementations constraints, but the processing limits
>  in
>  paragraph 10.1 of RFC 4408 does exactly this.
>
>  While the technical limits themselves are appropriate, paragraph 10.1
>  should
>  be split into two parts.  The actual processing limits should find a home
>  in
>  the main body of the specification and then a revised security
>  consideration
>  should focus on a clearer discussion about why they are important and why
>  one
>  should design records the minimize DNS impact.
>
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00293.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/6>

I am opening Issue #6 in case it is related to the discussion of 
Issue #24.  Please comment on this issue.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 19:13:39 -0500

> >  Message from Scott Kitterman on 6 Feb 2012:
...
> Issue #24.  Please comment on this issue.

Here's what I had envisioned when I submitted this issue.

RFC 4408 paragraph 10.1 contains a mix of considerations and hard protocol 
requirements.  The protocol requirements should be moved up into the main part 
of the document from security considerations.  I would add the following facts 
(exact text there's no point in writing since we don't have a document to put 
it in - still) and whatever additional limits we determin are appropriate (irf 
any from the discussion of issue #24) into paragraph 4.6.  Either as part of a 
the main body of 4.6 or a new 4.6.1 that's before the current 4.6.1.

   SPF implementations MUST limit the number of mechanisms and modifiers
   that do DNS lookups to at most 10 per SPF check, including any
   lookups caused by the use of the "include" mechanism or the
   "redirect" modifier.  If this number is exceeded during a check, a
   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
   "exists" mechanisms as well as the "redirect" modifier do count
   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
   require DNS lookups and therefore do not count against this limit.
   The "exp" modifier does not count against this limit because the DNS
   lookup to fetch the explanation string occurs after the SPF record
   has been evaluated.

   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.

   MTAs or other processors MAY also impose a limit on the maximum
   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
   allow at least 20 seconds.  If such a limit is exceeded, the result
   of authorization SHOULD be "TempError".

The balance of 10.1 I would leave in security considerations. Text and 
clarifications TBD until we have a draft.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Mar 2012 00:36:25 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, March 07, 2012 4:14 PM
> To: [email-masked]
> Subject: Re: [spfbis] #6: RFC 4408 Section 10.1 - Processing limits needs clarification and reorganization
> 
> [...]
> 

That all seems reasonable to me, but we need to haggle about wording.  For example, the first paragraph's wording says more than ten can't be done.  That could be read as "pick your favourite ten" rather than "throw an error if there are more than ten".  The second paragraph seems to shift to talking about limiting the actual MX queries issued to the DNS, but isn't that the same as the number of MX mechanisms in the previous paragraph, where "mx" is excluded from the count?

But we can tackle later.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 19:49:24 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>That all seems reasonable to me, but we need to haggle about wording. 
>For example, the first paragraph's wording says more than ten can't be
>done.  That could be read as "pick your favourite ten" rather than
>"throw an error if there are more than ten".  The second paragraph
>seems to shift to talking about limiting the actual MX queries issued
>to the DNS, but isn't that the same as the number of MX mechanisms in
>the previous paragraph, where "mx" is excluded from the count?
>
>But we can tackle later.

Agreed. No point in it before there's a draft.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Mon, 12 Mar 2012 11:30:04 -0700

I'll attempt to summarize the discussion about Issue #6.  As usual, 
if I misunderstood or misinterpreted what you said, please let me know.

Issue #6 was raised by Scott Kitterman on February 6 [1].  In a 
message posted on March 8, he suggested that the protocol 
requirements should be moved up into the main part of the document 
from security considerations [2].  Murray Kucherawy agreed [3].

Regards
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00293.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00838.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00839.html