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)

[S Moonesamy <[e-mail]>]

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: [e-mail].  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.

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.

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.

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'

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)

1. message-id of messages:

[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
1545953.Y9VaoKsXxF@scott-latitude-e6320
[e-mail]
1977893.MDoye0cYQa@scott-latitude-e6320
[e-mail]
3896517.k8tBVMT4Fi@scott-latitude-e6320
[e-mail]
[e-mail]
271785100.KEZggNLeh1@scott-latitude-e6320
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
[e-mail]
686233851.4iQopu4Yll@scott-latitude-e6320
24624534.FuUVENZpXd@scott-latitude-e6320
24624534.FuUVENZpXd@scott-latitude-e6320
[e-mail]
[e-mail]
5129719.PDZTiHcDZ6@scott-latitude-e6320
[e-mail]
38312086.HKzMeyOO04@scott-latitude-e6320
2137735.9LNiMWPY5V@scott-latitude-e6320