Mailing List Archive: SPF: Discuss

[Fwd: Re: DNSOP Agenda for San Diego (IETF 67)]

1 2

View All

Index | Next | Previous | View Threaded

nobody at xyzzy

Oct 30, 2006, 5:56 PM

Post #1 of 26 (7242 views)
Permalink

[Fwd: Re: DNSOP Agenda for San Diego (IETF 67)]

For info - I vaguely recall that William is going to IETF 67.

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

william at elan

Oct 30, 2006, 6:11 PM

Post #2 of 26 (7032 views)
Permalink

Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

Yes, I noticed. Provide list of appropriate rebutal points and I'll make
it after the presentation.

Also Doug recently brought this up on nanog (mail list), so something
needs to be posted there too (I was planning to last week but never got
around to posting). As much as I hate to actually bother responding to
typical Doug anti-SPF behavior [and he's mostly along contuinuing to
bring it up], I think it might be easier to just have mail list post
(or wiki page) to point people to from other forums where he mentions it.

On Tue, 31 Oct 2006, Frank Ellermann wrote:

> For info - I vaguely recall that William is going to IETF 67.
>
> Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

nobody at xyzzy

Oct 30, 2006, 9:31 PM

Post #3 of 26 (7030 views)
Permalink

Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

william(at)elan.net wrote:

> Provide list of appropriate rebutal points and I'll make
> it after the presentation.

For a start see the corresponding thread on the DKIM list:
<http://permalink.gmane.org/gmane.ietf.dkim/6299>

But that's incomplete, and I didn't have the patience to
go through it again. He deliberately uses vague terms as
distraction from the fact that 10*10 is _the_ worst case,
with precisely two variations, 10 mx or 9 mx + 1 ptr.

Replace one by something else and you get 9 * 10 + 1, or
replace two to get 8 * 10 + 2, etc.

For the 10 * 10 scenario the attacker obviously gets the
remaining queries (111 - 100 = 11, if you add the SPF RR
it's 112 - 100 = 12).

So far it's clear, the 1 TXT (policy) + 10 MX (attacker)
+ 100 A (NXDOMAIN) answers should be cached by the target
after one mail. Another point where he's intentionally
vague, talking about a single mail, as if sending more
could make it worse. But he somehow uses %l in his case,
I'm unsure how that affects his scenario.

That's where the TTL considerations begin, and I'm unsure
how that works. The attacker can pick the TTL for the
bogus policy and the bogus MX records. The attacker also
picks the %l if that means anything.

> As much as I hate to actually bother responding to typical
> Doug anti-SPF behavior [and he's mostly along contuinuing
> to bring it up], I think it might be easier to just have
> mail list post (or wiki page) to point people to from
> other forums where he mentions it.

Yes, e.g. I've no clue how he arrives at numbers like his
"factor 2000". The factor 100 in a rather convoluted
scenario with one policy and ten MX, each with 10 names in
the domain of the victim, is clear. I don't get how his
scenario arrives at more than 100 plus 11 queries to the
name server(s) of the attacker - in other words an attacker
has to answer quite a lot of queries, and based on that it's
"only" a factor 10.

Frank (a related off list mail arrived, thanks)

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 30, 2006, 10:06 PM

Post #4 of 26 (7047 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

In <4546DF94.617F [at] xyzzy> Frank Ellermann <nobody [at] xyzzy> writes:

> william(at)elan.net wrote:
>
>> Provide list of appropriate rebutal points and I'll make
>> it after the presentation.
>
> For a start see the corresponding thread on the DKIM list:
> <http://permalink.gmane.org/gmane.ietf.dkim/6299>

Yeah, I saw that, but your response doesn't really apply to the
example that DougO gave in his I-D.

From what I can tell, the only thing that DougO's I-D deals with that
wasn't already been mentioned on this list before MARID started was
the use of longer domain labels on the MX records. (I used long
domain names in other DoS scenarios, but not the MX case.)

I was the first to really raise the issue of SPF and DoS attacks in
late 2003, and I have been the only one who has really pushed the
issue in the SPF community. (The lack of DoS resistant process limits
was one of the major reasons I started my schlitt-spf-classic I-D.)

I dunno. If the only two people who think the DoS issues with SPF are
worth worrying about are DougO and me, then maybe I've just screwed up
my analysis and am worrying about a non-issue. It would probably be
best if someone besides me did the analysis to see if Doug is right or
not. I would hope that a good starting place would be to review some
of my posts on the subject over the last 3 years.

Contrary to DougO's doom-and-gloom assessment of SPF, I suspect that
*IF* he has actually found something, the right thing to do would be
to simply limit the total number of DNS lookups. This is allowed
under RFC4408, as is rejecting SPF records that are too long.
(Another thing that DougO mentions in his I-D.)

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

nobody at xyzzy

Oct 30, 2006, 11:49 PM

Post #5 of 26 (7033 views)
Permalink

Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

wayne wrote:

> Yeah, I saw that, but your response doesn't really apply to the
> example that DougO gave in his I-D.

It's really hard to find the substance in his idiosyncratic weasel
words, so if you found it please explain it in something remotely
related to plain text. E.g. where does his "2000" come from ?

> the use of longer domain labels on the MX records

The length of domain labels ? Are we talking about bytes in his
factor 2000 story ?

> I have been the only one who has really pushed the issue in the
> SPF community. (The lack of DoS resistant process limits was one
> of the major reasons I started my schlitt-spf-classic I-D.)

Yes, I recall that, and of course you weren't alone, it's more like
the precise reason why "the community" changed horses in the battle,
because Mark's I-D didn't address that point, and he also didn't
indicate that he's willing to fix it a.s.a.p.

BTW, it was also discussed later again with Radu.

> If the only two people who think the DoS issues with SPF are worth
> worrying about are DougO and me, then maybe I've just screwed up
> my analysis and am worrying about a non-issue.

For normal usage everything is fine. For an attack it might need
somewhat tighter limits in the triple ten formula. You were never
alone with this issue, at least I'm interested.

> I would hope that a good starting place would be to review some
> of my posts on the subject over the last 3 years.

I'm not that interersted to dig in articles posted before May 2004,
for anything later I've read it (and discussed it, it took us some
days to arrive at the triple-ten-limit after the MARID-termination).

