Subject: [spfbis] Reasonable DNS error limits #24

From: Scott Kitterman <[email-masked]>
Date: Sat, 16 Mar 2013 13:40:39 -0400

This is one of the few open issues we have remaining:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24

> Each of 10 SPF mechanisms may require 10 separate reflected DNS resolutions
> where SPF is insensitive to the number of No Data responses in multiples of
> 100 DNS transactions. There is no limit for the number of No Data results,
> which represents a likely method malefactors might use in conjunction with
> local-part macros to implement DNS based attacks. The gain of this attack
> depends on whether SPF/TXT, HELO/EHLO, Mail From, and PRA checks are made
> for each message. Network amplification that could result is substantial.
> This risk can be significantly mitigated by simply imposing reasonable No
> Data limits.

This "No Data limit" is already widely deployed as part of the modern Perl SPF 
implementation, Mail::SPF.  This is documented at:

http://search.cpan.org/~jmehnle/Mail-SPF-v2.8.0/lib/Mail/SPF/Server.pm

> max_void_dns_lookups
> 
>     An integer denoting the maximum number of "void" DNS look-ups per SPF
>     check, i.e. the number of DNS look-ups that were caused by
>     DNS-interactive terms and macros (as defined in RFC 4408, 10.1,
>     paragraphs 6 and 7) and that are allowed to return an empty answer with
>     RCODE 0 or RCODE 3 (NXDOMAIN) before processing is aborted with a
>     permerror result. If undef is specified, there is no stricter limit on
>     the number of void DNS look-ups beyond the usual processing limits.
>     Defaults to 2.
>     
>     Specifically, the DNS look-ups that are subject to this limit are those
>     caused by the a, mx, ptr, and exists mechanisms and the p macro.
>     
>     A value of 2 is likely to prevent effective DoS attacks against
>     third-party victim domains. However, a definite limit may cause
>     permerror results even with certain (overly complex) innocent sender
>     policies where useful results would normally be returned.

The default of 2 has been in place since version 2.006, released on 
2008-08-17.

I had hoped to have time (or find someone else who had time) to use the results 
of Murray's previous SPF record survey to quantify the impact this might have 
on existing records, but have not succeeded.  Given that this has been in 
place, by default, for over 4 years on a very popular (using the Debian 
GNU/Linux distribution popcon (popularity contest) data, I would estimate that 
Mail::SPF is installed in almost 10% of Debian systems - it is by far the most 
popular SPF implementation in the distribution) implementation, I think it is, 
however, reasonable to assume that if it caused significant problems, they 
would have come up by now.  I did check with the primary developer (Julian 
Mehnle) and he is not aware of people having problems with it.

The only places a no data result will occur that are not due to a problem in 
the record are for exists which do not match the given criteria and for ptr 
(and p macro) if the connect IP has no reverse DNS.  The Mail::SPF limit of 
two allows for both these issues to occur in a record without raising an 
error.

My proposal is that we add this as a new limit in  section 4.6.4, DNS Lookup 
Limits, to resolve this issue.  I think it's a useful limit, unlikely to cause 
backward compatibility issues, and in scope for consideration due to long 
term, wide spread deployment.

If there is some consensus around the concept, then we can come up with 
specific text for 4.6.4, but I think it's useful to discuss the concept first.

Scott K

---

From: Dotzero <[email-masked]>
Date: Sat, 16 Mar 2013 17:19:10 -0400

Scott,

Your analysis and recommendation sound reasonable.

+1

On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman <[email-masked]> wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Mar 2013 20:31:58 -0700

I don't much care for the term "void lookup" (and Scott and I have
discussed this), but apart from that I'm in agreement with Mike that the
description and recommendation are reasonable additions.  If I can come up
with a better term, I will.  At a minimum, I would put a sentence or two
defining the term up front in the section where this is being added.
Something like this, perhaps (with corrections as appropriate):

