Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits

From: S Moonesamy <[email-masked]>
Date: Tue, 06 Mar 2012 09:13:24 -0800

At 18:56 21-02-2012, spfbis issue tracker wrote:
>#24: RFC 4408: Reasonable DNS error limits
>
>  Message from Douglas otis on 21 Feb 2012:
>
>  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.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24>

Please comment on the above issue.  As a reminder, please keep the 
subject line so that the discussion can be tracked easily.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Philip Gladstone <[email-masked]>
Date: Tue, 06 Mar 2012 12:23:24 -0500

> subject line so that the discussion can be tracked easily.
The "exists" mechanism is designed to test for the existence of a DNS 
record. I do not believe that DNS errors should be counted for this 
mechanism. The number of "exists" mechanisms that can be invoked is 
small, so there doesn't appear to be a risk here.

Philip

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 12:27:27 -0500

On Tuesday, March 06, 2012 09:13:24 AM S Moonesamy wrote:

I think the actionable part of the issue is:
...
> This risk can be significantly mitigated by simply imposing reasonable No 
Data limits.
...

This is an interesting idea.  As I mentioned when this was suggested, this is 
already implemented in Mail::SPF max_void_dns_lookups.  From the Mail::SPF 
documentation:

> An I<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
> (C<NXDOMAIN>) before processing is aborted with a C<permerror> result. 
> If B<undef> is specified, there is no stricter limit on the number of
> void DNS look-ups beyond the usual processing limits.  Defaults to B<2>.
> 
> Specifically, the DNS look-ups that are subject to this limit are those
> caused by the C<a>, C<mx>, C<ptr>, and C<exists> mechanisms and the C<p>
> macro.
> 
> A value of B<2> is likely to prevent effective DoS attacks against
> third-party victim domains.  However, a definite limit may cause
> C<permerror> results even with certain (overly complex) innocent sender
> policies where useful results would normally be returned.

This proposal may affect currently published and RFC 4408 compliant records as 
it is silent on this type of limitation.  I suspect, however, that for an 
appropriate value as the limit, this type of limit could be added to 4408bis 
without affecting interoperability.

In order to determine this, we'll need a survey of records to get a 
distribution of the number of void DNS lookups in SPF records.  I'm not sure 
how much we can do with the issue until we have data.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 12:36:55 -0500

> small, so there doesn't appear to be a risk here.

It's either that or count it and you've effectively limited the number of 
exists mechanisms in one SPF record to ~whatever limit we set.  Since exists 
is rarely used and rarely included, I think it would be OK to limit it to a 
few per record.  OTOH, exists can't provoke further lookups, so it should be 
OK not to count.

I think either approach would be OK (assuming we get a good survey that 
determines this type of limit is OK in general).  It's probably marginally 
simpler to conceptualize not counting exists for users crafting records.  It's 
probably marginally easier to implement counting all no data results than all 
but exists.  Tossup.

Since there's a lot more people writing SPF records than writing SPF 
libraries, I think I agree with you.

Scott K

---

From: John Leslie <[email-masked]>
Date: Tue, 6 Mar 2012 13:02:01 -0500

S Moonesamy <[email-masked]> wrote:
> Please comment...

   Doug is calling out a possible abuse situation, wherein an SPF record
can call for more than one DNS lookup to a domain quite unrelated to the
sending MTA.

   This deserves discussion on one of our RFCs -- I shall leave it for
others to argue which one...

   Be warned that "It hasn't happened yet" may not be a sufficient
discussion.

   The essential point, IMHO, is that any no-data response is a hint of
abuse; thus action to impose a limit on the rate of such queries after
a no-data response may be appropriate. Likewise, no-response may mean
that a DDoS is succeeding; and an even stricter limit might make sense.

   The other side of the argument is that these macros are _sometimes_
useful. We have seen them useful in gathering data on actual usage.
And there are situations in which different policies _must_ apply to
different local-parts.

   All this suggests to me that there may not _be_ a single limit which
makes sense.

   I suggest we consider "MAY" language here -- admitting that we can't
know how this issue might play out over the next decade. Instead of
trying for a maximum number of such queries, could we consider instead
what the _minimum_ might be to accomplish identified valid usage, and
specify MAY for any queries beyond that minimum?

--
John Leslie <[email-masked]>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 06 Mar 2012 19:12:18 +0100

> few per record.  OTOH, exists can't provoke further lookups, so it should be 

I'd rather have the limit set at 11 than saying which lookups don't
count.  No exception, just for the sake of clarity.  Redirect and
include count, don't they?  And the count is global, per call... but
that is ticket #6.

But what's puzzling me is the distinction between errors, no data,
cached responses, and similar.  Does it serve any practical purpose?

If at all possible, I'd avoid any exception, so that, given an SPF
record and the records recursively looked up via redirect and include,
it is possible to statically state whether it is valid or not.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 18:18:30 +0000

I need some clarification on this issue before I can give an opinion.  Someone help me out here...

Is the issue that I could publish an SPF policy that causes queries to someone else's DNS as a means of an attack, and the proposed mitigation is to abort the query if too many NOERROR replies with zero answers (which I think is what people mean by "No Data") are received?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 13:43:48 -0500

On Tuesday, March 06, 2012 01:02:01 PM John Leslie wrote:
> >> 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

Despite the rhetoric in the issue, I don't think any changes with regards to 
macros are being proposed here.  The only SPF mechanism that expects a nodata 
response in normal operations is exists: and I don't think there's a use case 
for multiple exists: per SPF record (except via include: or redirect=).

The basic theory is not new and a detailed assessment of it was done several 
years ago:

http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

Fundamentally, there is no news here.  If someone intendend to do an 
amplification attack like the rhetorical part of this issue describes, there 
are easier ways to do it than an SPF record.

That said, the specific operational piece of the comment is implemented and in 
widespread use (Mail::SPF is the most used, AFAIK, open source SPF 
implementation), so I think it's reasonable to consider adding the void lookup 
limit in some form.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 13:45:42 -0500

On Tuesday, March 06, 2012 06:18:30 PM Murray S. Kucherawy wrote:
> Is the issue that I could publish an SPF policy that causes queries to
> someone else's DNS as a means of an attack, and the proposed mitigation is
> to abort the query if too many NOERROR replies with zero answers (which I
> think is what people mean by "No Data") are received?

I believe that's correct.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Mar 2012 19:03:32 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Scott Kitterman
> Sent: Tuesday, March 06, 2012 10:46 AM
> To: [email-masked]
> Subject: Re: [spfbis] #24: RFC 4408: Reasonable DNS error limits
> 
> > someone else's DNS as a means of an attack, and the proposed
> > mitigation is to abort the query if too many NOERROR replies with zero
> > answers (which I think is what people mean by "No Data") are received?
> 

I think the mitigation is weak, then.  It thwarts the attack scenario in which I point my SPF record at some stuff in your domain that doesn't actually exist, but if I use "mx" or other mechanisms that do hit things that exist, the attack isn't stopped.

So I'm fine with the idea of specifying NODATA cutoff limits, but it doesn't cover the full threat space here, and we'll have to admit that in Security Considerations or suchlike.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 06 Mar 2012 14:06:39 -0500

On Tuesday, March 06, 2012 07:03:32 PM Murray S. Kucherawy wrote:
> > > I need some clarification on this issue before I can give an
> > > opinion.
> > > Someone help me out here...
> > > 
> I think the mitigation is weak, then.  It thwarts the attack scenario in
> which I point my SPF record at some stuff in your domain that doesn't
> actually exist, but if I use "mx" or other mechanisms that do hit things
> that exist, the attack isn't stopped.
> 
> So I'm fine with the idea of specifying NODATA cutoff limits, but it doesn't
> cover the full threat space here, and we'll have to admit that in Security
> Considerations or suchlike.

Certainly.  To the extent there's a threat we'll need to document it.  This 
isn't news since all the processing limits in RFC 4408 are in security 
considerations.  We have another issue on splitting them out and making both 
the limits an dthe security considerations clearer.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Mar 2012 09:50:26 +0100

> http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

