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

[Douglas Otis <[e-mail]>]

On May 29, 2013, at 7:36 AM, John Leslie <[e-mail]> wrote:

> NB: I tend to take Doug seriously, and feel he deserves more that "We
> ignored him before: it's safe to ignore him again."
> 
> Douglas Otis <[e-mail]> wrote:
>> On May 28, 2013, at 2:15 PM, Murray S. Kucherawy <[e-mail]> wrote:
>> 
>>> Nixing macros based on non-use has already been debated at length,
>>> to the point of a low-level appeal, and it's been decided that
>>> they're staying.  There's no action for the WG here based on that
>>> argument.
> 
>   I am not willing to advocate their removal, but I think they deserve
> to move a goodly way on the path to deprecation.
> 
>   They are indeed used (rarely), and are useful for some purposes not
> particularly central to SPF. Forbidding their use in this SPFbis would
> be going too far IMHO.

Dear John,

The WG had little problem deprecating SPF Resource Records, which actually enjoyed greater and growing use.  Clearly, this WG is not vested in preserving DNS.

However, efforts expended in creating a DNS based macro language and associated compilers makes it difficult for those vested in SPF macros to admit failure.  Such reluctance is understandable.  Several of the macro mechanisms have been given a "do not use" designation.  Unfortunately, such advice does not go far enough since it offers receivers no protection who are then expected to compile and resolve scripts from unknown sources.  Since macros are actually more likely to interfere with acceptance, their use has become negligible where even publishing macros will not ensure interchange.

>   Nonetheless, they remain a path to magnification of DoS. IMHO, folks
> _will_ turn off SPF macro expansion when it becomes a common tactic for
> DoS. (It's particularly nasty in that the initial request is free: a
> simple TXT record in DNS for some quite unrelated domain can set off
> at least ten seemingly-random DNS queries.)

Correction: SPF can set off 100 seemingly random DNS queries. DoS may seem a minor concern compared to protecting server's resources from non-cachable DNS related overhead.  As such, some folks have already turned-off SPF macros.  The DoS issue may become more apparent when DNSsec is deployed to support DANE enabled StartTLS for SMTP while coping with IPv6.  

SPF does not support RFC6532 internationalized email, nor does suggesting RFC5890 in the specification properly deal with many possible security issues.  The SPF macro compiler will be dealing with non-ASCII strings that may occur within local-part parameters never intended to be DNS compliant, in addition to non-A-Label DNS.  It only requires a single buffer overrun to compromise an SMTP server.  It seems negligent to run SPF scripts outside of a sandbox when making substantial changes to basic SPF macro compiler inputs.  

>   I quite agree it hasn't happened yet, and it doesn't seem likely to
> happen in the next year or two. Nonetheless, it's there for the taking,
> and it could become popular on rather short notice.
> 
>> A pertinent point regarding the decision that receivers must process
>> macros is whether it represents a reasonable demand.
> 
>   "MUST process" strikes me as less than reasonable. The benefit to
> the receiver which processes them is minuscule. The benefit to the
> domain which publishes them can mostly be accomplished in a cheaper
> way, and for the bulk of the other cases statistical sampling would
> accomplish essentially as much: processing them for one case out of
> a hundred would serve _very_ nicely.

Agreed, and it only requires a few large providers to also reach this conclusion for macros to then break interchange...

>> SPF records containing macros can not cache results and will always
>> necessitate reprocessing.
> 
>   (I don't understand Doug's point here either.)

When inputs into the SPF process include message elements beyond related domains,  re-executing the entire SPF process is the only compliant method.  If the SPF process were limited to just the related domain, then results could be cached by domain.  SPF macros may introduce label and local-part components that remove possible 1:1 domain/result relationships.   A 1:1 domain/result  relationship is restored when SPF macros are ignored.  Ignoring these macros convey many benefits to receivers and was asserted by AOL at the onset of SPF.

