Subject: Re: [spfbis] Barry Leiba's Discuss on draft-ietf-spfbis-4408bis-21: (with DISCUSS and COMMENT)

From: S Moonesamy <[email-masked]>
Date: Thu, 26 Sep 2013 08:05:01 -0700

Hi Barry,
At 07:37 26-09-2013, Barry Leiba wrote:
>Barry Leiba has entered the following ballot position for
>draft-ietf-spfbis-4408bis-21: Discuss

[snip]

>DISCUSS:
>----------------------------------------------------------------------
>
>UPDATED for -21: It seems that resolutions for the DISCUSS points got
>left out of the update.  :-(
>-------------------------------------------------------
>I have two very small points that I think are unclear, and important
>enough that we have to get them right, both regarding the check_host()
>function.  These should be really easy to clear up:
>
>-- Section 4.6 --
>
>    The check_host() function parses and interprets the SPF record to
>    find a result for the current test.  If there are any syntax errors
>    anywhere in the record, check_host() returns immediately with the
>    result "permerror", without further interpretation.
>
>I think you're trying to say that syntax checking is done before any
>evaluation, but you aren't saying it.  It matters, because
>implementations that make different choices in that regard won't get the
>same results from check_host() in all cases, as they're required to.
>Maybe this?:
>
>NEW
>    The check_host() function parses and interprets the SPF record to
>    find a result for the current test.  The syntax of the record is
>    validated first, and if there are any syntax errors anywhere in the
>    record, check_host() returns immediately with the result "permerror",
>    without further interpretation or evaluation.
>END

Scott Kitterman agreed to the proposed text previously ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html 
).  What follows is the change to address to DISCUSS:

OLD

    The check_host() function parses and interprets the SPF record to
    find a result for the current test.  If there are any syntax errors
    anywhere in the record, check_host() returns immediately with the
    result "permerror", without further interpretation.

END

NEW
    The check_host() function parses and interprets the SPF record to
    find a result for the current test.  The syntax of the record is
    validated first, and if there are any syntax errors anywhere in the
    record, check_host() returns immediately with the result "permerror",
    without further interpretation or evaluation.
END

>-- Section 5.5 --
>
>I have to say that I'm not happy about the pseudocode here: what
>situation are we in when the pseudocode differs from the text?  Which
>wins?
>
>I already see a case where they differ: the new pseudocode says "if more
>than 10 sending-domain_names are found, use at most 10", and there's
>nothing of the sort in the text.
>
>Does the working group really think there's enough value in having
>pseudocode there that it's worth saying the same thing twice and relying
>on them to be truly the same?  And is it really worth it for mechanism
>that's not recommended for use?
>
>I strongly suggest making sure that the text says what you want it to,
>and removing the pseudocode.

Scott Kitterman agreed that the pseudocode can be removed ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html 
).  The OLD text is below; there isn't any NEW text as it is a removal.

OLD

  Pseudocode:

    sending-domain_names := ptr_lookup(sending-host_IP);
    if more than 10 sending-domain_names are found, use at most 10.
    for each name in (sending-domain_names) {
      IP_addresses := a_lookup(name);
      if the sending-domain_IP is one of the IP_addresses {
        validated-sending-domain_names += name;
      }
    }

    for each name in (validated-sending-domain_names) {
      if name ends in <target-name>, return match.
      if name is <target-name>, return match.
    }
    return no-match.
END

Regards,
S. Moonesamy (as document shepherd)

---

From: Pete Resnick <[email-masked]>
Date: Thu, 26 Sep 2013 10:08:39 -0500

Thanks SM. I will put these in an RFC Editor Note so that Barry can clear.

pr

On 9/26/13 10:05 AM, S Moonesamy wrote:
> http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ).  
> What follows is the change to address to DISCUSS:
>
> OLD
>
> http://www.ietf.org/mail-archive/web/spfbis/current/msg04124.html ).  
> The OLD text is below; there isn't any NEW text as it is a removal.
>
> OLD
>
>  Pseudocode:
>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Hector Santos <[email-masked]>
Date: Thu, 26 Sep 2013 11:49:01 -0400

>     without further interpretation or evaluation.

For the record, our implementation does not have what is effectively 
described above as a two-pass parser.  IMO, it is technically a waste 
and not optimal in the long run (of continued operations) -- most 
records are not invalid.  And its also a implementation method, not 
required to be a two-pass parser.

Probably, what you mean with the second sentence:

     The syntax of a directive or mechanism is checked first. If
     there are any syntax errors, check_host() returns immediately
     with the result "permerror", without further interpretation
     or evaluation.

>       if name is <target-name>, return match.

hmmmm, to tell you the truth I though the "10" limit was on the number 
of total lookups, not in the the BUFFER storage restrictions on a PTR 
lookup.

I don't think you can tell DNS server "please only give me 10" PTR 
query records, so the overhead concern "to avoid unreasonable load on 
the DNS" stated in section 4.6.4 would not be correct.

However, there could be limits to save recursion stack limits if its 
not dynamically allocated implementation design.

Also more importantly,  if you need to single source the DNS API 
interface (for local caching designs) across different applications, I 
found it to be better to increase the potential records returned 
(allocate more space) otherwise you can get false positive/negative 
under SPF.   In fact, for historical reasons, our records for 
208.247.131.9 are 14 records.

M:\rfc\spf>nslookup -query=ptr 208.247.131.9

Non-authoritative answer:
9.131.247.208.in-addr.arpa      name = ntbbs.santronics.com
9.131.247.208.in-addr.arpa      name = mail.catinthebox.net
9.131.247.208.in-addr.arpa      name = ftp.catinthebox.net
9.131.247.208.in-addr.arpa      name = news.winserver.com
9.131.247.208.in-addr.arpa      name = listserv.winserver.com
9.131.247.208.in-addr.arpa      name = groups.winserver.com
9.131.247.208.in-addr.arpa      name = mail.santronics.com
9.131.247.208.in-addr.arpa      name = mail.winserver.com
9.131.247.208.in-addr.arpa      name = ntbbs.winserver.com
9.131.247.208.in-addr.arpa      name = winserver.com
9.131.247.208.in-addr.arpa      name = catinthebox.net
9.131.247.208.in-addr.arpa      name = secure.winserver.com
9.131.247.208.in-addr.arpa      name = pop3.winserver.com
9.131.247.208.in-addr.arpa      name = dkim.winserver.com

I'm sure we are not the only server with this historical layout.

I think don't the issue is related to the concept of deprecating PTR 
publishing. SPF MUST support the PTR logic. No parser can get around 
that complaint protocol design requirement.

But we can do is save the overhead and minimize wasted processing 
because SPF parser limited the PTR resultant record to 10.  In this 
case, allow implementators to set their own limits because a) we can 
afford it today, and b) there is no DNS concern in this regard (can't 
set a limit to 10 to query DNS).

I thought the "10 limit" was for total DNS queries.

-- 
HLS