Re: [Asrg] DKIM role?
2009-01-08 15:10:41
On Jan 5, 2009, at 7:22 AM, Ian Eiloart wrote:
--On 22 November 2008 08:43:21 -0500 Rich Kulawiec <rsk(_at_)gsp(_dot_)org>
wrote:
On Thu, Nov 20, 2008 at 02:33:51PM +0000, Ian Eiloart wrote:
The only thing that matters is that you can reach the system
administrator for the domain that sent the email. Then you can
assign reputation to the domain, and even to the email address used.
But you can do that today -- well, by IP address, at least, which
is (as we've seen from the use of DNSBLs) nearly always good enough
to make accept/deny decisions WRT email.
But that's not good enough. In fact it's crap. If I want to
whitelist an organisation, I can't do it because there's no
principled way in which I can know what IP address they're using to
send email. I need to be able to whitelist the domain. As long as
there's nothing to stop people spoofing the domain,
There are methods that can be used to limit risks related to
whitelisting domains. Often these involve capturing prior
conversations and noting where the message originated. The locations
might then be expanded to CIDRs, routes, or acquired address lists.
And *please* let's not try to assign reputations to individual
email addresses, as the scalability problems involved in N users
with M email addresses trying to track reputations of N users with
M addresses, given that N is on the order of 10e9, are awful.
While that might appear to represent an unreasonable number, dealing
with IPv6 might quickly exceed any reasonable magnitude when one
attempts to resolve to individual IP addresses. DKIM on the other
hand limits M to the number of DKIM signing domains with a reasonable
reputation, where the i= parameter (the user) will likely be needed to
deal with compromised or abused accounts which might be replayed.
You don't have to have centralised reputation management for that. I
can manage my own address based reputation database, once I know
that email from a given address really is coming from the owner.
Yes you could. There are also services related to this effort, such
as boxsentry, realmail which attempts to deal with the Asian and
Middle Eastern markets.
happens from there on is down to local policy - it'll depend on
whether the domain belongs to an ISP, a university, an individual,
or whatever. But, you'll be able to hold the domain admin
responsible for the email.
I see what you're saying but we can do this *today* by IP address
(and thus by extension) by network. In fact: we ARE doing it, and
have been for a long time. It works quite well, without the need
to invent and deploy any new technology.
Well, it kind of works, but really really poorly. I've had business
requests to whitelist certain domains and always resisted them
because whitelisting a domain would simply open a hole in my anti-
spamming measures.
One must include more than a few parameters in order to do this safely.
Given that it's trivially easy to change domains (spammers go
through them by the thousands, and ICANN seems quite intent on
making this even easier and cheaper for them)
That's irrelevant to whitelisting. And, reputation is earned so new
domains have to work to build reputation.
Agreed. In fact it would seem that email must start heading in the
direction of white-listing. Such a direction however is politically
problematic since this suggests email would no longer represent an
open system. One method that might be tried would be for the network
providers to register the routes they monitor for abuse related to
various public protocols. Then at least only those routes would need
to assessed, where the reputation of the network provider. This could
help sustain the open nature of email a bit longer.
but much more difficult to forge IP addresses and change networks,
it seems much better for anti-spam purposes to focus on addresses
and networks, and not on domains. But there's a more fundamental
problem at work here.
We have to take into account the presence of a few hundred million
0wned systems -- whose new owners have the ability to immediately
take possession of any authentication credentials used on them,
should it please them to do so.
Agreed. Only the network providers are truly in a position to
accurately monitor the abuse. Having some official open and public
body establish a registry as to what the network providers are willing
to protect should help. Currently, this is being done in
opportunistically, and often based upon poorly managed reverse DNS
address space that may not survive IPv6.
So although we frequently refer to spam as "the problem", it's not
the problem -- it's merely a symptom of the problem.
So, actually we've got two problems, given that SMTP has no
mechanism for assigning accountability. Sure, endpoint security
needs addressing, but part of the solution could be to reduce the
attraction of 0wning systems by preventing those systems from
spoofing sender addresses.
Any protocol has a mechanism for assigning accountability, BGP. :^)
Things like DKIM should help find those that have a vested interest in
preserving their reputations whenever the providers fail to curb
problematic accounts.
The problem is a serious and fundamental lack of security on a very
large number of network endpoints. That problem remains
unaddressed except in token fashion, which is why it continues to
get worse with no sign of any turnaround in the forseeable future.
(And multiple signs that it could get much worse, i.e., the
inclusion of DRM in popular OS releases, meaning they're pre-
compromised at the factory, so to speak.)
One wonders whether a class action suit might prove helpful. How long
must the Internet suffer from stodgy proprietary libraries supporting
hundreds of class structures in desperate need of recompilation, or
their merged settings which thwart untangling malware from critical
functions. There are operating systems that do not build in the means
to hide from fully privileged users, while still offering application
functionality to restricted users.
Sure, we could argue "go ahead and do it anyway", but I think
that's not a good idea. The enemy reads these lists and the RFCs
and the code, too, and has long since demonstrated the capacity to
wait until something's deployed, then begin to exploit it. This
is, by the way, one of my deep concerns with anti-forgery
technologies: it's my opinion that widespread deployment of one
will be followed shortly thereafter with widespread exploitation:
see "few hundred million 0wned systems" above, and note that the
absence of any reason to think that corporate or ISP or government
or university or any other networks are free of these.
Agreed. Any effort to consolidate accountability at the domain, which
ADSP or Sender-ID attempts, clearly enables the next generation of
victims where there is no practical mitigation. For this, there is a
large industry making Band-Aids. :^(
I'm worried that if we begin deploying technology that trains users
to believe that email is REALLY from who/where it claims to be
from, that they will eventually accept that training...at which
point forgeries become much more dangerous than they are now, when
we're training users never to believe that anything is from who/
where it claims to be.
That's bogus. They already do believe that, in my experience.
Huh?
I suspect the next accepted communication scheme will depend upon SSL
certified presences servers acting as gateway channels. SMTP will
likely fade when people get tried of deleting spam.
-Doug
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Asrg] DKIM role?,
Douglas Otis <=
|
|
|