Subject: [dnsop] Doug's attack scenarios without SPF

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 13 Nov 2006 14:01:57 -0800 (PST)

[This email explains on scenario for what could be called 'NXDOMAIN'
  DNS DoS which Doug tried to use in his FUD campaign against SPF
  (I'll comment on that in next email). This is mostly same message
  as I posted on MXCOMP (former MARID mail list) on Friday:
   http://www.imc.org/ietf-mxcomp/mail-archive/msg05839.html]

Hi,

While Doug has particular issue with SPF, the problem he points to has
little to do with SPF. In fact the attack is general dns attack that will 
work with several other records (MX, SRV, NS, most likely PTR and NAPTR 
and possibly CNAME [John Levine suggested it, but I don't immediately see 
using it by  itself]). The issue is that certain applications (including 
DNS resolver itself) by means of special DNS records can be directed to 
do several additional lookups. The idea of the attack here is to direct 
those lookups to somebody else who would have to answer that it does not 
know about this name. Those answers if original name is large can 
themselves be quite large so you get amplification even though the
answer is NXDOMAIN or similar.

Specially for Doug I'm going to give example of using NS and EHLO for 
this attack, at the end I'll also explain why CSV (Doug's alternative
to SPF) is even better case for launching such an attack.

Lets assume that an attacker controls domain big.bad.domain.example.net
(for good amplification the name needs to be pretty long; for better
view in email post I'm not doing it). He sends email with SMTP session 
starting as
   EHLO big.bad.example.net
and he previously set up the following in DNS:
  $ORIGIN bad.domain.example.net
    big IN NS victim-dns1.example.com
    big IN NS victim-dns2.example.com
    big IN NS victim-dns3.example.com
    big IN NS victim-dns4.example.com
    big IN NS victim-dns5.example.com
    big IN NS victim-dns6.example.com
    big IN NS victim-dns7.example.com
    big IN NS victim-dns8.example.com
(if victim does not have enough dns servers, it can actually be done so
as to direct attack against the same server - its more complex and
I don't want to go into it right now)

Now lets assume that as per Doug's scenario the email is sent using botnet
to many mail servers and we'll assume that those email servers are going 
to try to resolve EHLO name (some would some would not - both CSV and 
SPF would require it but many mail servers & anti-spam filters do it 
without that too). Now what happens is that each mail server that received 
the email would try to resolve big.bad.domain.example.net and as part
of that would come to bad.domain.example.net and would be by means of
NS directed to victim DNS servers. Victim servers would each answer
that they are non-authoritative but would have to include large domain
(imagine big.bad.example.com being close to maximum DNS label size)
and that is where amplification comes from,  i.e. the attacker only 
responded with one packet which include 'big.bad.example.com' once in 
that packet and smaller size names of victim dns servers (which since
NS supports label compression can be quite compact) where as the
response include that entire large name ('big.bad.example.com') and
comes from each and every NS server listed. The above attack can be 
architected to be better then more typical 10:1 with certain additional 
tricks and provided that email server and victim's dns servers are on 
good network connection (most resolvers have no limit as to how many NS 
they would check - they do usually have timeout though so how well it 
would work would depend on network connection and timeout settings).

Now I promised to explain why CSV makes it easy and is worse then SPF.
That is due to the suggestion of having to walk the dns tree (up to
6 levels deep) which CSV specification has. Lets imagine that EHLO name
is actually bad1.bad2.bad3.bad4.example.com. What happens is that CSV
specifies to do lookups first to
  _client._smtp.bad1.bad2.bad3.bad4.example.com.
Using above system you cause multiple lookups due to lame delegation
that can be setup with "_client._smtp NS .." at zone
bad1.bad2.bad3.bad4.examp.e.com that cause victims to respond they
don't know  how to find_client._smtp.bad1.bad2.bad3.bad4.example.com. 
Next per CSV (as far as I understood), the application would have to try
  _client._smtp.bad2.bad3.bad4.example.com
and similarly attacker can setup lame delegation but this time at 
bad2.bad3.bad4.example.com zone. So this way you can easily cause
many lookups for the same email session from  the same system  - that
is why it is worse then with SPF. But in reality if you  look into it 
deeper, the actual amplification factor would be the same as in all
those cases servers do one lookup for bad?.example.com that cause to
happen 10x responses. It is exactly the same with SPF but in that case 
Doug has used mx operator - he causes requests for MX hosted at attacker 
side and several requests from victim for addresses pointed out but MX. 
This all comes down to something like 10 amplification factor and not
100 or more like Doug says.

Again this is general issue that can be replicated using different DNS
records - its cause is that several DNS record types cause application
(or dns resolver) to do additional lookups to list of names specified
in that record [and SPF is not something new to this field, nor is it 
some type of script like Doug says]. Another example of the same issue
is when you send email such that it would bounce (you can do it although
nowdays email systems are smarter) and you setup bad MX (like Doug did)
which  would cause lookups to victim. It would be the same type of attack 
and amplification. I can provide several more examples (email offers 
great choices since anti-spam systems do a lot of lookups when trying to 
decide if its good or bad email and if you use lots of domains for 
various victims like in URL then you often cause some type of lookup
to find if that name exists) as well as examples in non-SMTP field
(SNMP and SIP both can be vulnerable to it to some degree).

I hope this helped you all to understand this attack scenarios.

-- 
William Leibzon
Elan Networks
[email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Nov 2006 17:37:02 -0500

>  DNS DoS which Doug tried to use in his FUD campaign against SPF

Just like in the meeting, I think many of us do not want to spend a
great deal of time exploring all the nooks and crannies of some other
working group's rathole.  It is not even interesting to me whether
SPF is or is not the primary method by which these attacks can be
performed.  So I ask, as I did last Friday, a question in response to
the general issue:

> do several additional lookups. 

I still have no idea, from any of the SPF-blahblah discussion here,
whether there is anything at all that this group needs to do about
the problem.  As nearly as I can see, there are a few possible
answers.  None of the following are positions I'm adopting; I'm just
trying to figure out what questions, if any, to ask.  Also, I bet
this list isn't exhaustive:

1.	Sort of.  There is a DNS problem.  We need to define what that
problem is and what the operational impact might be; but if there is
a protocol problem, we have to ask dnsext to take it up as a work
item.

2.	Yes.  The general topic of DNS-using attacks is a work item
that the group needs to take up.

3.	No.  This is a problem that people have pointed out more than
once when others decided to start loading up the DNS with all these
other kinds of records, and the consequences are here as predicted. 
Since everyone knew this was going to happen, we have nothing to say
about it now.

4.	Yes, but in a limited way.  Some attacks are worse than
others, and each attack type should be evaluated case-by-case, so
that the group can decide whether it is worth investigating.  

5.	No.  This is a topic better handled in operator group forums
like NANOG, RIPE, APNIC, and even OARC, rather than here.

I lean towards (1) or (2) myself, but I can't say I have anything
like a well-formed view on this stuff, so I'd like to hear the views
of others as to what, if anything, to do about these kinds of
attacks.  I pray that we can keep particular examples out of it, but
I suspect we can't.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 13 Nov 2006 22:15:07 -0800

> a protocol problem, we have to ask dnsext to take it up as a work

There is a general threat to DNS created by an experimental email script
contained within DNS records.  This script may initiate more than 100
crafted DNS transactions directed toward any victim domain.  Crafting
these transactions can utilize the local-part of an email-address as
variable domain labels.  This script is executed when receiving spam
without consuming additional resources of an attacker, once a local
resolver is seeded.  The source of the attack can not be discerned, and
the attack is virtually free.  DNS ACLs or BCP 38 will not prevent this
attack.

The amplification of this SPF script attack can exceed that of a DNS
reflective attack utilizing spoofed sources and EDNS0.  The
amplification of an SPF script could be 64 kBytes per execution or 64:0
where zero represents a message that would be sent anyway.      

This threat is demonstrated by an example script along with a captured
trace from a distributed routine in compliance with experimental
RFC4408.  The example script and the trace can be found within the
appendix of the paper explaining the concern.  William continues to
overlook additional DNS transactions resolving address records from
different domains.  10 mechanisms where each resolves 10 address records
initiates 100 directed transactions per SPF script execution.  The math
is 10 times 10 equals 100.  In addition, the script might be executed
several times per message.

William suggests any transaction in response to a client might lead to a
DoS exploit.  His suggested exploit scenario is caused by chaining a
sequence of victim NS records that do not answer for the questioned
domain.  His issue only distracts from the SPF concern.  Any remedy to
resolve an NS chaining exploit raised by William, if there is an
exploit, is completely orthogonal to the problem raised by the SPF
script.

Transactions initiated by each SPF script's execution can be within 100
different domains and may occur several times per message.  NS chaining
would further exacerbate the amplification caused a DNS transaction for
different domains.  William's suggestion that DNS transactions can also
be amplified by such techniques only strengthens concerns regarding the
number of transactions initiated by SPF scripts.

Without other defensive strategies, blocking records that enable
dangerous script execution is the only viable solution.  The level of a
potential attack can bring down any domain.  The ability to craft an
assortment of labels accessing many and various record types at no cost
to the attacker makes SPF scripts dangerous and inviting.  This WG
should be able to express meaningful concerns about the state of this
experimental RFC.

-Doug

.

---

From: Andras Salamon <[email-masked]>
Date: Tue, 14 Nov 2006 10:33:45 +0000

On Mon, Nov 13, 2006 at 10:15:07PM -0800, Douglas Otis wrote:
> contained within DNS records.

As far as I understand, the attack vector relies on some process
outside the DNS retrieving, interpreting and acting on records
contained in the DNS.  Is this correct?  If so, my feeling is the SPF
folks should revise their protocol.  Perhaps it isn't altogether a
good idea to make protocols general enough to be near-Turing-complete
for the sake of data compression.

However, please clarify why a DNS working group should take
responsibility for fixing the semantics of data people choose to
put into the DNS.  People bringing down parts of the DNS through
DOS attacks is hardly new.  Storing the semantics of the attack
into the DNS itself is cute but hardly a cause for action by a DNS
working group.

Finally, if such a protocol (experimental, right?) were to start being
deployed, it would likely destroy its own ecology, so I don't see it
lasting long in an environment of cautious network operators.

-- Andras Salamon                   [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Nov 2006 10:00:01 -0500

> exploit, is completely orthogonal to the problem raised by the SPF

Well, maybe.  I'm not sure this conclusion follows from what you said,
actually, because it seems to me that the _kind_ of vulnerability
would be the same in any case.  This is what I took Olaf Kolkman to
mean when he said that this is an architectural issue (I'm sure he'll
correct me if I misunderstood).

> should be able to express meaningful concerns about the state of this

So, if I understand correctly, the last sentence there is what your
response is to my question?  If so, it seems to represent a different
answer than any of the candidate ones I proposed.  This one, if I
read you right, is

6.	There is a specific issue here, and it needs to be addressed
in the particular case, and not the general one.

Is that correct?

A

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Nov 2006 08:00:10 -0800

On Tue, 2006-11-14 at 10:33 +0000, Andras Salamon wrote:
> > There is a general threat to DNS created by an experimental email 
> > script contained within DNS records.
> 
> contained in the DNS.  Is this correct?

Yes.

> If so, my feeling is the SPF folks should revise their protocol.
> Perhaps it isn't altogether a good idea to make protocols general
> enough to be near-Turing-complete for the sake of data compression.

The SPF script language does not improve data compression.  APL RR
(RFC3123) provides 10 times the informational density and existed prior
to SPF development.  Parameters added as arguments to this script
necessitate repeated execution, even when resolving from the same
domain.  State-full processing of many scripted transactions also likely
leads to common multiplexing ports.  Execution of DNS related script
from unknown entities represents a breach in network security. 

> lasting long in an environment of cautious network operators.

Although SPF is experimental, it is being heavily promoted for use with
Sender-ID.  SPF is at about 30% adoption by the largest corporations
which represents 10 times the typical level of adoption!  Running with
the big dogs, few seem to notice the RFC is experimental, nor is this
mentioned in promotional material.

This script can be aimed at poisoning DNS, as the language can
repeatedly query resources of various record types while flash flooding
authoritative DNS.  Scripted execution may happen at MTAs and at the
desktop of email recipients.  DNS is at risk, but attacks can be highly
targeted and devastating.  Being highly targeted, this retains the
ecology providing the attack vector.  It is fallacious to suggest the
network is protected by the self interests of the bad actor.

-Doug

.

---

From: wayne <[email-masked]>
Date: Tue, 14 Nov 2006 12:03:27 -0600

[Note: I sent this reply yesterday, but I don't think it ever made it
to the list, sorry if it is a dup.  I've long read this list via
gmane.org, but apparently I've never posted here before and apparently
this list doesn't like posts via gmane.]

In <[email-masked]> Andrew Sullivan <[email-masked]> writes:

> working group's rathole.

I can certainly understand that.

For what it is worth, I did read the jabber session and also DougO's
slides.  However, the audio of the session was cut off about 10
minutes into Doug's presentation.  I've asked if the full presentation
was around and was told it would be there "shortly", but that was last
Saturday.

(I'm interested in hearing DaveC's presentation also...)

> answers.

Does this have anything to do with the "yes - no - yes - no - yes "
comment in the jabber session?

Anyway, as WilliamL said, there are a lot of assumptions in the SPF
DoS scenario that Doug presented that are, uh, "unlikely".  I analyzed
the same attack that was presented at IETF67 back in early 2004, along
with about a half dozen others.  I still believe that SPF is
relatively safe and the chances that anyone could regularly pull off
such a DoS attack are about the same as the chances of anyone
regularly winning the lottery.

There are some DNS operation issues that may be useful to consider for
SPF DoS attacks or the NS record DoS attack that William talked about.

In both cases, there is a requirement that the nTTL of the victim's
zone be much much shorter than the TTL of the attacker's records.
Fairly obvious ways to stunt any attack that is in progress include
updating the victim's SOA record so that the nTTL is much longer,
publishing a wildcard record so that the victim's TTL is used, or
delegate the part of the victim's zone that is being attacked to a
very slow name server.

More general solutions are to make sure that all protocols that use
DNS records that allow for indirection (NS, MX, SPF, SRV, etc.) to
limit the number of records that they process.  As William mentioned,
I put a limit of 10 in the SPF RFC.  This may really be a DNSEXT
issue, I'm not certain.

One suggestion, brought up by another person on the SPF lists, was that
SPF should also have a limit on the total number of "broken" indirects
before giving up.  A small limit of 2 or 3 would completely defeat all
the SPF DoS scenarios that I know of.

You can't just give up after the first bogus MX record.  Too many
people have a broken MX records that they think is acting as a
secondary/fallback MX, but since everything works fine with only the
primary MX they don't realize that anything is really wrong.  The same
thing goes for people with lame delegations.  Most people don't have
more than one or two lame namesevers, but unfortunately, all too many
have at least one.

Similar limits on the number of "broken" records that can be tolerated
could (should?) be put into things like resolvers checking NS records,
mail servers checking MX records, jabber clients that use SRV, etc. to
prevent them from being used as attack vectors.  Again, this may be an
issue best addressed in the DNSEXT WG, I'm not sure.

Anyway, sorry to hear that things got a little heated at the IETF67
meeting.  DougO has been on a grand crusade to stop SPF and to promote
his own replacements for many years now.  Some of us are more than a
little tired of it.  If he was more interested in fixing things, it
would be real nice.

-wayne

.

---

From: wayne <[email-masked]>
Date: Tue, 14 Nov 2006 12:16:12 -0600

In <[email-masked]> Douglas Otis <[email-masked]> writes:

> to SPF development.

*sigh*

Where do you get this "10 times" claim from?

To represent an IPv4 address:

APL entries require 16 + 8 + 1 + 7 + 32 = 64 bits or 8 bytes

SPF ip4: mechanism require from 12 to 23 bytes, depending on the
decimal digits and if CIDR notation is used.

That is *AT MOST* a factor of less than 3.

For IPv6 addresses the difference is even less.

Come on Doug.  Like this highly exaggerated SPF DoS potential, I did
testing back in early 2004.  Very compact, binary encoded SPF records
are rarely less than half the size of the text versions.

The RMX proposal used APL records.  It went no where.  There are good
reasons why.  I'll spare this list a rehash of the thousands of posts
from the IRTF ASRG WG, SPF-discuss and the IETF MARID WG mailing lists.

-wayne
.

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Nov 2006 10:13:08 -0800 (PST)

[I'll not be answering Doug directly. Mainly because if I start doing
  it, we'll continue forever as Doug would never stop (his arguments
  would still be same and not clear) and result is likely that most
  folks would locally blacklist both of us...]

On Tue, 14 Nov 2006, Andrew Sullivan wrote:

> would be the same in any case.

I'd suggest is that people read Doug's draft but try to ignore all
the craft about SPF being all bad and Doug's solutions being answer
and just focus on DNS. What you'll find in the end is that he presents
exactly the same scenario as I described with NS where the DoS is due
to NXDOMAIN and amplification due to using long domain name. What you'll
also find is that there is no 10x10 but that for each extra MX to be 
resolved you actually need to send requests to attacker's server.

Also the attack has little to do with size of SPF record (or that some 
think its near turing-complete; if it were the attack issue would be
how to cause somebody long processing & loops), its primarily using 
large domain itself as an amplification due to the same domain having
to be present in QUERY and NXDOMAIN answer.

> This is what I took Olaf Kolkman to mean when he said that this is an 
> architectural issue (I'm sure he'll correct me if I misunderstood).

This issue that is present in DNS and has been from the start, its both
an issue for resolver and for applications that use certain records.
I'm not entirely sure how it should be addressed (if at all - this
all is purely theoretical right now) - in general or at applications
that use their specialized records.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Nov 2006 23:37:03 -0800

> regularly winning the lottery.

Nothing suggests "chance" is involved with an attack enabled by SPF
scripts.  The example attack requires little knowledge of the victim.
Using SPF to include local-part email-addresses in queries to an
attacker's DNS permits canvassing when efficiency is desired.  However,
little of an attacker's resources are consumed when the repeat interval
is not optimized.

> delegate the part of the victim's zone that is being attacked to a

Extending negative caching may not be controlled by the victim and could
create problems during transitions.  Many wrongly suggest turning off
negative caching to avoid support issues.  Even with the level of
amplification reduced, the source of this attack remains hidden and can
continue without recourse.

> I put a limit of 10 in the SPF RFC.  This may really be a DNSEXT

The limit of 10 is with respect to a "mechanism" where 10 is also
suggested as a maximum number of host names resolved from the MX record
transaction.  Reducing the number of host names resolved creates
intermittent problems when there are more published without truncation,
but are ignored anyway by the script.

> the SPF DoS scenarios that I know of.

When will SPF routines be updated?  Forcing this change requires
modifying the version of the SPF record.  There is still wildcard SPF
RRs that can be randomized using local-part address macros.  SPF still
chains through 11 such resource records where this attack can be further
amplified by the tricks suggested by William.  Keep in mind these
attacks are still free for the attacker, and are not a matter of chance.

-Doug

.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Nov 2006 23:37:15 -0800

> Where do you get this "10 times" claim from?

Don't ignore the overhead added to SPF scripts, such as various tags and
record chaining.  CIDRs listed in 10 chained TXT resource records used
by Paypal.com can be accomplished within a single APL RR, for example.

-Doug

.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Nov 2006 06:09:02 -0800

On Tue, 2006-11-14 at 10:13 -0800, william(at)elan.net wrote:

> What you'll also find is that there is no 10x10 but that for each
> extra MX to be resolved you actually need to send requests to
> attacker's server.

A crafted MX response can reduce the size coming from the attacker. The
attacker also benefits from the difference between a negative caching
interval and that of their MX record TTL.  The number per hour needed in
a sustained attack at each Bot will not require many MX records to span
a negative caching interval.  Once the MX records are seeded in local
resolvers, only the 100 address record transactions per script execution
will not have been cached.

> to be present in QUERY and NXDOMAIN answer.

You are describing a technique where the SPF attack amplification is
increased!  The number of NS records is likely subject to truncation,
however a small SPF script still permits 100 victim transactions per
execution plus a number of NS record chaining as described! This only
increases the impact of an SPF attack!  Certainly this does not dismiss
SPF as being a significant concern.

> an issue for resolver and for applications that use certain records.

While there has always been some amplification possible with DNS, SPF
scripts greatly extend this risk due to the 100 directed transactions
per script execution.  Execution of an SPF script might occur many times
per message.  Adding '+all' at the end of the SPF script ensures a PASS
result without address records being returned.

> that use their specialized records.

The deployment of routines that execute SPF scripts in the manner
described is not theoretical.  Whether these routines stage an attack is
conjecture. Recognizing when this occurs will be difficult.  A remedy
likely requires the concerted blocking of SPF records.

-Doug

.

---

From: wayne <[email-masked]>
Date: Wed, 15 Nov 2006 09:48:40 -0600

*sigh*

let's check your claim about paypal.com that paypal.com can use a
single APL RR, apparently that backs up your claim that APL records
are *ten times* as short as SPF records.

OK, so let's get a list of all IP blocks that paypal currently
publishes: 

(wayne@footbone) $ spfquery -debug -ip=1.2.3.4 -helo=paypal.com 2>&1 | grep ip_match | wc -l
59

huh...  paypal.com's SPF record encodes 59 different IP blocks.  So,
an APL record will need about 59*8=472 bytes. Will this fit in a UDP
packet?

spfquery -debug -ip=1.2.3.4 -helo=paypal.com 2>&1 | grep ip_match | sed 's;.* == \([0-9.]*\)  (\(/[0-9]*\) [0-9.]*):.*;1:\1\2;' | tr '\n' ' ' | sed -e 's/^/_apltest.schlit.net. APL /' -e 's/ $/\n/'
_apltest.schlitt.net. APL 1:64.4.240.75/32 1:64.4.240.74/32 1:64.4.244.74/32 1:66.135.209.192/27 1:66.135.197.0/27 1:64.4.240.64/27 1:64.4.244.64/27 1:66.135.215.224/27 1:216.33.244.96/27 1:216.33.244.84/32 1:67.72.99.26/32 1:206.165.246.83/32 1:206.165.246.84/32 1:206.165.246.85/32 1:206.165.246.86/32 1:64.127.115.252/32 1:194.64.234.129/27 1:65.110.161.77/32 1:204.13.11.49/32 1:204.13.11.51/32 1:12.155.144.75/32 1:62.22.61.131/32 1:63.104.149.126/32 1:64.68.79.253/32 1:64.94.204.222/32 1:66.135.215.134/32 1:67.72.12.29/32 1:80.93.9.10/32 1:195.234.136.12/32 1:203.49.69.114/32 1:209.63.28.11/32 1:210.80.80.136/32 1:212.110.10.2/32 1:212.147.136.123/32 1:213.219.8.227/32 1:216.113.168.128/32 1:216.113.175.128/32 1:216.177.178.3/32 1:217.149.33.234/32 1:220.248.6.124/32 1:67.72.12.30/32 1:216.113.188.112/32 1:80.66.137.58/32 1:212.208.64.34/32 1:216.113.188.96/32 1:216.33.244.6/32 1:216.33.244.7/32 1:63.80.14.17/32 1:216.113.188.96/32 1:216.113.188.112/32 1:66.211.168.230/32 !
 1:66.211.168.231/32 1:64.4.240.67/32 1:64.4.240.73/32 1:64.4.240.75/32 1:64.4.244.69/32 1:64.4.244.74/32 1:64.4.244.75/32 1:64.4.240.74/32

(wayne@footbone) $ dig _apltest.schlitt.net apl | head -3
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.3.2-P1 <<>> _apltest.schlitt.net apl

Nope.  paypal.com can not encode their SPF records into an APL packet
without falling back to TCP.  Of course, falling back to TCP means
that a lot more overhead, almost as much as the current SPF setup.
Also, many braindead firewalls block TCP port 53, so I doubt
paypal.com would find that acceptable even if it was the only choice.

But, as I mentioned in an earlier post, APL records were used by the
RMX system.  They were rejected for good reasons.  Do you really want
to rehash all the thousands of posts from the IRTF ASRG, spf-discuss
and IETF MARID lists here?  I certainly don't.

Hint:  It isn't must paypal.com that can't use easily APL records,
yahoo.com in particular doesn't can't even come close.

-wayne

.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 Nov 2006 17:00:25 +0100 (CET)

> continue without recourse.

How can an attack be both a DDOS and remain hidden?

Please. With current virtualisation techniques, it is easy to setup a test
scenario with 4 machines that demonstrate this attack. Please setup such
a test setup on Xen, and provide hard data, (not 10x, not 100x) and let
look at the validity and reality and quality of the setup. Either you are
right and we can work on fixing SPF, or you are wrong and we can finally
end this discussion. But like this, it is getting nowhere.

Paul
.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Nov 2006 20:44:18 -0800

On Wed, 2006-11-15 at 17:00 +0100, Paul Wouters wrote:
> > Even with the level of amplification reduced, the source of this
> > attack remains hidden and can continue without recourse.
> 

An SPF related attack transverses resolvers offering a legitimate
service.  The source of an attack is not discerned examining suspicious
queries, or SMTP logs within the domain of a resolver transversed.  The
source of the attack comes from unidentifiable messages referencing
malicious SPF scripts located in unidentified domains.

-Doug

.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Nov 2006 20:44:11 -0800

On Wed, 2006-11-15 at 09:48 -0600, wayne wrote:
> >> > The SPF script language does not improve data compression.  APL
> >> > RR (RFC3123) provides 10 times the informational density and
> >> > existed prior to SPF development.
> >> 
> >> *sigh*
> >> 

...

> paypal.com's SPF record encodes 59 different IP blocks.  So,an APL
> record will need about 59*8=472 bytes. Will this fit in a UDP packet?

Check paypal's existing SPF records...

$ dig paypal.com TXT

; <<>> DiG 9.3.3rc2 <<>> paypal.com TXT
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39361
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4

;; Query time: 27 msec
;; SERVER: 208.201.224.33#53(208.201.224.33)
;; WHEN: Wed Nov 15 19:44:29 2006
;; MSG SIZE  rcvd: 477
>>>                ---

Even SPF records used by paypal.com do not fit!

Disney indicated their inability to fit all of their IP addresses within
SPF records as well.  Clearly SPF represents data structures far too
large for safely publishing with DNS.  SPF scripts do not reduce the
record size as Andras suggested.  In this case, SPF with TCP fallback
makes paypal.com prone themselves.

There are any number of ways to resolve the fundamental design problem,
and several solutions have been suggested.  This list is not where
solutions are to be discussed however.

-Doug

.

---

From: wayne <[email-masked]>
Date: Thu, 16 Nov 2006 00:14:09 -0600

> ;; Truncated, retrying in TCP mode.

Weird.  I get 413 bytes and no fallback to TCP.

> makes paypal.com prone themselves.

huh...

(wayne@footbone) $ host -t txt disney.com
disney.com          	TXT	"v=spf1 mx -all"

looks like they don't have a problem fitting.

You can always publish SPF records along the lines of:

   "v=spf1 exists:%{ir}._whitelist.large-domain.com -all"

This creates a DNSBL-type lookup.  As I'm sure you are quite aware,
DNSBLs can scale to very large sizes.  This will cost one extra DNS
lookup.  If you want to optimize it, you can use the ip4: mechanism to
list your most common sending IP addresses at the beginning.

-wayne
.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Nov 2006 00:57:59 -0800 (PST)

> Weird.  I get 413 bytes and no fallback to TCP.

The difference is due to "additional section" which includes ip addresses
of their NS servers. Paypal's DNS servers by default send all of them
even for non-NS queries. Depending on which dns server you use you may
not see it in response or your own dns server may not resend it to you
and may just cache locally ip address of the NS server it actually got
the answer from (but if you query multiple times it would learn):

--------------------------------------------------------------
dig @ns1.nix.paypal.com paypal.com txt

;; ADDITIONAL SECTION:
ns1.nix.paypal.com.     3600    IN      A       64.4.240.70
ns1.sc5.paypal.com.     3600    IN      A       64.4.244.70
ns2.nix.paypal.com.     3600    IN      A       64.4.240.71
ns2.sc5.paypal.com.     3600    IN      A       64.4.244.71

;; Query time: 14 msec
;; SERVER: 64.4.240.70#53(64.4.240.70)
;; WHEN: Thu Nov 16 00:41:41 2006
;; MSG SIZE  rcvd: 477
--------------------------------------------------------------

This is BTW related to another form of attack where somebody
would make a request and together with it send unsolicited
response to caching DNS server to increase size of its response;
after that send short queries (from spoofed addresses) and
long answers are sent and you amplification DoS [or change
real answer to get resolver "in trouble" and confused]

DNS is full of those little gadgets for use by bad guys - look
at the link by Fergie if you want to get more embarrassed ...

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Nov 2006 07:21:01 -0800

> list your most common sending IP addresses at the beginning.

If this scheme were the _only_ solution, an immense threat would have
been avoid (along with the extra lookup).  Publishing white-lists can
still be accommodated with APL using standardized prefixes.

SPF is like using scripts, rather than bitmaps, to describe fonts
offering any number of features, such as flashing text, moving arrows,
and winking smiley faces.  Alas, as with any script, evil remains
possible and can lurk within the obfuscation of complexity and
variability. 

-Doug

.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Nov 2006 08:40:29 -0800

On Thu, Nov 16, 2006 at 07:21:01AM -0800,
 Douglas Otis <[email-masked]> wrote 
 a message of 31 lines which said:

> offering any number of features, such as flashing text, moving
> arrows, and winking smiley faces.

I typically never replies to Otis' emails or I-Ds because it is
obvious he is just motivated by a personal anti-SPF drive but this
presentation of digital typography is ridiculous: using scripts
instead of bitmaps for fonts have much more advantages, the most
obvious one being the ability to scale the text. If Otis knows about
DNS as much as about typography, I understand a lot of things...

.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 17 Nov 2006 12:53:28 -0500 (EST)

Several wrong things here:

> view in email post I'm not doing it). He sends email with SMTP session 
[...]
> Now what happens is that each mail server that received 
> NS directed to victim DNS servers. 

Ahh, no. Only if you actually resolve this name, rather than just log
it. The SMTP server does not need to resolve this name, and learns
nothing by doing so.  (yet another "anti-spam" gun-foot-fire-aim
problem?).  There is no improved security in resolving such names, any
more than having in-addr proves one isn't a spammer.

> Victim servers would each answer that they are non-authoritative but
> would have to include large domain (imagine big.bad.example.com being
> close to maximum DNS label size)

No, only one server would answer.  That server either recurses (remember
the discussion about "reflectors are evil"), with the right answer (from
cache, even), or else it gives a (relatively larger) response containing
authority records directing to the nameservers that are authoritative
for the domain.

[Gee, it looks like reflectors are actually "good". I wish I had put
this in my opposition to draft-ietf-dnsop-reflectors-are-evil-02.txt]

There is no significant amplification.  Any DNS query has a response
larger than the question, so there is always some small amplification
potential.  Probably one could think of an EDNSO response with 8k bytes
of authority records, but I think such a record would pretty obviously
be custom made for abuse, rather than a legitimate purpose record, and
dealt with appropriately. I don't think this particular issue of
authority records is really much of a problem. Certainly not when
compared with the problems associated with 4k to 8k byte SPF and IN-ADDR
records which do occur legitimately, where the amplification is upwards
of 90x.

The executing of arbitrary time-consuming SPF scripts on the SPF-using
victim is a problem, but only for those people who use SPF. (again,
gun-foot-fire-aim). Its a problem in the SPF standards and SPF
architecture.  This problem can't be fixed operationally except by NOT
running arbitrary SPF scripts.

Of course, Information Theory shows conclusively that you can't stop
spam with things like DNS or SPF.  It seems to me that the fact that
other people want to waste their time on such scams should not be not a
DNSOP concern unless it affects stability or operations in someway. It
seems to me that only their own stability is affected, and then only
because of their insistence on ignoring the laws of physics and nature.
[its a physical law because information theory is related to
thermodynamics.]

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Nov 2006 12:33:51 -0800

On Nov 17, 2006, at 8:40 AM, Stephane Bortzmeyer wrote:

> obvious one being the ability to scale the text. If Otis knows  
> about DNS as much as about typography, I understand a lot of things...

The scale of the SPF query process returning all IP addresses  
authorized to send messages for specific domain is daunting.  This  
issue is expressed in the spf-dos-exploit draft.  Being the target of  
DoS abuse increases one's attention to details.  While respecting  
efforts made by Wayne, William and others from MARID, the basis of  
the SPF design remains flawed.  Fixing SPF requires a fundamental  
design change.  Wayne's libraries are the most conservative of those  
examined, although his scheme remains problematic for several domains.

Scripts indeed allow features that many come to expect.  Scripts  
however also represent a significant security threat.  With SPF, the  
victim of this threat can be any third-party not involved in the  
message's transaction.  The font analogy was an attempt to make a  
comparison, where indeed many desirable features are made possible by  
executing a script, rather than rigidly applying fixed data  
structures.  Email, all too often, is not about dealing with messages  
from known sources.  As such, it remains a bad idea to fetch html  
images and execute scripts contained within these messages  
automatically.

Many consider SPF script to be somehow different.  Unlike those cases  
mentioned, many expect SPF to be executed automatically without  
knowledge of the originator.  For many, the purpose of the SPF script  
is to discern whether an SMTP client is authorized, without ever  
knowing who is being authorized and who is making the reference to  
the script.

-Doug

.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Nov 2006 13:02:18 -0800

On Nov 17, 2006, at 9:53 AM, Dean Anderson wrote:

> The executing of arbitrary time-consuming SPF scripts on the SPF- 
> using victim is a problem, but only for those people who use SPF.  
> (again, gun-foot-fire-aim). Its a problem in the SPF standards and  
> SPF architecture.  This problem can't be fixed operationally except  
> by NOT running arbitrary SPF scripts.

The primary motivation for larger domains publishing SPF is to be  
white-listed by a few major providers demanding records for this  
purpose.  A laudable goal that can be more safely done using other  
methods.  A major software vendor is paying MTA vendors 50K to  
implement these libraries.  The libraries executing SPF scripts can  
easily affect those not using SPF.  SPF offers indirection with the  
hundreds of transactions invoked allowing anyone to covertly become a  
victim.  The present SPF transaction limit per execution is 10  
mechanism by 10 target resolutions.  If receiving a message would  
normally involve requesting and resolving all MX target addresses,  
then executing one SPF script would increase these risks by a factor  
of 10.  But there are multiple names within a message that might be  
used to check for authorization.  The level of risk also increases by  
how many names are being checked.  A PRA failure will likely lead to  
checking the Mail From, for example.  Soon DKIM might be added to  
this list.

-Doug
.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 20 Nov 2006 21:58:26 +0100

>    big IN NS victim-dns2.example.com

[snip]

This is part of a much larger problem.  You can achieve the same
effect with IMG SRC= links on a popular web service (for instance, an
ad server).  It is very hard to fix properly because at one point, you
need to send a packet, only to learn that it was unsolicited.  But the
damage has already been done.

Curiously, SPF tries to solve this vert problem, but in the end, it
only shifts the potential damage.  Every technical countermeasure
would probably fail in a similar manner.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html