Subject: Re: [Asrg] DKIM role?

From: Ian Eiloart <[email-masked]>
Date: Mon, 05 Jan 2009 15:22:02 +0000

--On 22 November 2008 08:43:21 -0500 Rich Kulawiec <[email-masked]> 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, the

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

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.

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

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

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

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

>
> ---Rsk
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/asrg

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/asrg

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Jan 2009 12:10:23 -0800

On Jan 5, 2009, at 7:22 AM, Ian Eiloart wrote:
>>> 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.
>
> 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.
>>
>> 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, 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.
>

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

---

From: SM <[email-masked]>
Date: Thu, 08 Jan 2009 12:43:58 -0800

>might then be expanded to CIDRs, routes, or acquired address lists.

Is it that important to note where the message originated?  Although 
the where is commonly used as input for lack of a better reference 
point, it can be a problem when renumbering a network or for mobility.

Did this message reach you because:

  1. it came from the irtf.org domain

  2. it came from the ASRG email address

  3. it came from an IP address associated with 1 or 2

  4. it came from a CIDR block you view as "safe"

Regards,
-sm

P.S. You may decide not to answer the above question to limit the 
risks related to whitelisting.

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 09 Jan 2009 11:22:51 +0000

--On 8 January 2009 12:10:23 -0800 Douglas Otis <[email-masked]> 
wrote:

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

"Greylisting"? Or something similar. Well, perhaps, but it seems 
complicated compared with SPF. I don't understand why there are banks that 
don't publish SPF records, for example. And, I'd like to be able to 
whitelist all .ac.uk domains when there's an SPF or DKIM match. Why? Well, 
I know that the domains are hard to register, that they have a relationship 
with my organisation, and as a rule I'll be able to contact a competent 
administrator if something goes wrong.

The advantage of DKIM and SPF, of course, is that I don't have to guess 
about anything technical - like which IP addresses belong to a domain.

....

-- 
Ian Eiloart
IT Services, University of Sussex
x3148
_______________________________________________
Asrg mailing list
[email-masked]
http://www.irtf.org/mailman/listinfo/asrg

---

From: Franck Martin <[email-masked]>
Date: Sat, 10 Jan 2009 01:54:14 +1200 (FJT)

The beauty of DKIM is that the a federation of University could provide a DKIM signature for all UK education centers. Ensuring you are dealing with properly registered education centers.

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 9 Jan 2009 09:59:07 -0500

On Sat, Jan 10, 2009 at 01:54:14AM +1200, Franck Martin wrote:

>The beauty of DKIM is that the a federation of University could
>provide a DKIM signature for all UK education centers. Ensuring you
>are dealing with properly registered education centers.

What would such a DKIM signature look like?

-- 
Jeff Macdonald
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Jan 2009 09:44:11 -0800

On Jan 8, 2009, at 12:43 PM, SM wrote:

>> conversations and noting where the message originated.  The  
>> locations might then be expanded to CIDRs, routes, or acquired  
>> address lists.
>

White-listing based upon a domain would be dangerous without also  
including the IP address of the SMTP client and message tracking.   
There are companies currently providing this service, particularly  
needed where spam remains largely unmanaged.

> 4. it came from a CIDR block you view as "safe"

The algorithm can remain oblivious to who owns the SMTP client.  It  
determines whether a conversation was observed, while also allowing  
also users to submit corrections.

A reduction in the false positive detection of spam is achieved  
through conversation tracking.  Some exceptions are needed to  
accommodate one-way traffic, which often represents transactional  
notifications.  There are services doing this today by using two tiers  
of information.

-Doug

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 12 Jan 2009 10:29:26 +0000

--On 9 January 2009 09:44:11 -0800 Douglas Otis <[email-masked]> 
wrote:

> including the IP address of the SMTP client and message tracking.  There
> are companies currently providing this service, particularly needed where
> spam remains largely unmanaged.
>

Absolutely. That's the point of SPF and DKIM. The reason that I don't 
whitelist sender domains or addresses is that they're so easy to forge at 
the moment. With deployment of SPF and DKIM, there are domains that I'd be 
willing to whitelist given either a good SPF or DKIM match. In fact, there 
are top level domains like .edu, .gov, .ac.uk, .gov.uk, .sch.uk, .coop, and 
so on that I'd be prepared to conditionally whitelist because the 
registration process is tougher - though I might find myself making 
exceptions if certain subdomains didn't behave reasonably.