Re: continued: rrsig(qtype)

[Ben Laurie <ben@algroup.co.uk>]

Paul Vixie wrote:

>>>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.

Purely as an interim measure. I think we all agree that 2 & 3 should be 
solved.

> 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.

DNSSEC can certainly help with imaginable attacks against some proposed 
anti-spam solutions, but it isn't required for them.

BTW, I don't suppose I'll be all that upset if my spam is delayed, so 
the general form of the solution works for me. :-)

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff