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

From: S Moonesamy <[email-masked]>
Date: Thu, 12 Sep 2013 01:46:01 -0700

Hi Doug,
At 21:55 11-09-2013, Douglas Otis wrote:
>Recommended text is as follows:

Thanks for suggesting text.  I'll take this up with the SPFBIS WG 
after the (IESG) DISCUSSes have been addressed.

Here are some quick comments.  Section 4.6.4 was reviewed again in 
response to the DISCUSS from Barry Leiba.  I will take the new 
changes into consideration when making a suggestion to the SPFBIS WG 
about that part of the draft.  I'll also review the text proposed in 
the message at 
http://www.ietf.org/mail-archive/web/ietf/current/msg82402.html 
before making that suggestion.

There were also some text clarifications to Section 5 in response to 
comments from Barry Leiba.  I'll see whether the addition of the one 
sentence which you propose fits in.

Some text was proposed to address the "DNS message" issue in Section 
3.4 ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg04104.html 
).  I'll use your suggestion and some of the other suggestions to get 
this issue resolved.

It is my understanding that you consider the "macro" issue (Section 
11.5.3 in the text which was proposed) as a major one.  The argument 
in your message starts with IPv6 or DNSSEC not being in the purview 
of draft-ietf-spfbis-4408bis.  It is followed by EDNS0 is used with 
DNSSEC, and there is a discussion about MTU after that.  The next 
paragraph starts with the argument that the SPF macro feature can be 
used for "attacks".  The proposed text then argues that SPF records 
containing macros are to be ignored to mitigate such an attack.  At 
the moment I do not know what I will suggest.  I welcome any new 
input from anyone who has not commented about the "macro" issue.

I suggest using the [email-masked] mailing list only for any 
follow-up about the above instead of copying the message to the [email-masked].

Regards,
S. Moonesamy (as document shepherd)

---

From: S Moonesamy <[email-masked]>
Date: Mon, 16 Sep 2013 09:00:22 -0700

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: [email-masked].  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,

1. message-id of messages:

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Sep 2013 11:20:17 -0700

Dear SM,

See comments inline.

On Sep 16, 2013, at 9:00 AM, S Moonesamy <[email-masked]> wrote:

>> 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: [email-masked].  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 significantly.  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:
> 

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. 

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

Regards,
Douglas Otis

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Sep 2013 13:49:52 -0500

Posting as the responsible AD for the document in question.

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

I'm afraid I'm going to have to end this thread here and now. The 
problem is not that Doug has tried to keep his explanations concise, or 
that people are not familiar with the DNS and therefore confused. The 
latter may or may not be true, but the problem here is precisely that 
Doug has failed to keep things concise and on point. This is not meant 
as an insult to Doug, and I apologize to him publicly just in case he 
feels offended. It is simply the fact that he is unable to clearly and 
concisely explain to others the security problem he believes exists in 
this protocol. For example:

> SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components.

Doug never explains in this sentence *what* the mechanisms are the 
SPFbis macros are using, he never explains *in what way* those 
mechanisms are not supported by the DNS, he never explains *how* use of 
these mechanisms inhibits caching, and never gives an example of *how* 
the targets (I presume attack targets) are constructed.

After a long conversation with Doug, I *think* I may understand what 
he's raising. I *suspect* the issue could be addressed by a sentence or 
two added to 11.5.3 or, more likely, to the third and fourth bullet of 
11.1. But I'm not sure, and even after that long conversation, I was 
unable to get a clean explanation of the problem or reasonable text for 
a solution.

So, barring further information, I am simply forced to say that Doug is 
going to be in the rough part of the consensus. If someone else thinks 
they will be able to clearly and concisely characterize the problem and 
propose some text, I welcome such suggestions, though I ask that you 
communicate first with the SPFBIS chairs and/or myself to make sure that 
we all understand the specifics. We are far past the point of 
diminishing returns now, and I do not wish further disruption to either 
the IETF list or the SPFBIS list on this topic.

Again, I intend no insult to Doug, and I again apologize to him for 
having to take this step publicly. I hope, if there is a problem here 
that needs to be noted, that Doug can work with someone else so that we 
can improve the document.

Thanks.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Stuart Gathman <[email-masked]>
Date: Wed, 18 Sep 2013 16:36:10 -0400

On 09/18/2013 02:49 PM, Pete Resnick wrote:
> problem is not that Doug has tried to keep his explanations concise, 
> or that people are not familiar with the DNS and therefore confused. 
> The latter may or may not be true, but the problem here is precisely 
> that Doug has failed to keep things concise and on point. This is not 
> meant as an insult to Doug, and I apologize to him publicly just in 
> case he feels offended. It is simply the fact that he is unable to 
> clearly and concisely explain to others the security problem he 
> believes exists in this protocol. For example:
>
>> SPFbis macros inhibit normal caching protections by imposing 
>> mechanisms not directly supported by DNS and having targets 
>> constructed from email message components.
>
> mechanisms are not supported by the DNS, he never explains *how* use 
> of these mechanisms inhibits caching, and never gives an example of 
> *how* the targets (I presume attack targets) are constructed.
>
Most macros are harmless, but the localpart macro is "constructed from 
email components" as is the helo macro.  In particular, a malicious 
sender can vary the localpart with every MAIL FROM on the same 
connection, causing a unique set of DNS lookups when SPF is checked.  
(The HELO can only be varied every connection.)

Of course, in real life, unless the malicious sender manages to actually 
send some mail (in which case the "amplification" aspect is moot), the 
IP is banned after a handful of attempts at such nonsense.

---

From: "John Levine" <[email-masked]>
Date: 18 Sep 2013 22:39:25 -0000

>(The HELO can only be varied every connection.)

Sheesh.  That's on a par with putting fake DKIM signatures with random
selectors on your spam.  Yes, it causes some DNS traffic, but there are
much easier ways to provoke DNS floods if that's what you want to do.

Enough, already.