ietf
[Top] [All Lists]

Re: Macro Expansion (was: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)

2013-09-18 13:20:56
Dear SM,

See comments inline.

On Sep 16, 2013, at 9:00 AM, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com> 
wrote:

Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
Add to:
11.5.3.  Macro Expansion
,---
It is not within SPF's purview whether IPv6 or DNSSEC is being used.  IPv6 
(RFC2460) increased the minimum MTU size to 1280 octets.  DNSSEC is deployed 
with EDNS0 (RFC6891) to avoid TCP fallback.  EDNS0 suggests an MTU increase 
between 1280 and 1410 octets offers a reasonable result starting from a 
request of 4096 octets.  A 1410 MTU offers a 2.4 times payload increase over 
the assumed MTU of 576 octets and is widely supported by Customer Premise 
Equipment.  With increased MTUs being used with DNS over UDP, network 
amplification concerns increase accordingly.

SPF macros can utilize SPF parameters derived from email messages that can 
modulate the names being queried in several ways without publishing 
additional DNS resources.  The SPF macro feature permits malefactors a means 
to covertly orchestrate directed DDoS attacks from an array of compromised 
systems while expending little of their own resources.

Since SPF does not make use of a dedicated resource record type or naming 
convention, this leaves few solutions available to DNS operations in 
offering a means to mitigate possible abuse.  This type of abuse becomes 
rather pernicious when used in conjunction with synthetic domains now 
popular for tracking users without using web cookies.

However, email providers can mitigate this type of abuse by ignoring SPF 
records containing macros.  Very few domains make use of macros, and 
ignoring these records result in neutral handling.  Some large providers 
have admitted they make use of this strategy without experiencing any 
notable problem.  AOL began their support of SPF by saying they would use 
SPF to construct whitelists prior to receipt of email.  Clearly, such 
whitelisting practices tends to preclude benefits derived from macro use.
'---

As background information I read draft-otis-spfbis-macros-nixed-01.  I read 
the messages where EDNS0 was mentioned [1].  I read the messages on the 
thread starting with msg-id: 
9884B9CD-0ED3-4D89-A100-58D05EA4BC98(_at_)gmail(_dot_)com.  I have followed 
the discussions about macros ever since the SPFBIS WG was chartered.

The above suggestion is to add text in the Security Considerations section of 
the draft.  The problem being pointed out is, in simple terms, DNS 
amplification.  The first (quoted) paragraph argues that there can be an 
acute problem because of EDNS0 as specified in the Internet Standard.

The second paragraph starts with SPF macros can utilize SPF parameters 
derived from email messages".  I do not understand that.  From what I 
understand the rest of the second (quoted) paragraph argues that the SPF 
macro feature permits evildoers to use it as an attack vector.

Since this was not understood, I'll attempt to clarify.  An effort to keep 
these conversations fairly concise seems to lead to a level of confusion with 
those not familiar with DNS.

DNS UDP traffic lacks congestion avoidance when used to covertly direct 
attacks.  Residential systems represent a large component of compromised 
systems involved with email although data centers measured by overall traffic 
is increasing.  Network amplification is measured by gains beyond exchanges 
initiating a higher volume of exchanges.  DNS caching tends to reduce 
subsequent exchanges.  SPFbis macros inhibit normal caching protections by 
imposing mechanisms not directly supported by DNS and having targets 
constructed from email message components.  SPFbis mechanism names can be 
misleading since they are given a related manipulated DNS resource name.  One 
SPFbis mechanism can represent more than 100 subsequent DNS transactions where 
normally resolving the resource would represent a single transaction.  
Publishing new targets within DNS resources to circumvent caching would 
normally be expensive and unlikely to provide remarkable gain.  SPFbis macros 
change this equation sig!
 nificantly.  SPFbis offers macros to translate code points, restructure host 
labels, build labels from the client IP address, make use of the local-part of 
the message return path or some label in the EHLO hostname, etc.

In other words, SPFbis macros permit malefactors a means to modulate the target 
of their queries while still leveraging their own cached DNS records.  This 
means a malefactors' DNS resources can be highly leveraged as a result of 
recipient SPFbis macro processing.  Secondly, SPFbis also ignores the overall 
size of the resources being queried in many cases.   The most egregious is 
perhaps that of the unlimited PTR RRsets which then results in a series of 
address RRset resolutions cascading down the hostname labels that happens for a 
maximum of 10 PTRs that might be offered on either a random or round robin 
basis.  It would be extremely difficult to determine the number of transactions 
and overall traffic volume any single PTR mechanism might impose, for example. 

The argument in the third (quoted) paragraph is that it is not possible to 
mitigate possible (DNS) abuse due to the SPF as it does not have a dedicated 
resource record type.

Or a naming convention that might support mitigation efforts.

The fourth (quoted) paragraph argues that macros should be ignored.  That 
paragraph also mentions that some large providers admitted to using that 
strategy.  I am not aware of any public reports about that.

As was said, AOL made their use of prefetching of SPF public at the beginning 
which precluded use of macros.  Others have also adopted this practice but have 
not made their use public.

I read draft-otis-spfbis-macros-nixed-01 again to try and understand the 
problem.  It seems to be the:

 '{%l}._spf.{%d} or exists:{%i}_spf.{%d} can  be used in "specialized"
  DNS servers able to understand encrypted local-parts'

There is nothing in SPFbis that limits the structured use of DNS resources.  In 
this example, it shows the expansion of the return path local-part, which 
represents a non-suspicious variable not derived from DNS, that can increase 
the leverage obtained in DNS related attacks.  A similar attack might 
manipulate HELO hostname or  MAIL FROM domain labels as well. 

which is discussed in Appendix E of draft-ietf-spfbis-4408bis-20.

Arthur Thisell commented about the "specialized DNS server".  He mentioned 
that at the time that text was written two people came forward to say that 
they were doing that.  During the SPFBIS discussions nobody stated that he or 
she has implemented or is using a "specialized" DNS server.

I'll ask the person editing draft-ietf-spfbis-4408bis or the SPFBIS WG to 
provide some publicly verifiable cases where these examples are used.

I assume that the SPFBIS WG and the Responsible Area Director have understood 
the mathematics relating to EDNS0 and DNS amplification.  Anyone who has not 
understood that part is welcome to raise the issue on the SPFBIS mailing list.

The discussion about the "dedicated resource record type" has led to 
agreement.  I'll describe the agreement as something people can live with.  
In my opinion it is better not to start another discussion about that.

I hope that what I wrote above clearly explains what I have understood and 
what I have not understood.

Regards,
S. Moonesamy (as document shepherd)

Regards,
Douglas Otis