Subject: Re: [spfbis] draft-ietf-spfbis-4408bis-14

From: S Moonesamy <[email-masked]>
Date: Thu, 23 May 2013 10:01:02 -0700

Hi Phillip,
At 09:58 26-04-2013, Phillip Hallam-Baker wrote:
>The document is clear and describes the SPF mechanism effectively. 
>The only quibble that I could find is that repeated mentions are 
>made of limiting the number of 'DNS queries' without specifying 
>whether these are individual queries or recursive. The count will 
>come out rather differently if looking up TXT/x.example.com counts 
>as one lookup or three. I think it is reasonably clear that this is 
>one but could not find an explicit statement to that effect.
>
>On the security side, the document addresses all the mail issues 
>that I can remember at this point and rather more besides.
>
>I think we have reached the point of diminishing returns.
>
>The document provides a clear enough warning to people configuring 
>SPF records as to the consequences of getting it wrong which is the 
>main concern. The filtering services will know their business well 
>enough to minimize false positives.
>
>Hopefully the email infrastructure will evolve over time towards 
>concentrating on the more policy friendly approaches and it will be 
>possible to simplify the mechanism at a future date.

There are two comments about the security directorate review of 
draft-ietf-spfbis-4408bis-14 at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html

The SPFBIS WG does not plan to make any change to 
draft-ietf-spfbis-4408bis.  Please let me know if you consider that 
the security directorate review has not been addressed.

Regards,
S. Moonesamy (as document shepherd)

---

From: Douglas Otis <[email-masked]>
Date: Thu, 23 May 2013 11:58:17 -0700

On May 23, 2013, at 10:01 AM, S Moonesamy <[email-masked]> wrote:

>> The document is clear and describes the SPF mechanism effectively. The only quibble that I could find is that repeated mentions are made of limiting the number of 'DNS queries' without specifying whether these are individual queries or recursive. The count will come out rather differently if looking up TXT/x.example.com counts as one lookup or three. I think it is reasonably clear that this is one but could not find an explicit statement to that effect.
>> 
>> On the security side, the document addresses all the mail issues that I can remember at this point and rather more besides.
>> 
>> The document provides a clear enough warning to people configuring SPF records as to the consequences of getting it wrong which is the main concern. The filtering services will know their business well enough to minimize false positives.
>> 
>> Hopefully the email infrastructure will evolve over time towards concentrating on the more policy friendly approaches and it will be possible to simplify the mechanism at a future date.
> 
> There are two comments about the security directorate review of draft-ietf-spfbis-4408bis-14 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03723.html and http://www.ietf.org/mail-archive/web/spfbis/current/msg03726.html
> 
> The SPFBIS WG does not plan to make any change to draft-ietf-spfbis-4408bis.  Please let me know if you consider that the security directorate review has not been addressed.

Dear SM and Scott,

Greater clarity would have been achieved by separating transactions involving the SPF checkhost process (spfch-transactions) which may then generate some number of recursive dns server transactions (rdns-transactions).

A transaction made at the spfch level will result in some number of transactions at the rdns level, which could then be described as representing some number of separate DNS queries.

Confusion has been caused by conflating checkhost and recursive DNS transactions with that of non-recursive DNS which may involve dozens of unique queries to resolve any particular resource.  This is bad and is a continuing source of confusion.

A practical means to simplify SPF's impact on a receiver's DNS is to first ignore SPF records containing macro expressions.  This happens and this may explain the nearly 100% lack of macro use.  They then limit the number of SPF resource records and MX mechanisms and ignore the PTR mechanism.  Appreciate what receivers consider a reasonable demand on their resources that offers cache-able results.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 May 2013 12:14:32 -0700

Hi Doug,
At 11:58 23-05-2013, Douglas Otis wrote:
>Greater clarity would have been achieved by separating transactions 
>involving the SPF checkhost process (spfch-transactions) which may 
>then generate some number of recursive dns server transactions 
>(rdns-transactions).
>
>A transaction made at the spfch level will result in some number of 
>transactions at the rdns level, which could then be described as 
>representing some number of separate DNS queries.
>
>Confusion has been caused by conflating checkhost and recursive DNS 
>transactions with that of non-recursive DNS which may involve dozens 
>of unique queries to resolve any particular resource.  This is bad 
>and is a continuing source of confusion.

What I noted among other things in the review was "the only quibble" 
and "it is reasonably clear".

>A practical means to simplify SPF's impact on a receiver's DNS is to 
>first ignore SPF records containing macro expressions.  This happens 
>and this may explain the nearly 100% lack of macro use.  They then 
>limit the number of SPF resource records and MX mechanisms and 
>ignore the PTR mechanism.  Appreciate what receivers consider a 
>reasonable demand on their resources that offers cache-able results.

I don't see any relation between the security directorate review ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) 
to the above (quoted paragraph).  If the security directorate 
reviewer is of the opinion that it is related to his review I will 
ask the SPFBIS to comment about the matter.

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 24 May 2013 14:58:13 -0700