>> If macro processing is skipped, any expectation of preserving
>> interchange is lost. In other words, it is broken by design by
>> asking too much from receivers.
> 
>   I do agree it asks too much of receivers.
> 
>>> Beyond that, I disagree that macros "diminish" SPF's utility in
>>> any way; their mere presence in the protocol doesn't render it
>>> less useful, as one may simply not use them and still get useful
>>> results.
> 
>   Which is observed in the wild...
>> When the main purported use is to determine a domain's outbound
>> IP addresses, macros preclude this prevalent use offering the
>> greatest utility, bar none.
> 
>   (I don't understand that sentence either.)

The greatest utility expressed by providers for SPF (which may list MX or hostname resources or simply offer CIDR notation) is to determine a domain's outbound address space.  Comparing this list against reputation services quickly ascertains potential problems.

When macros are used, ascertaining a domain's outbound address space can not be determined without also processing SPF macros in conjunction with message derived elements acting as inputs.  Use of macros can easily destroy this utility by introducing indeterminate unknowns, such as the IP addresses of the client, or some portion of the local-part. These elements may depend on indeterminately placed exists() resources.

>>> I would argue that DMARC, which makes use of SPF in a specific way,
>>> should not influence SPF itself at this point as DMARC has no
>>> particular status with the IETF yet.
> 
>   DMARC is heading toward an IETF status, though it seems premature
> to react to it at this time.

A processing priority conflict will require revisiting SPF processing with different inputs more than once.  An inability to cache results against domains places greater emphasis on a need to immediately deprecate macros.  Now is the time for macro deprecation in all its aspects.

>> DMARC does not differ in how many hoped to make use of SPF.
>> Desired use is very much at odds with stated SPF processing which
>> is likely to require subsequent reprocessing, with increased burdens
>> and layer violations.   
>> 
>>> The dropping of type 99 RRTYPE support was made for more reasons
>>> than just "sparse use"...
> 
>   I'll not take that bait!
> 
>>> The local-part macro attack has been discussed to death.
> 
>   Well, to exhaustion anyway...
> 
>>> There's no new information presented here that I can see.
> 
>   I must admit I saw nothing to change my mind on that; but before
> Doug's recent posts I already strongly believed that SPF macros deserve
> a path towards deprecation.

Agreed.  The path offered by the WG does not protect receivers or ensure interchange primarily due to survey oversights, IMHO. 

>>> Saying RFC6686 "failed to provide a breakdown on macro use" is to
>>> imply that it should have...
> 
>   I have no opinion on that.

Perhaps I should have said omitted any consideration of macro use, although oddly the same survey concluded that SPF RR types should be deprecated, without also noting an even greater disparity in macro publication.

>> IMHO, it was wrong (a failing) to limit a review of SPF to answer only
>> whether the PRA mode was being used...
> 
>   No opinion on that either...
> 
>>> The document mentions use of macros given the advent of EAI, but I
>>> believe the current spfbis document already deals with this in the
>>> same way DKIM did...
> 
>   EAI is a minefield for DNS -- but is no worse for SPF.

How will a new reference to RFC5890 ensure security is retained?  How will SPF macro compilers handle new inputs?  

>> It can no longer be assumed domains will be encoded as A-labels...
> 
>   Alas, true; but again no worse for SPF than most other uses.

The impact might be something fairly minor.  An encoding that expands differently in some library sub-component that then allows an SMTP server to be compromised.  How will this play with existing libraries, and how will this operate in conjunction with new changes?  Is it really safe to assume there will not be any problem?

As a side note, the macros-nixed I-D was made available earlier, but SM wanted to delay its review until after the WG concluded its revision process.  After all, there was every reason to believe the related concerns would be casually dismissed by the WG.  I'll make a few more changes to address some of the expressed confusion.

Any input or criticism either on or off the list is most welcome.  Thank you.

Regards,
Douglas Otis