On Sun, 2007-02-18 at 12:51 +0100, Harald Tveit Alvestrand wrote:
> On second thought, I know that you know this field well enough that I
> *must* have misunderstood your message.
>
> Could you please restate your missive in such a way that it's clear:
>
> - What problem you think the IETF can help solve
> - What action you think the IETF should take to solve it?
>
> I'm afraid the whole spam thing has gotten so convoluted by now that I need
> instructions in large type to figure out which path out of the weeds you're
> pointing at....
There is a very dangerous trend developing in how email and network
providers wish to deal with bulk unsolicited messaging. In essence,
their desire is to hold content originators accountable. At the same
time, are promoting identification strategies that obscure who is
actually transmitting the message. Although identifying the domains
creating message content might seem ideal, not identifying the domain
transmitting the message is highly perilous from a network security
standpoint.
Case in point would be Sender-ID. Here the SMTP client's IP address is
authorized by matching it against a possible originating domain's list
of all IP addresses used publicly within the Internet. A safe
alternative (that does not attempt to obscure the transmitting entity)
would be to first authenticate the transmitting entity, and then check
whether an originating domain has authorized the transmitting entity.
The transmitting entity can be authorized using a "Name-Hash" with one
small and safe DNS transaction. Sender-ID's efforts to obscure the
transmitting entity has created an extremely dangerous DDoS threat
instead.
Case in point would be DKIM. Here the originating email-address is
assured _only_ by the signature of a parent domain. DKIM could have
been structured to allow the signature to always be applied by the
transmitting entity instead, and then allow this entity to be authorized
by originating domains when the domains differ. DKIM lacks a means to
identify on who's behalf the signature was applied when the domains
differ, and a means for originating domains to authorize the
transmitting entity.
DKIM's signatures can be replayed, as can any crypto-graphic signature.
DKIM's strategy to obscure the transmitting entity means a definition
must now be establish as to which upper portions of the domain hierarchy
can be considered authoritative for email-addresses. In addition,
email-address domain owners that outsource email services will need to
exchange private keys on a large scale with these transmitting entities.
DKIM's efforts to obscure the transmitting entity means MTAs will
warehousing thousands of private-keys. In addition, the diffusion of
DKIM signatures at the transmitting entity also makes dealing with
replay abuse virtually impossible.
---
The safe way forward would be to demand that security be considered
first and foremost. In a store and forward scheme, start the chain of
identification from the transmitting entity, where the originating
entity is then able to authorize the transmitting entity when they
differ.
---
For Sender-ID, validate the SMTP client, and then allow the PRA to
authorize the SMTP clients using a small single "Name-Hash" DNS
transaction.
For DKIM, allow the signature to indicate on which header's behalf the
signature was applied. This could be done by extending the 'i='
semantics, or more simply by naming the header. A small single
"Name-Hash" DNS transaction could then safely authorize the transmitting
entity. This removes the need to establish which elements of the domain
hierarchy are authoritative for email-addresses, and removes the extreme
risk created when exchanging and warehousing private keys at
transmitting MTAs, as the current scheme now demands.
In either approach, having a strong identifier of a transmitting entity
allows a much faster response to abuse. The current trend of obscuring
the transmitting entity must be stopped, or the IETF will face the
perils these schemes will surely create.
-Doug
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
