Re: [Asrg] Re: More e-mail oddities; SPF thoughts2006-02-06 12:23:36On 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(_dot_)org https://www1.ietf.org/mailman/listinfo/asrg
|
|
||||||||||||||||