Section 5.4 of RFC 4408 says:

                                        To prevent Denial of Service
 (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
 evaluation of an "mx" mechanism (see Section 10).

Section 10 says:

 SPF implementations MUST limit the number of mechanisms and modifiers
 that do DNS lookups to at most 10 per SPF check, including any
 lookups caused by the use of the "include" mechanism or the
 "redirect" modifier.  If this number is exceeded during a check, a
 PermError MUST be returned.  The "include", "a", "mx", "ptr", and
 "exists" mechanisms as well as the "redirect" modifier do count
 against this limit.

To me, "do count against this limit" means that for "v=spf1 +mx -all"
one has already spent two lookups for the record itself and the mx, so
the evaluation fails if the sending address belongs to the ninth
eXchanger or further down.  No 111 amplification.  What am I missing?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 07:06:46 -0500

On Wednesday, March 07, 2012 09:50:26 AM Alessandro Vesely wrote:
> > The basic theory is not new and a detailed assessment of it was done
> > several years ago:
> > 

First, I don't think there's a lot of point in computing the maximum number of 
lookups possible.  As has been said elsewhere in the thread there are other, 
simpler, ways of doing an attack like this, so I while I do think we need to 
address the concern, I'm not worried about the specifics in great detail.

I do think we need to make sure the processing limits are worded in a way that 
is clear enough that everyone counts things the same way for a deterministic 
result.  Your "v=spf1 +mx -all" example and your counting is a good example of 
how people can easily get things wrong.

Look again at RFC 4408 10.1.  

"MUST limit the number of mechanisms and modifiers  that do DNS lookups to at 
most 10 per SPF check"

Your example only has one mechanism or modifier that does a DNS lookup (mx), so 
it counts as one, not two.  The language in 4408 10.1 is technically 
unambiguous, but hard to parse.  This is why I filed issue #6, RFC 4408 Section 
10.1 - Processing limits needs clarification and reorganization.  We can figure 
out how to rewrite it when we get to that issue, but I thought it worth 
mentioning is this thread as an example of why we need clearer words.

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

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Mar 2012 13:41:57 +0100

On 07/Mar/12 13:06, Scott Kitterman wrote:
> First, I don't think there's a lot of point in computing the
> maximum number of lookups possible.

Why?  It doesn't sound difficult to specify of implement.  I mean,
isn't it easier to say "you can do at most 111 lookups" than "you can
evaluate at most 10 terms worth 10 lookups each plus an exists as a
bonus"?

> "MUST limit the number of mechanisms and modifiers  that do DNS lookups to at 

It may be clearer as:

  MUST limit the number of terms that do DNS lookups to at most 10
  /terms/ per SPF check

BTW, I don't think "term" is a bad term.

> http://trac.tools.ietf.org/wg/spfbis/trac/ticket/6

Sorry for conflating #6 and #24.  They really ought to be merged.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 08:10:42 -0500

> evaluate at most 10 terms worth 10 lookups each plus an exists as a

The 111 is a corner case.  Your reformulation makes it the standard case.  I 
don't think it's a good idea.

> > "MUST limit the number of mechanisms and modifiers  that do DNS lookups
> > to at most 10 per SPF check"
> 
> It may be clearer as:
> 

Could be, except then you have to go look up what a term is.  I don't feel 
strongly either way.

> Sorry for conflating #6 and #24.  They really ought to be merged.

I don't think so.  They are related, but not the same.

AIUI, #6 is about refactoring the way the existing processing limits and 
security considerations and this is about adding a new limit on no data 
lookups.

scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 07 Mar 2012 18:43:15 +0100

On 07/Mar/12 14:10, Scott Kitterman wrote:
> The 111 is a corner case.  Your reformulation makes it the standard
> case.  I don't think it's a good idea.

No, wait.  I don't mean one /has/ to do all the lookups.  The limit is
meant to guard against an excessive number of lookups, whether
malicious or buggy.  As long as we believe that's not the norm, and
only happens in corner cases, a non-partitioned amount of lookups may
be more flexible and simpler than a structured limit devised to
prevent a particular attack only.

> Could be, except then you have to go look up what a term is.  I don't feel 

I'd be fine with a better term.  The point is, as Arthur noted, that
it has to be repeated twice in that sentence.

> security considerations and this is about adding a new limit on no data 

Except in case we find out that a better refactoring of processing
limits can cover the full threat space, making #24 moot.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 13:05:36 -0500

On Wednesday, March 07, 2012 06:43:15 PM Alessandro Vesely wrote:
> No, wait.  I don't mean one has to do all the lookups.  The limit is

The current rules are:

No more than 10 terms that need DNS lookups
No more than 10 a lookups from an mx mechanism
No more than 10 a lookups from a PTR mechanism.

So there is currently a primary limit of 10 and a secondary limit of 10 
lookups per primary of a certain type.

Is there any evidence that the primary limit of 10 is not adequate?  I am not 
aware of any.  Most of the largest email providers that exist have published 
records that fit within this limit.

Why would we want to change it?  Because we're changing the spec and it makes 
the spec clearer is not a good reason if it requires code to be re-written.  
Your proposal would.

As has been mentioned, one of the primary design principles in SPF was to 
produce a deterministic output based on a defined input.  If we change the 
current 1 + 10 + 10*10 limit to 111, then every SPF library that properly 
implements RFC 4408 10.1 would have to be changed.  

Based on that, I think the proposal is out of scope, but I also think it's a 
bad idea in any case.

Scott K

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 07 Mar 2012 15:17:53 -0500

Long ago, Nostradamus foresaw that on 03/07/2012 01:05 PM, Scott 
> No more than 10 a lookups from a PTR mechanism.
I would like to point out that 'MX' is the only problematic mechanism in 
a Doug Otis scenario.  PTR only needs to get looked up once per 
connection (and is then cached).  The MTA has probably already looked it 
up, so I don't think it should count at all (but I'm not recommending 
changing the rules for 4408bis).  'A' is a straightforward one lookup 
per mechanism.  'MX', on the other hand may require up to 10 additional 
'A' lookups.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 15:30:47 -0500

> per mechanism.  'MX', on the other hand may require up to 10 additional

To the extent any of this is actually problematic, I agree.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Mar 2012 21:36:11 +0000

Limiting the total number of DNS queries a single policy causes is a function of the domain publishing the policy, and the policies to which it points (which may or may not be the same).

If for example I post a policy of "v=spf1 mx -all", and then I advertise "n" MXes, and each of those have "m" IP addresses, that gives me m x n IP addresses to compare to the client address.  If that's arbitrarily truncated, by this specification, it can lead to false negatives and random message rejections.

I think there are two things to point out here in RFC4408bis (in the vein of "I have not read your document but I have an opinion on it"):

1) An ADMD that wants to publish an SPF policy but already has a matrix of MX/A records that will be queried needs to understand the DNS load from SPF verifiers that this will generate, and might want to consider some other arrangement.

2) The same ADMD that declines to make any adjustment risks SPF false negatives as described above.

I'm also a little troubled that, since the order of RRs in a reply can be randomized, the place at which the set is truncated is not under the control of the ADMD.  I know it's out of scope, but if we can't come up with a way to alleviate that concern (which seems likely), we might -- after re-chartering, of course -- consider a way to provide instruction to verifiers about how to truncate the list; for example, consider only MXes whose precedence is below/above/equal to some value.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 16:55:28 -0500

On Wednesday, March 07, 2012 09:36:11 PM Murray S. Kucherawy wrote:
> Limiting the total number of DNS queries a single policy causes is a
> function of the domain publishing the policy, and the policies to which it
> points (which may or may not be the same).
> 
> If for example I post a policy of "v=spf1 mx -all", and then I advertise "n"
> MXes, and each of those have "m" IP addresses, that gives me m x n IP
> addresses to compare to the client address.  If that's arbitrarily
> truncated, by this specification, it can lead to false negatives and random
> message rejections.
> 
> I think there are two things to point out here in RFC4408bis (in the vein of
> "I have not read your document but I have an opinion on it"):
> 
> 1) An ADMD that wants to publish an SPF policy but already has a matrix of
> MX/A records that will be queried needs to understand the DNS load from SPF
> verifiers that this will generate, and might want to consider some other
> arrangement.
> 
> I'm also a little troubled that, since the order of RRs in a reply can be
> randomized, the place at which the set is truncated is not under the
> control of the ADMD.  I know it's out of scope, but if we can't come up
> with a way to alleviate that concern (which seems likely), we might --
> after re-chartering, of course -- consider a way to provide instruction to
> verifiers about how to truncate the list; for example, consider only MXes
> whose precedence is below/above/equal to some value.

What RFC 4408 doesn't say (it's left to the reader to infer from paragraph 
10.1) is if you have more than 10 mx records, don't use an mx mechanism in 
your SPF record.  We could be explicit about that.  There are ways around this 
problem that don't require protocol changes.

FWIW, I don't think anyone actually needs more than 10, they just haven't 
thought things through (Gmail only has 5, Yahoo has 3).  I don't think that 
4408bis has to accomodate every vaguery of ill considered design.  On the off 
chance one actually has more than 10, you can do it like this:

Imagine the following:

$ dig mx example.com +short

10 mx00.example.com
10 mx01.example.com
10 mx02.example.com
10 mx03.example.com
10 mx04.example.com
20 mx05.example.com
20 mx06.example.com
20 mx07.example.com
20 mx08.example.com
...
40 mx20.example.com

Instead of using mx in an SPF record, publish records for another unique 
hostname, e.g. mx.example.com, and a records from it pointint at all the 
various mx* IP addresses:

$ dig a mx.example.com +short

mx.example.com     120     IN    A   192.0.2.2
mx.example.com     120     IN    A   192.0.2.3
mx.example.com     120     IN    A   192.0.2.4
mx.example.com     120     IN    A   192.0.2.5
mx.example.com     120     IN    A   192.0.2.6
mx.example.com     120     IN    A   192.0.2.7
mx.example.com     120     IN    A   192.0.2.8
...
mx.example.com     120     IN    A   192.0.2.22

Then you can use that in an SPF record like:

v=spf1 a:mx.example.com -all

That covers all the same IP space as:

v=spf1 mx -all (for example.com)

But it's only one DNS lookup.

There's really no reason to give any advice other than "If you have more than 
10, don't use mx/ptr".

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Mar 2012 22:11:06 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, March 07, 2012 1:55 PM
> To: [email-masked]
> [...]
> There's really no reason to give any advice other than "If you have
> more than 10, don't use mx/ptr".