On May 23, 2013, at 12:14 PM, S Moonesamy <[email-masked]> wrote:

> What I noted among other things in the review was "the only quibble" and "it is reasonably clear".
> 
> I don't see any relation between the security directorate review ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html ) to the above (quoted paragraph).  If the security directorate reviewer is of the opinion that it is related to his review I will ask the SPFBIS to comment about the matter.

Dear SM,

SPFbis terminology conflates similar terms used in both recursive DNS and the pseudo check_host service indirectly defined in the SPFbis document. In addition, there appears to be a significant departure in processing of the EHLO domain in lieu of the RFC5321.MAILFROM.  SPFbis section 2.1states  "If a conclusive determination about the message can be made based on a check of HELO, then the use of DNS resources to process the typically more complex MAIL FROM can be avoided." 

This approach is at odds with a process proposed by draft-kucherawy-dmarc-base, section 4.3 "For example, [DKIM] authenticates the domain that affixed a signature to the message, while [SPF] authenticates either the domain that appears in then RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications).

Draft-kucherawy-dmarc-base already requires reprocessing message header stacks to exclude ONLY repeated From header fields.  It also suggests EHLO will be ignored and the RFC5321.MailFrom will still need to be processed.  This potentially doubles the load on DNS and offers poor protocol layering. If directed toward synthetic domains used to replace web cookies, the application of the new DNS Response Rate Limiting may prove problematic, in addition to an attack easily occurring from a myriad clients easily beyond prefix limits used to associate responses.  Although related to offering security, it seems highly improbable SPF can safely make use of DNSsec. 

It should also be noted that RFC6531 introduces character sets not handled by SPFbis since this also includes local-part components which may invoke handling errors since this introduces data not converted by RFC5890.  It should also be noted that use of macros still allows left-hand labels to take the place of randomized local-parts to leverage cached records while inducing different queries.

The only way SPFbis can be made reasonably safe would be to disable implementation of the macro functions by the receiver.  Since these macros are rarely used, this change would not impact the exchange of email.   Even now, senders making use of macros will see a greater impact with their SPF records being ignored as things currently stand.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 May 2013 02:52:01 -0700

Hi Doug,
At 14:58 24-05-2013, Douglas Otis wrote:
>This approach is at odds with a process proposed by 
>draft-kucherawy-dmarc-base, section 4.3 "For example, [DKIM] 
>authenticates the domain that affixed a signature to the message, 
>while [SPF] authenticates either the domain that appears in then 
>RFC5321.MailFrom portion of [SMTP] or the RFC5321.EHLO/HELO domain 
>if the RFC5321.MailFrom is null (in the case of Delivery Status Notifications).
>
>Draft-kucherawy-dmarc-base already requires reprocessing message 
>header stacks to exclude ONLY repeated From header fields.  It also 
>suggests EHLO will be ignored and the RFC5321.MailFrom will still 
>need to be processed.  This potentially doubles the load on DNS and 
>offers poor protocol layering. If directed toward synthetic domains 
>used to replace web cookies, the application of the new DNS Response 
>Rate Limiting may prove problematic, in addition to an attack easily 
>occurring from a myriad clients easily beyond prefix limits used to 
>associate responses.  Although related to offering security, it 
>seems highly improbable SPF can safely make use of DNSsec.

The above comment is about draft-kucherawy-dmarc-base.  The SPFBIS WG 
is not working on draft-kucherawy-dmarc-base.  I have not been asked 
to take that draft into consideration for the work being done in the SPFBIS WG.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 30 May 2013 16:00:40 -0400

My point was a quibble, no more. The intent was clear enough to me and it
is hard to imagine an implementer of code making a blunder if their code is
timing out too often on real records they will raise their limits. A person
writing records might however.

I can see that attempting to clarify this point might add more confusion as
John Levine pointed out. In fact that was the main concern I had with the
document as a whole. I think it is done as well as it is going to be at
this point.

On Thu, May 23, 2013 at 3:14 PM, S Moonesamy <[email-masked]> wrote:

>> involving the SPF checkhost process (spfch-transactions) which may then
>> generate some number of recursive dns server transactions
>> (rdns-transactions).
>>
>> transactions with that of non-recursive DNS which may involve dozens of
>> unique queries to resolve any particular resource.  This is bad and is a
>> continuing source of confusion.
>>
>
>> first ignore SPF records containing macro expressions.  This happens and
>> this may explain the nearly 100% lack of macro use.  They then limit the
>> number of SPF resource records and MX mechanisms and ignore the PTR
>> mechanism.  Appreciate what receivers consider a reasonable demand on their
>> resources that offers cache-able results.
>>
>
> http://www.ietf.org/mail-**archive/web/spfbis/current/**msg03679.html<http://www.ietf.org/mail-archive/web/spfbis/current/msg03679.html>) to the above (quoted paragraph).  If the security directorate reviewer is
> of the opinion that it is related to his review I will ask the SPFBIS to
> comment about the matter.
>
>
> Regards,

-- 
Website: http://hallambaker.com/