> *IF* he has actually found something, the right thing to do would
> be to simply limit the total number of DNS lookups. This is
> allowed under RFC4408

Almost recommended, there's a "SHOULD limit the amount of data",
but the MUST-hard limits are 10/10/10. Maybe that could be tuned
in a 4408bis: Are more than say two mx mechanisms per SPF record
realistic / necessary ?

A limit of two "mx" per record would result in at most seven "mx"
with three include or redirect. Not very convincing, 70 queries
isn't much better than 100. We could use a total limit of queries:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/10950>

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

stuart at bmsi

Oct 31, 2006, 7:57 AM

Post #6 of 26 (7014 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, 31 Oct 2006, Frank Ellermann wrote:

> A limit of two "mx" per record would result in at most seven "mx"
> with three include or redirect. Not very convincing, 70 queries
> isn't much better than 100. We could use a total limit of queries:

I had a limit of 50 DNS queries total in pyspf, before the 10/10/10
rule went down. The most queries I've ever encountered for a real SPF
record was 76.

IMO, a simple limit for total queries was much simpler and easier
to implement than what we have.

Limiting SPF traffic to UDP queries also caps the total bytes.

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

alex at ergens

Oct 31, 2006, 8:07 AM

Post #7 of 26 (7028 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, Oct 31, 2006 at 10:57:55AM -0500, Stuart D. Gathman wrote:

> Limiting SPF traffic to UDP queries also caps the total bytes.

TXT "v=spf1 -all"
TXT "other protocol", total some 200 bytes (reasonable)
TXT "yet other protocol", total some 200 bytes (reasonable)
TXT "still other protocol", total some 200 bytes (reasonable)

together: > 611 bytes, which is more than 512, thus uses TCP.

This SPF record doesn't get any shorter.

Let's face it. Waiting for the type99 record was good, but also
allowing txt records (and worse: promoting to use TXT records)
may have been a mistake.

Alex

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

stuart at bmsi

Oct 31, 2006, 8:22 AM

Post #8 of 26 (7015 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, 31 Oct 2006, Alex van den Bogaerdt wrote:

> On Tue, Oct 31, 2006 at 10:57:55AM -0500, Stuart D. Gathman wrote:
>
> > Limiting SPF traffic to UDP queries also caps the total bytes.
>
> TXT "v=spf1 -all"
> TXT "other protocol", total some 200 bytes (reasonable)
> TXT "yet other protocol", total some 200 bytes (reasonable)
> TXT "still other protocol", total some 200 bytes (reasonable)
>
> together: > 611 bytes, which is more than 512, thus uses TCP.

And thus would result in 'None' for pyspf (unless a type99 was available)
- it would simply refuse to use TCP.

> Let's face it. Waiting for the type99 record was good, but also
> allowing txt records (and worse: promoting to use TXT records)
> may have been a mistake.

I publish and check type99 records - and encourage others to do the same.

RFC lawyer question: 4408 says I SHOULD limit the size of DNS queries.
Fine - I do that. But what should the result be when the size is exceeded?
None? TempError?

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 31, 2006, 8:23 AM

Post #9 of 26 (7021 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

In <20061031160701.GZ6130 [at] ergens> Alex van den Bogaerdt <alex [at] ergens> writes:

> On Tue, Oct 31, 2006 at 10:57:55AM -0500, Stuart D. Gathman wrote:
>
>> Limiting SPF traffic to UDP queries also caps the total bytes.
>
> TXT "v=spf1 -all"
> TXT "other protocol", total some 200 bytes (reasonable)
> TXT "yet other protocol", total some 200 bytes (reasonable)
> TXT "still other protocol", total some 200 bytes (reasonable)

No, those other protocols are *NOT* reasonable. They, like SPF, need
to be able to redirect to another record if the TXT record space at
the domain level gets congested. Protocols that require large TXT
records, such as domainkeys, need to put them at a subdomain level.
That is, instead of a TXT record at gmail.com, it needs to use
_domainkeys.gmail.com.

After 20 years of use, there appears to be only a few protocols that
use TXT records at the domain level. At the rate that the TXT space
is being used up, it will be many decades, if not a century, before
there is any sort of problem.

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 31, 2006, 8:34 AM

Post #10 of 26 (7017 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

In <Pine.LNX.4.44.0610311049530.5676-100000 [at] bmsred> "Stuart D. Gathman" <stuart [at] bmsi> writes:

> I had a limit of 50 DNS queries total in pyspf, before the 10/10/10
> rule went down. The most queries I've ever encountered for a real SPF
> record was 76.

There needs to be a limit of 10 mechanisms anyway since, if I recall
my DoS study results correctly, it is having more creates a too large
of an amplification factor. DougO's attack utilizes DNS label
compression to keep the single MX lookup relatively small while
generating large individual A record lookups directed toward the
victim. Impossible to compress lookups can easily be created with
simple include: or a: mechanisms.

> IMO, a simple limit for total queries was much simpler and easier
> to implement than what we have.

Yes, a limit on the total number of DNS lookups is simpler for the
implementation than the 10/10/10 rule. It is, however, much harder to
count by eye.

And, while the total number of DNS lookups is simplier, it isn't
really the critical thing, it is the total number of bytes thatis
really important.

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 31, 2006, 8:42 AM

Post #11 of 26 (7015 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

In <Pine.LNX.4.44.0610311116540.5676-100000 [at] bmsred> "Stuart D. Gathman" <stuart [at] bmsi> writes:

>> Let's face it. Waiting for the type99 record was good, but also
>> allowing txt records (and worse: promoting to use TXT records)
>> may have been a mistake.
>
> I publish and check type99 records - and encourage others to do the same.

I agree that encouraging the publication of TYPE99/SPF records is
probably useful, but I'm not at all convinced that checking for them
is a good idea.

Or, at least checking for both is probably a bad idea, especially if
you are doing those checks on include: mechanisms. That just makes
the DoS problem worse, not better.

Until such time as there is a non-trivial number of TYPE99/SPF
records, I think that checking for them is at least mildly abusive.

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

julian at mehnle

Oct 31, 2006, 9:10 AM

Post #12 of 26 (7027 views)
Permalink

