Re: [dnsext] [spfbis] Sean Turner's No Objection on draft-ietf-spfbis-4408bis-19: (with COMMENT)

Dear  John,

See comments inline.

On Sep 12, 2013, at 8:02 AM, John Levine <johnl@taugh.com> wrote:

> I don't see anything about SPF that makes DNS spoofing more of a
> problem than any other DNS application, so I don't see why it needs
> another plug for DNSSEC.

For the record, I would like to strongly disagree with this statement.  SPFbis represents a significant change in how DNS and DNSSEC can be abused and network amplifications achieved.  

SPF introduces predefined "mechanisms" in conjunction with "macros" that operate on message elements rather than just DNS resources.  These "mechanisms" combine with "macros" (if actually implemented by large providers) to allow any compromised system to leverage cached Resource Records to induce recipients into making more than 222 uniquely directed DNS transactions derived from check_host() message elements (111 DNS transactions for each of the two SPFbis check_host() message elements).  NO MITIGATION of this type of threat is possible without ignoring SPFbis records containing "macros".  This mitigation remains practical only by email providers (not DNS operators) since only 0.00053 of the domains publish records with a "macro" feature.  

When DNSSEC is used, network amplification calculations change dramatically.  For example, the "PTR" or "MX" "mechanism" can be invoked 10 times where each instance can resolve addresses for 10 RRs.  For the PTR mechanism, each invocation is permitted to return any number of PTR RRs where the upper bound on the response size could be 8x larger.  While SPFbis recommends against their publication, there is no recommendation against these "mechanisms" being processed by recipients which is where the threat is realized.   The complexity is represented by the target modulation permitted by SPFbis "macros".  RFC4033 does not offer any mitigation for this type of threat which becomes significantly worse when the DNS Message constraint changes from 512 octets and each message can then cause 222 massive UDP DNS transactions against two likely unrelated names constructed by macro expansion that SPFbis recommends be resolved.

> On the other hand, it's not a big deal, if it'll make the discuss go away, that's fine.

I don't think any DNS abuse mitigation strategy would be effective against SPFbis misuse of DNS.  SPFbis offers unknown entities significant access to DNS resources that can not be blocked by BCP38, rate limiting, or even be identified by RR Type or naming convention.  Sending a 1KB message could result in network amplifications significantly greater than that provided by source address spoofing.  The reason this is not likely an issue is that providers are not processing SPF records that contain macros because they may prefetch SPF records as a means of whitelisting which precludes use of "macros".  If so, "macros" may introduce significant interchange issues.  Too bad no survey was made regarding the publication or the processing of SPFbis "macros". 

Regards,
Douglas Otis

>>>> ----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Should s11.3 also provide a mitigation via a reference for the spoofed
>>>> DNS?  Right now it just points to the DNS threats RFC.  I guess the
>>>> reader can infer they should use DNSSEC if they're worried but adding a
>>>> pointer to the right RFC would be better.  Something as simple as adding
>>>> "... and see [RFCXYZ] for a countermeasure" or something like that.
>>> 
>>> I'll suggest:
>>> 
>>>   and see RFC 4033 for a countermeasure.
>>> 
>>> and leave it to the SPFBIS WG to comment on the above.
>> 
>> That would work for me.
> _______________________________________________
> spfbis mailing list
> spfbis@ietf.org
> https://www.ietf.org/mailman/listinfo/spfbis