To:
dnssec@cafax.se
From:
Paul Vixie <paul@vix.com>
Date:
Tue, 22 Jun 2004 00:31:34 +0000
In-Reply-To:
Message from Ben Laurie <ben@algroup.co.uk> of "Mon, 21 Jun 2004 16:10:01 +0100."<40D6FA49.3020901@algroup.co.uk>
Sender:
owner-dnssec@cafax.se
Subject:
Re: continued: rrsig(qtype)
> > Anything not getting DNSSEC into an RFC is a problem. Postponing
> > DNSSEC for another year by fixing this corner case of abuse is going
> > to give me a LOT more spam then the amount of spam I would get when
> > DNSSEC is deployed and people can start using things like SPF
> > records.
for the record, i do not expect spf to stop much spam, though it might
prevent some forgeries. but i've been told that i'm just bitter about
the ignorance of the FUSSP community and their reluctance to even bother
to read my own prior work in this area ("mailfrom"). but, we digress.
> Why is DNSSEC required for SPF?
the ways in which the traditional (non-secure) query model is vulnerable are:
1. an attacker can cause your query, or your response, to not be received.
2. an attacker can cause you to believe that nonauthentic data is authentic.
3. an attacker can cause you to believe that authentic data does not exist.
(that's roughly microburst ddos, query-id guessing, and query-id guessing.)
dnssec-bis proposes to solve #2 and #3.
several people concerned about zone walking are considering just solving #2.
at the moment, no public proposal claims to address #1.
forgetting zone walking for the moment, and therefore, forgetting the
distinction between #2 and #3, and sort of smashing them together into
a single lump, it's clear that any "dns-based antispam solution" which
is susceptible to #1 won't benefit from any sort of dnssec -- and might
as well not even be tried, since microburst-ddos can accompany spam runs
and all such filtering would do is increase pollution in the internet core.
therefore we're left with the #2/#3 blob. perhaps SPF is susceptible to #1,
and is something that will stop helping you whenever someone microbursts you.
that wouldn't surprise me but i really don't know.
there are however ways in which "authenticated and reachable" can be made
a prerequisite for inbound e-mail, such that attack #1 would cause delay but
no leaks or losses. in this sense, some form of DNSSEC could be wildly
helpful in deploying certain imaginable anti-spam solutions.