Re: Processing limits (was: DNSOP Agenda for San Diego (IETF 67)) [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
> Stuart D. Gathman writes:
> > IMO, a simple limit for total queries was much simpler and easier
> > to implement than what we have.

I've long been for a total queries limit. After all, it is, among other
things, the number of queries that we want to limit, so that is what
should have actually been limited.

> Yes, a limit on the total number of DNS lookups is simpler for the
> implementation than the 10/10/10 rule. It is, however, much harder to
> count by eye.

True, but so are single atoms, and still they are being used with precision
in modern technology. Writing a lookup counter tool isn't hard. There's
no need for stuff to be counted by eye.

> And, while the total number of DNS lookups is simplier, it isn't
> really the critical thing, it is the total number of bytes thatis
> really important.

Right. Such a limit should also have been specified (as opposed to merely
suggesting it) in order to maintain (mostly) deterministic results. (Yes,
I know, the contents of DNS replies aren't exactly deterministic.)

Always impose limits on that which you actually want to limit.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFR4N3wL7PKlBZWjsRAh0qAJ9snGFMDtURZ/bQMrUnVCsBTrhGfQCgmGIE
BcY3/a8mz85h8rgrNgpwT+U=
=qCeA
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 31, 2006, 9:32 AM

Post #13 of 26 (7019 views)
Permalink

Re: Re: Processing limits (was: DNSOP Agenda for San Diego (IETF 67)) [In reply to]

In <200610311710.15161.julian [at] mehnle> Julian Mehnle <julian [at] mehnle> writes:

> Wayne Schlitt wrote:
>> Yes, a limit on the total number of DNS lookups is simpler for the
>> implementation than the 10/10/10 rule. It is, however, much harder to
>> count by eye.
>
> True, but so are single atoms, and still they are being used with precision
> in modern technology. Writing a lookup counter tool isn't hard. There's
> no need for stuff to be counted by eye.

The idea of SPF being easy to for people to publish, even if it makes
for more work for implementations has been a key concept since near
the beginning. If you want something that requires makes use of
things other than TXT records and gives the trade off toward
easy-of-implementation, you should have backed RMX, DMP, FSV or
CallerID, not SPF.

I think it is clear that Meng made the right trade off here and that
using TXT records, a simple language that could be easily created and
checked by hand was key to the success of SPF over those other
systems.

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

wayne at schlitt

Oct 31, 2006, 9:48 AM

Post #14 of 26 (7018 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

In <20061031173753.89F928B70E [at] chiclet> Scott Kitterman <scott [at] kitterman> writes:

> I think this is all much ado about nothing.
>
> First, nothing requires any to do SPF checks. A truly well engineered
> integration of SPF would degrade gracefully and bail out on SPF checks if
> resource usage get to be to great.

You have *COMPLETELY* missed the point.

This is *NOT* about SPF publisher or SPF checker attacks.

This is about *THIRD PARTY* attacks.

People who neither publish, nor check SPF records.

You can not "gracefully bail out".

*sigh*

> While the lack of anybody doing such a DOS attack does not entirely refute
> the argument, I do think that if this was easy, we'd have seen it by now.

Uh, no, it is pretty clear that 1) most people don't understand the
issue, and 2) DougO is working hard to make it so people do.
Unfortunately, because it is DougO, most clueful technical people tune
him out, so the only people who will likely pay any real attention to
him are bad buys.

> I'm not saying it's not a risk, but that I think it can be managed.

How?

-wayne

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

scott at kitterman

Oct 31, 2006, 10:20 AM

Post #15 of 26 (7025 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

I think this is all much ado about nothing.

First, nothing requires any to do SPF checks. A truly well engineered
integration of SPF would degrade gracefully and bail out on SPF checks if
resource usage get to be to great. A competent admin will do this manually
as soon as they are alerted to the problem. So, worst case this is a
potential issue for integrators and admins to be aware of.

While the lack of anybody doing such a DOS attack does not entirely refute
the argument, I do think that if this was easy, we'd have seen it by now.

I'm not saying it's not a risk, but that I think it can be managed.

IIRC, when I was arguing with Radu about this, much of the amplification
potential related to pipelining (particularly unauthorized pipelining that
starts before the SMTP greeting). I know that both Sendmail and Postfix
have controls to protect against this kind of abuse.

There is no box on the internet that cannot be DOSed today through one or
another mechanism. Defense against DOS attcaks requires active effort.
SPF is no different in that regard.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

scott at kitterman

Oct 31, 2006, 10:20 AM

Post #16 of 26 (7022 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, 31 Oct 2006 11:48:35 -0600 wayne <wayne [at] schlitt> wrote:
>In <20061031173753.89F928B70E [at] chiclet> Scott Kitterman
<scott [at] kitterman> writes:
>
>> I think this is all much ado about nothing.
>>
>> First, nothing requires any to do SPF checks. A truly well engineered
>> integration of SPF would degrade gracefully and bail out on SPF checks
if
>> resource usage get to be to great.
>
>You have *COMPLETELY* missed the point.
>
>This is *NOT* about SPF publisher or SPF checker attacks.
>
>This is about *THIRD PARTY* attacks.
>
>People who neither publish, nor check SPF records.
>
>You can not "gracefully bail out".
>
>
>*sigh*
>
>
>> While the lack of anybody doing such a DOS attack does not entirely
refute
>> the argument, I do think that if this was easy, we'd have seen it by now.
>
>Uh, no, it is pretty clear that 1) most people don't understand the
>issue, and 2) DougO is working hard to make it so people do.
>Unfortunately, because it is DougO, most clueful technical people tune
>him out, so the only people who will likely pay any real attention to
>him are bad buys.

OK. I'm in the midst of a power outage right now and doing e-mail on my
phone. Doug's text is hard enough to parse on a full size screen. I'm not
even going to try on my phone. I'll go look at it again after the power
comes back.

I guess I was defending against the wrong attack as what I described was,
IIRC, Radu's threat. I'll accept that Doug's is different and go look
again.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

julian at mehnle

Oct 31, 2006, 11:01 AM

Post #17 of 26 (7011 views)
Permalink

Re: Processing limits [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne wrote:
> The idea of SPF being easy to for people to publish, even if it makes
> for more work for implementations has been a key concept since near
> the beginning. If you want something that requires makes use of
> things other than TXT records and gives the trade off toward
> easy-of-implementation, you should have backed RMX, DMP, FSV or
> CallerID, not SPF.
>
> I think it is clear that Meng made the right trade off here and that
> using TXT records, a simple language that could be easily created and
> checked by hand was key to the success of SPF over those other
> systems.

How does using tools for checking against security limits conflict with
easy deployment?

Do you really think that people like to count DNS lookups against the 111
limit "by eye" for any but the most trivial cases? Would that limit
become "un-SPF-ish" and should be removed as soon as using an automatic
checker becomes more convenient than counting by eye?

Sorry, I can't follow your argument.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFR52QwL7PKlBZWjsRAovjAJ4565mw9ixELpApx9Zugy538EgVvACgpUvK
dKagCi591b0NR9KMJNpFN/g=
=ZJNu
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

alex at ergens

Oct 31, 2006, 12:55 PM

Post #18 of 26 (7021 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, Oct 31, 2006 at 10:42:14AM -0600, wayne wrote:

> >> Let's face it. Waiting for the type99 record was good, but also
> >> allowing txt records (and worse: promoting to use TXT records)
> >> may have been a mistake.
> >
> > I publish and check type99 records - and encourage others to do the same.
>
> I agree that encouraging the publication of TYPE99/SPF records is
> probably useful, but I'm not at all convinced that checking for them
> is a good idea.
>
> Or, at least checking for both is probably a bad idea, especially if
> you are doing those checks on include: mechanisms. That just makes
> the DoS problem worse, not better.

Why?

If a type99 SPF record is found, don't even start looking for TXT.

> Until such time as there is a non-trivial number of TYPE99/SPF
> records, I think that checking for them is at least mildly abusive.

But looking for SPF, which has its own record type, should cause
a transfer of all TXT records eventhough there is a type99 record
available? I could argue that this would be mildly abusive.

What's the point in publishing type SPF if the majority of all
clients is going to fetch TXT records anyway?

Alex

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

scott at kitterman

Oct 31, 2006, 1:10 PM

Post #19 of 26 (7012 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

OK, power's back on here.

I read Doug's draft again.

http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt

I agree. I still don't get it.

Some of what he said is right. Some of what he said is stuff you could do,
but is nonsense. Part of what he said is specifically contrary to 4408 (he
talks about implementations that do not have processing limits).

Is the idea that some bad actor can cause a third party to have their DNS
DOSed by sending mail to receivers that check SPF and have them do a bunch of
lookups against the 3rd party?

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

william at elan

Oct 31, 2006, 3:27 PM

Post #20 of 26 (7013 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, 31 Oct 2006, Scott Kitterman wrote:

> OK, power's back on here.
>
> I read Doug's draft again.
>
> http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt
>
> I agree. I still don't get it.
>
> Some of what he said is right. Some of what he said is stuff you could do,
> but is nonsense. Part of what he said is specifically contrary to 4408 (he
> talks about implementations that do not have processing limits).
>
> Is the idea that some bad actor can cause a third party to have their DNS
> DOSed by sending mail to receivers that check SPF and have them do a bunch of
> lookups against the 3rd party?

The idea is that a bad 3rd party [attacker] would create specifically
crafted dns records that redirect or point to victim in various ways,
that 3rd party would then send email to various SPF-checking places
which would look up these records and do lots of lookups to victim's
dns servers, i.e. DoS.

--
William Leibzon
Elan Networks
william [at] elan

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

stuart at bmsi

Oct 31, 2006, 7:27 PM

Post #21 of 26 (7065 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tue, 31 Oct 2006, Alex van den Bogaerdt wrote:

> If a type99 SPF record is found, don't even start looking for TXT.

I wish it were that simple. Too many (braindead) DNS servers timeout
when presented with a type99 query. The obvious algorithm of checking
type99 first, then check TXT if not found is unworkable thanks to these
antisocial beasts.

It might be useful to keep a cache of which DNS servers are braindead
(timeout on type99).

--
Stuart D. Gathman <stuart [at] bmsi>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

nobody at xyzzy

Oct 31, 2006, 8:47 PM

Post #22 of 26 (7005 views)
Permalink

Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

Stuart D. Gathman wrote:

> RFC lawyer question: 4408 says I SHOULD limit the size of DNS queries.
> Fine - I do that. But what should the result be when the size is
> exceeded? None? TempError?

When Wayne mentioned "always allowed" yesterday I checked what he's
talking about and found this SHOULD (= "recommends"). From the context
I think it should be TempError, same idea as for the 20 seconds limit.

Kind of odd because it won't go away by trying again later without
manual intervention. If we want a PermError for "excessive amounts
of data" (unspecified) we should note it as erratum.

In another article you mentioned 76. IIRC that was the RR case before
they simplified their policy. It was not within the 10/10/10 limits.

To damp Doug's attack without counting bytes (shudder) maybe a total
limit of about 40 queries (10 mechanisms + 30 names) would do, or is
that too liberal / too conservative ?

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

scott at kitterman

Oct 31, 2006, 8:55 PM

Post #23 of 26 (7013 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Tuesday 31 October 2006 23:47, Frank Ellermann wrote:

> To damp Doug's attack without counting bytes (shudder) maybe a total
> limit of about 40 queries (10 mechanisms + 30 names) would do, or is
> that too liberal / too conservative ?

I think that's on the right track.

The problem as I understand it is that some IP addresses on shared hosts have
huge numbers of PTR records. The number of names returned with PTR is
generally beyond the control of the domain owner unless they have exclusive
use of the IP (which isn't what we are talking about here).

I'd be tempted to go for something like that, but I think you have to process
MX before PTR if they count against the same limit. This would add to why
PTR is unreliable.

I'd be more inclined to set the MX limit to 20 total for all MX mechanisms and
just leave PTR at one (don't use PTR unless the IP only has one name
associated and it's the one you want).

Dunno. We have a while to think about it.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

nobody at xyzzy

Oct 31, 2006, 9:33 PM

Post #24 of 26 (7011 views)
Permalink

Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

Scott Kitterman wrote:

> Is the idea that some bad actor can cause a third party to have their DNS
> DOSed by sending mail to receivers that check SPF and have them do a bunch
> of lookups against the 3rd party?

Yes. You need a list of receivers checking SPF, or you'd just fire blindly
hoping to hit SPF checkers. You need a nameserver for the policy and the
bogus MX records. All those MXs claim to have names like {random}.kitterman
and the reply doesn't contain their IPs in the additional section.

Therefore the SPF clients start to query you for {random}.kitterman hosts.
100 queries per client triggered by one mail. The setup needs to be more
convoluted if the same client asks you again, maybe using various policies
for subdomains and/or MX records depending on local parts. Obviously the
attacker gets about 1/11 of the queries, 10/11 go to the victim.

If we'd limit "indirect" A-queries (triggered by "mx" or "ptr") to 30 per
evaluation we'd get 1/4 (attacker) vs. 3/4 (victim), a factor 3 instead of
10. I've no clue how Doug arrived at factors like 2000.

Frank

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

scott at kitterman

Oct 31, 2006, 9:49 PM

Post #25 of 26 (7000 views)
Permalink

Re: Re: [Fwd: Re: DNSOP Agenda for San Diego (IETF 67)] [In reply to]

On Wednesday 01 November 2006 00:33, Frank Ellermann wrote:

> If we'd limit "indirect" A-queries (triggered by "mx" or "ptr") to 30 per
> evaluation we'd get 1/4 (attacker) vs. 3/4 (victim), a factor 3 instead of
> 10. I've no clue how Doug arrived at factors like 2000.

I've a guess at where he got numbers like that, but this is a polite mailing
list, so I won't try and explain it.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss [at] v2

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads