Apart from the general undesirability of using IP addresses for
authentication -- and I've been writing about that for 15 years -- the
problem of authentication for anti-spam is ill-defined. In fact,
posing it as an authentication problem misses the point entirely.
In almost all circumstances, authentication is useful for one of two
things: authorization or retribution. But who says you need
"authorization" to send email? Authorized by whom? On what criteria?
Attempts to define "official" ISPs leads very quickly to the walled
garden model -- you have to be part of the club to be able to send mail
to its members, but the members themselves have to enforce good
behavior by their subscribers.
Retribution doesn't work very well, either -- new identities are very
easy to come by, and since most spammers are already committing other
illegal acts (ranging from the "products" they advertise to the systems
and address blocks they hijack) they're not easily dissuaded by laws.
Reasoning like this leads me to schemes that involve imposing cost. It
may be financial, it may be CPU cycles, it may be any of a number of
things. But it can't be identity based, except for recipient-based
whitelists, and they have their own disadvantages.
--Steve Bellovin, http://www.research.att.com/~smb
Reasoning like this leads me to schemes that involve imposing cost. It may be financial, it may be CPU cycles, it may be any of a number of things. But it can't be identity based, except for recipient-based whitelists, and they have their own disadvantages.
cost is good. the problem is convincing a reasonable user of smtp
that everything would work much better only if everything (for instance) took
longer (or cost more) to deliver. can you imagine the joy of debugging a problem-solving
challenge/response system? or better yet, getting *everyone* to switch out their client?
(and who would actively support "phasing out" smtp clients as they stand as long as it all
still worked? keep in mind that uucp is still alive and well because it actually works.)
only when the average joe hates spam enough that the cost to him justifies the effort
to him can it happen. right now, i think it's mostly tech geeks who get really amped up
about it. and of course, they view the cost to them as disproportionately high...
s.
Steve,
In almost all circumstances, authentication is useful for one of two
things: authorization or retribution. But who says you need
"authorization" to send email? Authorized by whom? On what criteria?
Authorized by the recipient or some delegee thereof, using whatever
algorithms and heuristics they chose. But based on data the authenticity of
which they can determine without it being trivially forgeable, and without
it being mixed up with the transport protocol. IE in much the same way as
say PGP, or BGP.
Attempts to define "official" ISPs leads very quickly to the walled
garden model -- you have to be part of the club to be able to send mail
to its members, but the members themselves have to enforce good
behavior by their subscribers.
I never said anything about "official" ISPs. I am attempting to draw an
analogy (and note the difference) between SMTP as currently deployed, and
the way this same problem has been solved many times for other well known
protocols.
We do not have an official BGP authorization repository. Or an official PGP
authorization repository. We just have people we chose to trust, and people
they in turn chose to trust. Take BGP (by which I mean eBGP) as the case in
point: It seems to be general held opinion that the one-and-only canonical
central repository for routes does not work well. The trust relationship is
important, and we expect some transitivity (no pun intended) in the trust
relationshipa to apply. And many end-users in the BGP case - i.e. stub
networks - chose to "outsource" their their trust to their upstream; when
they don't like how their upstream manages their routes, they move
provider. BGP allows me (in commonly deployed form) to run a relatively
secure protocol between peers, and deploy (almost) universal end-to-end
connectivity for IP packets in a manner that does not necessarily involve
end users in needing to know anything about it bar "if the routing doesn't
work, I move providers"; and IP packets do not flow "through" BGP, they
flow in manners prescribed by BGP. Replace BGP by "a mail authorization
protocol" and "IP packets" by "emails" in the foregoing; if the statement
still holds, we are getting there (without reverting to bangpaths &
pathalias). Oh, and people keep mentioning settlement and how it might fix
everything - people said the same about BGP (i.e. IP peering) - may be, may
be not - the market seems to have come up with all sorts of ingenious
solutions for BGP.
Alex
Alex Bligh wrote:
Steve,
> In almost all circumstances, authentication is useful for one of two
> things: authorization or retribution. But who says you need
> "authorization" to send email? Authorized by whom? On what criteria?
Authorized by the recipient or some delegee thereof, using whatever
algorithms and heuristics they chose. But based on data the authenticity
of
which they can determine without it being trivially forgeable, and without
it being mixed up with the transport protocol. IE in much the same way as
say PGP, or BGP.
> Attempts to define "official" ISPs leads very quickly to the walled
> garden model -- you have to be part of the club to be able to send mail
> to its members, but the members themselves have to enforce good
> behavior by their subscribers.
I never said anything about "official" ISPs. I am attempting to draw an
analogy (and note the difference) between SMTP as currently deployed, and
the way this same problem has been solved many times for other well known
protocols.
No it hasn't, and your comparison to BGP is very much about 'official ISPs'.
For starters your examples are not anywhere close to the same scale as the
SMTP 'problem', and are restricted to 'IN' players. The closest they get is
the blatant attempt to restrict SMTP to the privileged club of BGP speakers.
We do not have an official BGP authorization repository. Or an official
PGP
authorization repository. We just have people we chose to trust, and
people
they in turn chose to trust.
Where they specifically form a club and agree to preclude the basement
multi-homed site from participating through prefix length filters. This is
exactly like the thread comments about preventing consumers from running
independent servers by forced filtering and routing through the ISP server.
This is not scaled trust; it is a plain and simple power grab. Central
censorship is what you are promoting, but you are trying to pass it off as
spam control through a provider based transitive trust structure. Either you
are clueless about where you are headed, or you think the consumers won't
care when you take their rights away. Either way this path is not good news
for the future Internet.
Tony
Now there was me thinking that I was in general agreeing with you. I am not
promoting any sort of censorship, central or otherwise. I believe you have
a perfect right to open a port 25 connection to any server, and I have a
perfect right to accept or deny it. And of course vice-versa. What I am
saying is that I would like, in determining whether to accept or reject
your connection, to know who you are and that you act responsibly, or
failing that, to know someone who is prepared to vouch for you; failing
that, may be I'll accept your email anyway, may be I won't. I do not care
what upstream either you or I have. For the avoidance of doubt, I am not
talking about forcing people to send mail through their upstreams, or even
suggesting that the graph of any web of trust should follow the BGP
topology. Indeed the entire point I made about separating the web of
trust's topology from IP addresses etc. was rather to enable end users to
CHOOSE how they accept/reject mail in a manner that might have nothing to
do with network topology. Personally I would be far more happy accepting
mail from someone who'd been vouched for by (say) someone on this list I
knew, than vouched for by their quite possibly clueless DSL provider. Of
course some people will want to use their "ISP", many won't. Just like Joe
User can use their upstream's DNS service, but doesn't necessarily need to.
Maybe PGP would have been a better analogy as far as the scale bit goes. I
think you are assigning motives to the BGP basement-multihoming problems
where in general the main motive is not getting return on cost of hardware;
however, I don't think the same scale constraints need apply as it is
unnecessary to hold a complete table in-core at once.
Alex
Clearly I misinterpreted your comments; sorry for reading other parts of the
thread into your intent. The bottom line is the lack of a -scalable- trust
infrastructure. You are arguing here that the technically inclined could
select from a list of partial trust options and achieve 'close enough'.
While that is true, Joe-sixpack wouldn't bother even if he could figure out
how. Whatever trust infrastructure that comes into existence for the mass
market has to appear to be seamless, even if it is technically constructed
from multiple parts.
Steve Bellovin suggested earlier that identity based approaches wouldn't
work. While I agree having the identity won't solve the problems by itself,
it does provide a key that the rest of the legal system can start to work
with. False identities are common in the real world, so their existence in
the electronic world is not really any different. I guess I am looking at
this from the opposite side the two of you appear to be, rather than
requiring authorization to send, irrefutable identity should be used to deny
receipt after proven abuse.
Tony
From: Alex Bligh [mailto:alex@alex.org.uk]
Sent: Tuesday, February 17, 2004 4:48 PM
To: Tony Hain; 'Steven M. Bellovin'
Cc: nanog@merit.edu; Alex Bligh
Subject: RE: Clueless service restrictions (was RE: Anti-spam System Idea)
> Where they specifically form a club and agree to preclude the basement
> multi-homed site from participating through prefix length filters. This
> is exactly like the thread comments about preventing consumers from
> running independent servers by forced filtering and routing through the
> ISP server. This is not scaled trust; it is a plain and simple power
> grab. Central censorship is what you are promoting, but you are trying
to
> pass it off as spam control through a provider based transitive trust
> structure. Either you are clueless about where you are headed, or you
> think the consumers won't care when you take their rights away. Either
> way this path is not good news for the future Internet.
Now there was me thinking that I was in general agreeing with you. I am
not
promoting any sort of censorship, central or otherwise. I believe you have
a perfect right to open a port 25 connection to any server, and I have a
perfect right to accept or deny it. And of course vice-versa. What I am
saying is that I would like, in determining whether to accept or reject
your connection, to know who you are and that you act responsibly, or
failing that, to know someone who is prepared to vouch for you; failing
that, may be I'll accept your email anyway, may be I won't. I do not care
what upstream either you or I have. For the avoidance of doubt, I am not
talking about forcing people to send mail through their upstreams, or even
suggesting that the graph of any web of trust should follow the BGP
topology. Indeed the entire point I made about separating the web of
trust's topology from IP addresses etc. was rather to enable end users to
CHOOSE how they accept/reject mail in a manner that might have nothing to
do with network topology. Personally I would be far more happy accepting
mail from someone who'd been vouched for by (say) someone on this list I
knew, than vouched for by their quite possibly clueless DSL provider. Of
course some people will want to use their "ISP", many won't. Just like Joe
User can use their upstream's DNS service, but doesn't necessarily need
to.
they in turn chose to trust. Take BGP (by which I mean eBGP) as the case in
point: [...] The trust relationship is
important, [...]. BGP allows me (in commonly deployed form) to run
a relatively
secure protocol between peers, and deploy (almost) universal end-to-end
connectivity for IP packets in a manner that does not necessarily involve
end users in needing to know anything about it bar "if the routing doesn't
work, I move providers";
Right but:
- The world of BGP peers is a rarified one, there are, what, <20k
ASes out there? Nearly all are medium sized enterprises, institutions
or organisations or bigger.
- With BGP's peer-to-peer trust relationships, prefixes get hijacked,
rogue ASes collude with spammers.
So, despite the small number of players, it still doesnt work, and
people are working on adding stronger forms of verification of
announcements to to BGP.
And you want to try scale this to the millions and millions of SMTP
hosts? 
Alex
regards,