I'd be quite happy if we included that sort of material to guide people about the tradeoffs of various approaches.  I don't think the protocol needs to be fixed to handle this stuff, but nuances like what we're talking about need to be highlighted.

There's still an attack that's at least worth calling out, but I don't particularly care about MX/A set truncations causing false negatives in that case.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2012 17:41:08 -0500

On Wed, Mar 07, 2012 at 10:11:06PM +0000, Murray S. Kucherawy wrote:
> I'd be quite happy if we included that sort of material to guide
> people 

[. . .]

I'm not sure whether my hat is on or off for this, but that sounds to
me very much like deployment advice and not part of the protocol.  If
people want to produce such material, we ought to think very hard
about whether it belongs in a protocol draft or somewhere else.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 7 Mar 2012 22:46:33 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Wednesday, March 07, 2012 2:41 PM
> To: [email-masked]
> people want to produce such material, we ought to think very hard about
> whether it belongs in a protocol draft or somewhere else.

True, that.

If putting this stuff in appendices is something we don't really want to do (I could go either way), an Applicability Statement is certainly a feasible alternative.  It's not among our current chartered deliverables, but I'd be willing to argue for its addition.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 07 Mar 2012 17:56:01 -0500

>about whether it belongs in a protocol draft or somewhere else.
Writing records that fit within the processing limits is an essential part of determinism of the protocol. Please let's not fork off part of what people need to know to do that into a separate document (that no one is chartered to write).

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2012 18:05:08 -0500

On Wed, Mar 07, 2012 at 05:56:01PM -0500, Scott Kitterman wrote:
> >
> Writing records that fit within the processing limits is an
> essential part of determinism of the protocol. Please let's not fork
> off part of what people need to know to do that into a separate
> document (that no one is chartered to write).

Hat on for sure now.  I agree with this.  I'm just trying to
distinguish between "parts of protocol" (which is definitely part of
what we have to do) and "advice to users".  "DNS response size limits"
fits in the former.  "How to set up your zone so it works reliably"
does not.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2012 00:56:51 -0000

>thought things through (Gmail only has 5, Yahoo has 3).

Actually, gmail has considerably more than 5, but they only hand out five per
DNS answer.  Each of Yahoo's MXes has at least 8 A records.  But, of course,
neither publishes an SPF record with an MX clause.

>There's really no reason to give any advice other than "If you have more than 

Agreed.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2012 00:58:26 -0000

>about whether it belongs in a protocol draft or somewhere else.

In this case, I think it belongs in the protocol document, since it's
basically pointing out that something that you might think would work
if you read one part of the document in fact doesn't if you read the
rest of it.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Mar 2012 01:01:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, March 07, 2012 4:57 PM
> To: [email-masked]
> Cc: [email-masked]
> >FWIW, I don't think anyone actually needs more than 10, they just
> >haven't thought things through (Gmail only has 5, Yahoo has 3).
> 
> Actually, gmail has considerably more than 5, but they only hand out
> five per DNS answer.  Each of Yahoo's MXes has at least 8 A records.
> But, of course, neither publishes an SPF record with an MX clause.

Let's say they did: Is there no possibility then that a piece of email might come from a server that's not in the five contained in the DNS answer?

This is the kind of thing I'm on about.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 8 Mar 2012 01:48:39 -0000

>Let's say they did: Is there no possibility then that a piece of email might come from a
>server that's not in the five contained in the DNS answer?

In practice, anyone big enough to do rotating DNS for their mail
servers is going to have separate inbound and outbound servers, but
hypothetically assuming they got a really great deal on a warehouse
full of bidirectional Sendmail boxes, of course mail would be likely
to come from servers that don't show up in any particular DNS reply.

The general advice is that if you're using any clause that uses the
value of another DNS query, such as a, mx, include, ptr, exists, and
redirect, the results of that query better be consistent.

R's,
John

---

From: S Moonesamy <[email-masked]>
Date: Thu, 08 Mar 2012 09:14:02 -0800

I'll attempt to summarize the discussion of Issue #24. If I 
misinterpreted or misunderstood your comments, please let me know. 
The issue was based on the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00501.html

Philip Gladstone commented that the number of "exists" mechanisms 
that can be invoked is small, so there doesn't appear to be a risk 
here [1].  Scott Kitterman pointed out the actionable part of the 
issue: this risk can be significantly mitigated by simply imposing 
reasonable No Data limits [2].  He also mentioned an implementation 
and suggested a survey of records to get a distribution of the number 
of void DNS lookups in SPF records.  He agreed [3] on the points 
mentioned in Philip Gladstone's message.

John Leslie mentioned that the issue is calling out a possible abuse 
situation, wherein an SPF record can call for more than one DNS 
lookup to a domain quite unrelated to the sending MTA and that it 
deserves discussion on one of our RFCs [4].  He also mentioned that 
the essential point is that any no-data response is a hint of abuse; 
thus action to impose a limit on the rate of such queries after a 
no-data response may be appropriate.

Murray Kucherawy asked for a clarification about the issue 
[5].  Scott Kitterman pointed to draft-otis-spf-dos-exploit-01 
[expired draft] and mentioned that there are easier ways to do an 
amplification attack [6].  Murray Kucherawy suggested NODATA cutoff 
limits in a security considerations section [7].

Arthur Thisell mentioned that it is quite possible to generate larger 
amplification attacks using plain old DNS, in particular, the NS, MX, 
SRV, etc. records.   Unlike RFC 4408, the DNS RFCs don't have any 
limits on the recursion depth.  It is far easier for an attacker to 
trigger an NS lookup than it is to trigger an SPF evaluation [8] and 
that things like the "no data" limit are not complete fixes.  He also 
mentioned in response to a previous message about "MAY" language 
would mean that two different SPF implementations/users could 
evaluate the same SPF record and give different results [9].

Alessandro Vesely quoted Section 5.4 of RFC 4408 and Section 10, and 
commented that he did not see amplification [attack].  Stuart Gathman 
pointed out that 'MX' is the only problematic mechanism in a Doug 
Otis scenario [10] and Scott Kitterman agreed.

There was a comment from Andrew Sullivan, as chair [11].

I read all the messages on this thread.  I left some out in this 
message.  It's difficult to come up with a rough summary of the 
discussion on Issue #24.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00768.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00769.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00771.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00773.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00777.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00781.html
7. http://www.ietf.org/mail-archive/web/spfbis/current/msg00783.html
8. http://www.ietf.org/mail-archive/web/spfbis/current/msg00786.html
9. http://www.ietf.org/mail-archive/web/spfbis/current/msg00787.html
10. http://www.ietf.org/mail-archive/web/spfbis/current/msg00827.html
11. http://www.ietf.org/mail-archive/web/spfbis/current/msg00836.html

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 08 Mar 2012 13:17:02 -0500

> message.  It's difficult to come up with a rough summary of the

I think it's a good summary and fairly captures my points.  The only important 
point from the thread that I recall (I didn't go reread all the messages) that 
isn't mention is someone (I think John Leslie) suggesting that "it hasn't 
happened yet" is not a sufficient argument to consider this risk is necessarily 
mitigated.

I think that absent data, we won't be able to come to a good decision on this 
issue.  The SPF record survey that Murray Kucherawy has in progress now (to 
help inform the Type TXT/Type SPF discussion) will give us a list SPF records 
that could serve as an input to the survey I suggested.

If, to pick an exemplary number, we determine that we could set the maximum 
number of void lookups to 5 and affect no currently deployed SPF records that 
we could find that are otherwise functional, then I think that adding this kind 
of limit is low risk and eminently sensible.  OTOH, if you have to set it to 
50 and it still affects some small percentage, it's pretty inconsistent with 
the backwards compatibility goals in the charter and of minimal value.  The 
truth will likely be (of course) in the middle where we'll have a diversity of 
opinion about what the facts mean.

I'd like to suggest we do the survey and then look at this again.  My Perl 
skills are nil, but I'll be glad to help out to the extent I can.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 10 Mar 2012 13:12:09 +0100

On 08/Mar/12 18:14, S Moonesamy wrote:
> commented that he did not see amplification [attack].

Sorry, I meant to say that if issue #6 were solved by comprehensively
limiting lookups rather than guarding against known attack paths only,
then there would be no possibility of amplification and this issue
would be moot.

On 07/Mar/12 19:05, Scott Kitterman wrote:
>>> The 111 is a corner case.  Your reformulation makes it the
>>> standard case.  I don't think it's a good idea.
>>
>> As long as we believe that's not the norm, and only happens in
>> corner cases, a non-partitioned amount of lookups may be more
>> flexible and simpler than a structured limit devised to prevent a
>> particular attack only.
>
> The current rules are:
> 
> So there is currently a primary limit of 10 and a secondary limit
> of 10 lookups per primary of a certain type.

I'm unable to see the advantages of such a complicated structure.  I
hope we are not going to mandate that.

> Why would we want to change it?  Because we're changing the spec
> and it makes the spec clearer is not a good reason if it requires
> code to be re-written. Your proposal would.

If we wanted to change it, given that current processing limits need
clarification and reorganization, we could do it so as to avoid
invalidating existing code.

> As has been mentioned, one of the primary design principles in SPF
> was to produce a deterministic output based on a defined input.

AIUI, the "beyond limits" result is meant to be achieved for malicious
or buggy records only.  It is not a production technique.
A "good" SPF record getting PermError after some DNS maintenance, or a
"bad" record making a successful attack, are not the kind of
determinism we're after.  Unless the 10-10-10 rule expresses an
interoperable protocol feature, there should be no reason to require
that exact behavior.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 10 Mar 2012 11:55:46 -0500

> interoperable protocol feature, there should be no reason to require

It is.

RFC 4408 allows 10 mechanisms that use DNS.  If 4408bis allows (to pick an 
example) an overall limit of 50 DNS lookups without distinguishing as to their 
type, a sender could publish ann SPF record with (as an example) 15 DNS a: 
mechanisms that would be compliant with this hypothetical 4408bis requirement.  
Such a record would get a PermError from any software designed to RFC 4408 
requirements.

Unless we want to abandon backwards compatibility (we don't and we'd have to 
recharter for it anyway) the limit of no more than 10 a:, mx:, include:, ptr: 
or exists: is going to have to be carried forward into 4408bis.  There is no 
backwards compatible way to change it.

The other two limits are a bit different.  The additional lookups that can be 
caused by mx: and ptr: mechanisms are lookup caps, not hard publishing limits.  
Sites can publish as many MX records as they want.  It won't cause an error, 
it will just cause unreliable results because a compliant check_host() 
implementation will only look at the first ten and there's no guarantee of 
order in the responses.

The current language of RFC 4408 paragraph 10.1 does comprehensively limit the 
total number of DNS lookups and there is no validated 'attack path'.  Issue #6 
is about potentially adding an additional constraint that might provide some 
reduced risk to DNS DoS (not that the current level is high) and offer some 
potential for performance improvement (since check_host() would be able to 
abandon processing buggy records earlier).

4408bis needs to clearly define what records will raise errors.  SPF record 
publishers need to have confidence that their records will be processed 
reliably by both 4408 and 4408bis compliant check_host() implementations.

I do not believe it's possible to rewrite the limits the way you have proposed 
without losing backward compatbility.  So either I misunderstand your proposal 
or one of us is wrong about backward compatibility.

Would you please propose some text that might be suitable for inclusion in a 
4408bis draft (if we had one) that explains your proposal?  

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 11 Mar 2012 15:21:05 +0100

On 10/Mar/12 17:55, Scott Kitterman wrote:
>> Unless the 10-10-10 rule expresses an interoperable protocol
>> feature, there should be no reason to require that exact
>> behavior.
> 
> It is.

The numbers "10" there have no semantically relevant meaning, though.

> RFC 4408 allows 10 mechanisms that use DNS.  If 4408bis allows (to
> pick an example) an overall limit of 50 DNS lookups without
> distinguishing as to their type, a sender could publish ann SPF
> record with (as an example) 15 DNS a: mechanisms that would be
> compliant with this hypothetical 4408bis requirement. Such a record
> would get a PermError from any software designed to RFC 4408 
> requirements.
> 
> Unless we want to abandon backwards compatibility (we don't and
> we'd have to recharter for it anyway) the limit of no more than 10
> a:, mx:, include:, ptr: or exists: is going to have to be carried
> forward into 4408bis.  There is no backwards compatible way to
> change it.
> 
> The other two limits are a bit different.  The additional lookups
> that can be caused by mx: and ptr: mechanisms are lookup caps, not
> hard publishing limits. Sites can publish as many MX records as
> they want.  It won't cause an error, it will just cause unreliable
> results because a compliant check_host() implementation will only
> look at the first ten and there's no guarantee of order in the
> responses.

That's the semantics of DNS, and the traditional difficulties at
maintaining DNS settings.  To wit, SPF could be used to just tell what
addresses are authorized, and it would be a real pain to maintain it.
 Therefore, SPF offers all the mechanisms quoted above, and redirect.
 Thus, publishers' convenience is paid with lookups.

(That looks much like interpret/compile tradeoffs, and the situation
could be amended using an "SPF compiler" that also monitors related
DNS zones and autonomously re-compiles on change.)

> The current language of RFC 4408 paragraph 10.1 does comprehensively
> limit the total number of DNS lookups and there is no validated
> 'attack path'.

Attack paths can be considered definitely over-exaggerated liberties
being taken by a publisher, in this context.

The point is how do we tell when a publisher crosses the line, when it
exaggerates, at what point the publisher's convenience isn't worth the
price it puts.  I see two choices:

1:  The standard specifies exactly where the line lies.

2:  The standard just says there has to be a line.

#1 is apparently what you like and what RFC 4408 might be considered
to be stating.  #2 is somewhat softer.  For a comparison with DKIM,
consider the recommended signature content list: the result of a
verification may depend on local verifier's settings.

> 4408bis needs to clearly define what records will raise errors.
> SPF record publishers need to have confidence that their records
> will be processed reliably by both 4408 and 4408bis compliant
> check_host() implementations.

If the WG decides to go for choice #2 above, more latitude is left to
verifiers.  The 10-10-10 rule lives in security considerations, and we
can leave it there, add more considerations aimed at avoiding to
damage 3rd parties' DNS servers, and whatever, but make it clear that
local verifier policies may determine error conditions arbitrarily.

It is also possible to do both choices.  That is, specify exactly
where the most lenient line lies, while strongly recommending that
stricter limits be implemented.  In this case, I'd suggest that the
mandated "hard" line be expressed in terms simpler than 10-10-10.

> I do not believe it's possible to rewrite the limits the way you
> have proposed without losing backward compatibility.

It is possible, as it can be left to implementations to trace the
line.  The 10-10-10 behavior may still be suggested not normatively,
as it currently stands.

> Would you please propose some text that might be suitable for
> inclusion in a 4408bis draft (if we had one) that explains your
> proposal?

That's probably useless.  At this stage, it may be enough that the WG
understands what that choice is and possibly makes a decision.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 11 Mar 2012 17:16:13 -0400

> understands what that choice is and possibly makes a decision.

AIUI, the only choice you are offering is if we want to define an interoperable 
set of requirements for record publishers and processors.  I seriously hope we 
care about interoperabliity.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 07:24:14 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Sunday, March 11, 2012 7:21 AM
> To: [email-masked]
> #1 is apparently what you like and what RFC 4408 might be considered to
> be stating.  #2 is somewhat softer.  For a comparison with DKIM,

My problem with #2 is that from one SPF verifier to the next, the results are inconsistent.

(That's actually a problem with both of them given the random quality of ordering in DNS replies, but it's even more fuzzy when you don't have any guidance on where the line should be.)

As I think Scott mentioned elsewhere in the thread, there are ways to get around this even if the set of outbound IPs is known even if the set is somewhat large.  Maybe what we need to do is include a description of that mechanism and when it might be used.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Mar 2012 15:07:34 -0700

Dear SPFbis wg,

Conversations related to spf/txt records and general assumptions about 
potential DDoS concerns have been reviewed.  It seems limits for name 
and no data errors represent a compatible solution for resolving 
concerns related with the distributed nature of email, but it is not 
clear what conclusions have been reached.

Email remains heavily abused.  The initial impetus behind SPF was to 
deal with problems created when recipient validation followed message 
acceptance.  Since then such acceptance has become an unsustainable 
practice with increased network consumption from additional abuse that 
this invites, even when invalid recipients are silently dropped.  It 
would also be illogical to assume MTAs would be primary targets of abuse 
being the vehicle of distribution.

SPF leverages resources of the recipient to instantiate multiples of DNS 
transactions that might be measured in the hundreds.  The actual number 
depends upon whether spf/txt are done in parallel and whether EHLO and 
MFROM identities are also checked.  It should also be noted negative 
caching compliance is one of DNS's shortcomings.  A limit of 10 no data 
and name errors should not impact legitimate SPF records.

Any problems related to NS record referrals can be addressed with 
changes to the DNS protocol.  As such, SPF is different.  Those that 
could be affected by SPF may not offer any spf/txt resource records and 
universally use DNS that imposes strict limits on NS referrals.

It seems more productive to wait for proposed text to assess the 
situation, rather than arguing specific points in isolation.

Regards,
Douglas Otis

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Mar 2012 11:44:32 -0700

On 3/6/2012 9:27 AM, Scott Kitterman wrote:
> it is silent on this type of limitation.

I don't recall seeing the general issue raised, but I easily could have missed it:

In talking about possible changes to the specifications and the degree to which 
there is installed base that uses the existing text, it's worth distinguishing 
between:

      1.  Changes to the syntax or semantics of the SPF DNS records.  These 
affect what the owner of the associated domain intends or has to do;

      2.  Changes to the use of DNS records at the SMTP server side.

It is possible to have no changes in either the bits in the DNS record or the 
formal interpretion of them, but still have the consumer of the bits -- 
processing at the SMTP-server's side -- be different.

The scope of effect for #1 is quite broad.

The scope of effect for #2 is less broad.  Of course there is still a big 
difference between changes of this type that are entirely incompatible with 
whatever installed base in using the existing spec, versus changes that permit 
the old behavior continue.

I thought it worth highlighting this issue, for our considerations of changes 
that have greater or lesser effects on the installed base.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net