Concerns have been addressed that SPF verifiers can be used as
amplification agents for a denial-of-service attack.  In this scenario, the
attacker publishes an SPF record in its own DNS that uses "a" and "mx"
mechanisms directed toward the intended victim, e.g. "a:example.com a:
foo.example.com a:bar.example.com ..." and then distributes mail with a
MAIL FROM value including its own domain in large volume to a wide variety
of destinations.  Any such destination operating an SPF verifier will begin
querying all of the names associated with the "a" mechanisms in that
record.  The names used in the record needn't exist for the attack to be
effective.

A DNS query that returns either a positive answer (RCODE 0) with an answer
count of 0, or a no such record (RCODE 3) answer, is sometimes called a
"void lookup".  Operational experience since publication of RFC4408
suggests that mitigation of this class of attack can be accomplished with
minimal impact on the deployed base by having the verifier abort processing
and return "permerror" (Section x.x.x) once two void lookups have been
encountered.  While an implementation may choose to make such a limit
configurable, such a limit SHOULD exist and the default of two is
RECOMMENDED.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 Mar 2013 16:05:11 +0100

On Tue 19/Mar/2013 04:31:58 +0100 Murray S. Kucherawy wrote:
> discussed this), but apart from that I'm in agreement with Mike that
> the description and recommendation are reasonable additions.  If I can
> come up with a better term, I will.  At a minimum, I would put a
> sentence or two defining the term up front in the section where this
> is being added.  Something like this, perhaps (with corrections as
> appropriate):
> 
> amplification agents for a denial-of-service attack.  In this 
> scenario, the attacker publishes an SPF record in its own DNS that 
> uses "a" and "mx" mechanisms directed toward the intended victim,
> e.g. "a:example.com a:foo.example.com a:bar.example.com ..." and
> then distributes mail with a MAIL FROM value including its own
> domain in large volume to a wide variety of destinations.  Any such
> destination operating an SPF verifier will begin querying all of 
> the names associated with the "a" mechanisms in that record.  The 
> names used in the record needn't exist for the attack to be
> effective.

Besides, can't we mention somewhere, e.g. Section 4.8, that the domain
owners consent is required to specify domains in SPF records?  Just as
ammo for those LEAs out there...

> A DNS query that returns either a positive answer (RCODE 0) with an
> answer count of 0, or a no such record (RCODE 3) answer, is sometimes
> called a "void lookup".  Operational experience since publication of
> RFC4408 suggests that mitigation of this class of attack can be
> accomplished with minimal impact on the deployed base by having the
> verifier abort processing and return "permerror" (Section x.x.x) once
> two void lookups have been encountered.  While an implementation may
> choose to make such a limit configurable, such a limit SHOULD exist
> and the default of two is RECOMMENDED.

I like that text, but the last sentence.  I don't think that kind of
attacks justify such a low limit.  If the victim's DNS and the mail
servers' caching DNSes work properly, the amplification gain seems to
be low.  IMHO, the last sentence should be:

   An implementation MAY choose to make such a limit configurable and
   default to a value lower than the recommended limit of 10.

jm2c

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 19 Mar 2013 09:55:28 -0700

> ammo for those LEAs out there...

How are we supposed to make such an assertion in a protocol document?

> But the limit in the module Scott referenced is 2, not 10.  What's the
> justification for changing it now?
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 25 Mar 2013 16:34:55 -0400

I worked this around a bit into a new security consideration (the why) and an 
addition the the DNS processing limit section (the what).  Thanks.

Scott K

On Monday, March 18, 2013 08:31:58 PM Murray S. Kucherawy wrote:
> > On Sat, Mar 16, 2013 at 1:40 PM, Scott Kitterman <[email-masked]>
> > 
> > wrote:
> > >> Each of 10 SPF mechanisms may require 10 separate reflected DNS
> > 
> > resolutions
> > 
> > >> where SPF is insensitive to the number of No Data responses in
> > 
> > multiples of
> > 
> > >> 100 DNS transactions. There is no limit for the number of No Data
> > 
> > results,
> > 
> > >> which represents a likely method malefactors might use in conjunction
> > 
> > with
> > 
> > >> local-part macros to implement DNS based attacks. The gain of this
> > 
> > attack
> > 
> > >> depends on whether SPF/TXT, HELO/EHLO, Mail From, and PRA checks are
> > 
> > made
> > 
> > >> for each message. Network amplification that could result is
> > 
> > substantial.
> > 
> > >> This risk can be significantly mitigated by simply imposing reasonable
> > 
> > No
> > 
> > >> Data limits.
> > > 
> > > This "No Data limit" is already widely deployed as part of the modern
> > 
> > Perl SPF
> > 
> > >>     An integer denoting the maximum number of "void" DNS look-ups per
> > 
> > SPF
> > 
> > >>     paragraphs 6 and 7) and that are allowed to return an empty answer
> > 
> > with
> > 
> > >>     permerror result. If undef is specified, there is no stricter limit
> > 
> > on
> > 
> > >>     Specifically, the DNS look-ups that are subject to this limit are
> > 
> > those
> > 
> > > I had hoped to have time (or find someone else who had time) to use the
> > 
> > results
> > 
> > > of Murray's previous SPF record survey to quantify the impact this might
> > 
> > have
> > 
> > > GNU/Linux distribution popcon (popularity contest) data, I would
> > 
> > estimate that
> > 
> > > Mail::SPF is installed in almost 10% of Debian systems - it is by far
> > 
> > the most
> > 
> > > popular SPF implementation in the distribution) implementation, I think
> > 
> > it is,
> > 
> > > however, reasonable to assume that if it caused significant problems,
> > 
> > they
> > 
> > > would have come up by now.  I did check with the primary developer
> > 
> > (Julian
> > 
> > > The only places a no data result will occur that are not due to a
> > 
> > problem in
> > 
> > > the record are for exists which do not match the given criteria and for
> > 
> > ptr
> > 
> > > (and p macro) if the connect IP has no reverse DNS.  The Mail::SPF limit
> > 
> > of
> > 
> > > My proposal is that we add this as a new limit in  section 4.6.4, DNS
> > 
> > Lookup
> > 
> > > Limits, to resolve this issue.  I think it's a useful limit, unlikely to
> > 
> > cause
> > 
> > > specific text for 4.6.4, but I think it's useful to discuss the concept
> > 
> > first.
> > 
> > > Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Mar 2013 19:46:30 +0100

> addition the the DNS processing limit section (the what).  Thanks.

I think it may be clearer if 11.1 *Processing Limits* refers back to
Section 4.6.4 *DNS Lookup Limits* where "void lookups" is defined,
rather than talking about "lookups of non-existent domains".

The examples in 11.1 only mention "a" and "mx", while your original
message mentioned also "ptr", "exists" and the p macro.  Are
implementers supposed to derive that on their own?

Counting void lookups against "exists", as Mail::SPF::Server does,
implies that at most one "exists" mechanism can be defined in a record
and its descendants:  A second "exists" must never fail (and hence
it's futile) because its failure would trigger permerror, thereby
requiring manual intervention on the record.  Advice for publishers is
deserved.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 26 Mar 2013 23:02:10 -0400

On Tuesday, March 26, 2013 07:46:30 PM Alessandro Vesely wrote:
> > I worked this around a bit into a new security consideration (the why) and
> > an addition the the DNS processing limit section (the what).  Thanks.

Fixed locally.

> implementers supposed to derive that on their own?

The list of DNS using terms is earlier in section 4.6.4.  Since that's where 
the implementation guidance is, I think that's the right place to me 
exhaustive.

> requiring manual intervention on the record.  Advice for publishers is

The limit is two, so it's an error if there are three.  The text in 11.1 was 
wrong (and inconsistent with 4.6.4).  Fixed locally.

Thanks for the feedback.

Scott K