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

[Douglas Otis <[e-mail]>]

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

> 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.

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