|
Re: [Asrg] pre-rfc thought balloon: ESMTP DATA-CALLBACK (was ESMTP DATAFIRST)
2006-06-06 11:39:43
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(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|