Re: [Asrg] Re: More e-mail oddities; SPF thoughts

[Douglas Otis <dotis at mail-abuse.org>]

On Feb 6, 2006, at 6:12 AM, Frank Ellermann wrote:
> The argument that CSV could replace SPF was already dubious;

Rather than compiling huge address lists for all possible paths as  
with SPF, CSV, in conjunction with a forward PTR list of "authorized"  
domains within some message field, easily supplants the SPF  
approach.  This changes the maximal number of published records from  
112 down to 2, where in many cases one record lookup would be  
enough.  A CSV and forward PTR strategy is not bound by DNS response  
size which allows unlimited scaling.  This approach does not require  
specialized string parsing for CIDR notation, macro expansions,  
includes, redirects, or exists.


> CSV is an alternative to DKIM after reducing the problem to the  
> critical hops from original sender to initial receiver, from  
> initial receiver to next "251"-destination, and so on.

With DKIM, the message envelope is not included within the  
signature.  This independence is essential for store-and-forward,  
especially within heterogeneous name space.  With privacy concerns,  
especially related to spam, silently forwarding changes will likely  
be considered important.  The message envelope is independent of the  
DKIM signature, so the signing-domain must not be held accountable  
for the destination, the return-path, or the overall number of  
messages sent using the same signature.

Some may wish to trust the signing-domain to verify "originating"  
header fields within the signed portion of the message, and use this  
assumption to hold the "originating" email-address culpable.  This  
culpability may be considered "confirmed" when email-address policies  
records associate the signing-domain.  Using DKIM to hold either an  
email-address or the signing-domain accountable requires stringent  
control of message content.  Such control is not practical for most  
domains.  Getting sloppy about culpability also ensures only large  
domains remain viable.

While DKIM may prevent the initial source of a message from being  
spoofed, most reputation systems attempt to judge governance of a  
domain by a percentage of good/bad messages.  With DKIM, the  
assessment of bad depends upon the evaluation of just the message  
content that can not be quantified.  This evaluation would need to  
check for invalid header fields, criminal message content, or perhaps  
deceptive links.  This type of assessment is resource intensive, to  
say the least.

DKIM could reduce the expense related to monitoring for abuse by  
having the signing-domain indicate which messages are from vetted  
sources.  Any exceptional handling based upon the validation of a  
DKIM signature should also be limited to just those vetted sources.   
With DKIM, an inordinate amount of abuse can be generated from  
unvetted sources, which could easily overwhelm monitoring.  It would  
not be practical for monitoring to depend upon undefined email- 
address verifications by the signing-domain and then separately rank  
an unlimited number of email-addresses.


> DKIM integrates this into "let any MON on the route sign the  
> message, and let any later MRN check this signature".

The overhead processing signatures will not be insignificant.  This  
will become more apparent as SHA-1 is replaced with SHA-256 or keys  
greater than 1024 bits are used.  The stacking of signatures will  
likely represent a growing DoS concern.  A strategy that overlays or  
removes signatures (perhaps changing the signature header name to  
permit header inclusion) may be desirable.


> Or in other words DKIM is interesting if there's more than one  
> critical hop between signer and checker, otherwise its overhead is  
> beyond all reasonable limits:  There are much simpler schemes like  
> MTAMARK or CSV or SPF HELO to get a grip on "legit mailer" (in  
> combination with a white list).

Agreed.  A lightweight verification of the sending machine will help  
defend schemes like DKIM, that assist in overcoming some routing  
exploits.


> It's a bit beyond me why folks bother with CSV, or SPF HELO, or  
> DKIM (sorted by potential overhead) if they could as well use  
> something as simple as MTAMARK (maybe in combination with reliable  
> DUL-lists, worst case their own private list).

Perhaps network providers are keen to avoid spam related issues.  A  
forward lookup represents less administrative effort as well, which  
is why CSV seems to be a good approach.  CSV is not ambiguous about  
the purpose of the record.  Your example of the SPF not.example.com  
demonstrated what _not_ to do with SPF.  This example produces  
unexpected exposures, lost in the complexity of the syntax.


> Of course DKIM with STRONG signing policies is another matter  
> "phishing" in the muddy waters of PRA.  But "pure" DKIM is much ado  
> about nothing - more convenient for 251-forwarders than SPF, less  
> convenient for mailing lists than SPF.  Where PRA managed to  
> combine both worst case scenarios... <sigh />

The use of DKIM should be seen as a means to raise the level of trust  
for some transactional email.  DKIM will reduce the false positive  
detections with phishing related filtering.  Policy records offer no  
significant assistance, as there should be no reliance upon an email- 
address not being spoofed in the exploit, or that the recipient can  
recognize a look-alike.  There could be efforts to purchase thousands  
of look-alike domains and publish records indicating those domains do  
not sign messages.  It would be cheaper and safer to make a list of  
domains that have retained their trustworthy status, and mark those  
messages accordingly.  This also underscores the need to note which  
DKIM signatures are from a vetted source to both increase the safety  
of this assurance, and to minimize the resources consumed.

DKIM can also allow individuals recipients to locally make their own  
"trusted" lists to aid their effort avoiding being spoofed.  This  
would assume such recipient would use some out-of-band method to  
verify the source.

-Doug







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