[Asrg] DKIM role?

[Douglas Otis]

On Jan 5, 2009, at 7:22 AM, Ian Eiloart wrote:
> --On 22 November 2008 08:43:21 -0500 Rich Kulawiec <rsk at gsp.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