[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] pre-rfc thought balloon: ESMTP DATA-CALLBACK (was ESMTP DATAFIRST)


On Jun 6, 2006, at 9:13 AM, william(at)elan.net wrote:
On Tue, 6 Jun 2006, Douglas Otis wrote:
On Tue, 2006-06-06 at 00:26 -0700, william(at)elan.net wrote:

It is not about malware - there are actually ways to get rid of it that
are fairly effective even now (most malware is easy to identify based
on common signatures).

But the filtering for the malware depends upon the DKIM signing domain.

Its not about DKIM or other signature scheme, you can identify malware right now quite effectively with existing tools and signatures I meant are not crypto but virus pattern recognition signatures (which only need to be tested against .exe and similar attachments). I'm also fairly certain 99.999...% of email users have learned enough directly or through friends to not open email attachments that need to be executed. We'd have to wait for some research measurements, but I'd not be surprised if virus infection rate through email is significantly on decline.

When the data is stored at the sender, no intermediary is able to "filter" this information based upon signatures. Many of today's viruses are also polymorphic and change rapidly. Client side filtering and precautions are required using this mode of delivery, placing a greater onus on the signing domain and the recipient. Parents still expect that their child will not damage their computer. Parental controls will need to limit access to specific trusted domains. DKIM verification clearly identifies who is being trusted. Business communications still place message security as a high priority which can also use the trust model.


The reputation of the DKIM signing domain must be good before attempting to access the data section. The other benefit of this approach is it will not require any DSNs. There is no need to bounce a message that is never transferred.

Yes and that is the main point of im2000 - don't get what you dont want.

With crypto signatures the overhead to calculate hash is actually a lot smaller then that required to do RSA, so in reality the crypto effort itself would be almost the same. But anything that can be done with non-crypto session authentication is going to have less overhead where as cryptographic public-key signatures offer most advantages when two end-nodes are not directly talking to each other.

Using the existing email infrastructure has several advantages. A transition to a store at the signing domain is appealing, but using SMTP for notification is not point to point. A few milliseconds per message signature checks does not appear to be an impediment.


The reality is that im2000 is generally alot better approach for email
infrastructure where you do not expect that every email would be
delivered.... The advantages are that it can offer:
1. More effective per-ip and per-domain filters which are similar
to current URI filters but here URL is that of data store.
SPF-like verification based on URL location starts to work
with no forwarding problems for multiple identities.

This is not a secure scheme. SPF "like" verification has a rather

SPF-like includes CSV is you prefer to hear that. And this has nothing to do about your opinion on possible dns overhead with SPF which has not shown up to be a problem, in fact this does not directly has to do with SPF either. The scheme I mention verifies not the incoming
server connection but location of the message store based on store address (for which in fact RMX or CSV would be better as far as their design but the reality is that people will use SPF anyway including for this). Very low overhead, effective and no forwarding side-effects.

When this is a transition using SMTP for notification, leveraging off of a suitable authentication scheme remains an important consideration. While SPF advocates often ignore possible packet amplification exploits, major networks have been brought to their knees by an DDoS exploit running at about 60x amplification. As it is now, SPF could easily achieve 300x while also thwarting ongoing efforts aimed at preventing the current exploit of the day. As more applications attempt to utilize SPF, this figure gets even more frightening. : 0

Of course, a URL could be required to use a host name which would exceed the protections of an SPF IP address authorization scheme, but without the serious risks. Within the underlying transfer protocol, simply require the use of host names. : )


  2. Zombies are no longer as effective as its necessary for such
     systems to be able to receive incoming connections and not
     only establish outgoing connections (as these systems must
     also be accessible through DNS).


Zombies have no difficulty establishing their own (highly transitory)
DNS infrastructure.  That too offers little protection.

You're missing the point. Go work for ISP and you'll know that its a lot easier to filter incoming ports end-users then it is to filter outgoing traffic for those users (a lot more complaints for the later).

There is still the issue of notification. Subsequent to sending the notification, obtaining the message body is the means to reach past firewall protections.


Necessity for DNS infrastructure is secondary and serves as extra barrier for spammers to overcome which BTW makes identifying zombies easier as you only need to monitor certain domains on regular basis (i.e. every 10 minutes for those "transitory" domains).

Agreed, which is why SPF is such a bad idea. SPF never assures the controlling domain is identified, making this scheme worse than worthless in many cases. A reputation check should be made prior to accessing the message content, and when verifying the DKIM signature.


  4. Better multi-party delivery that is done on per-site basis
     (this is related to current thread - on per-site common emails
     to multiple recipients can have shared referenced body part(s)
     and those can be retrieved by the site once and can be reused).

The concept in mind was to leverage efforts being made by the T10 group
on object storage to encompass the entire message body.
http://www.lustre.org/

That is OT to email infrastructure design and in any case no such complexity is going to be there for most who use email.

When attempting to provide supporting infrastructure, these types of object storage systems removes a major amount of the required development. The number of messages and maintenance overhead overwhelm a traditional file system or database. Why not take advantage of existing tools? When distribution of such a messaging system is not queue based, the alternative must be considered when done at a massive scale. Object storage has been engineered to address many of these issues, such as preventing replicate storage base upon content, handing automated archival and removal, etc.

In most cases the bandwidth saved would be rather small for a fairly
high amount of complexity.

Its the other way around actually especially as far as attachments go.

But an attachment would not be part of the display selection as you suggested. The attachment could simply be a MIME extension as suggested.


  6. Other advanced security choices available once communication
     between end-site and sender is possible...

Security would be part of any scheme. DKIM is a good starting point. 

Encumbered, oversimplified and limited by design - a lot worth then
it would have been, have it been a full IETF design effect like MASS
was supposed to provide for (which is how IETF usually operates,
i.e. designing protocol in open basis at WG). It is only now being
fixed and those fixes can not fully change some of the limitations
deliberately put in the WG charter.

Cheer up. You have good ideas. There is something to be said for a simplified approach however.

-Doug


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg