Re: Doug attack scenarios without SPF
John Leslie <[email protected]> Fri, 10 Nov 2006 16:39:12 -0500
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Message-ID | <20061110213912.GI73049@verdi> |
... clarifying one small portion... William Leibzon <[email protected]> wrote: > > Now I promised to explain why CSV makes it easy and is worse then SPF. That > is due to the suggestion of having to walk the dns tree which as far as I > remember it CSV specification has. Lets imagine that EHLO name is actually > bad1.bad2.bad3.bad4.example.com. What happens is that CSV specifies to do > lookups first to _client._smtp.bad1.bad2.bad3.bad4.example.com. Using above > system you cause multiple lookups due to lame delegation at > bad1.bad2.bad3.bad4.example.com that cause victims to respond they don't > know how to find _client._smtp.bad1.bad2.bad3.bad4.example.com. Next per CSV > (as far as I understood it), the application would have to try > _client._smtp.bad2.bad3.bad4.example.com and similarly attacker can setup > lame delegation but this time at bad2.bad3.bad4.example.com zone. This deserves some explanation. The CSV design team considered it important to have a way to specify that any subdomains which send mail will have explicit CSV records. (Or, more commonly, that _no_ subdomains should be sending mail.) It is quite specifically intended that the bit which specifies this will be queried and cached by other players than the receiving SMTP server. Thus, you will find in section 7 of the CSA spec: ] ] A receiving SMTP server MAY discover domain assertion information ] (after finding no record for the specific domain in the EHLO string) ] by searching for CSV-CSA records in parent nodes of the EHLO string, ] within the DNS hierarchy. Such a search MUST NOT query a top-level ] domain (such as COM, NET, or UK), and SHOULD NOT query deeper than a ] sixth-level domain. We quite clearly intended that implementors would provide a way to disable these extra queries if they ever prove to be a problem. Speaking for myself only, I expected that reputation services would perform these queries as new EHLO domains come to their attention and periodically thereafter; and that their reputation reports would reflect the domain owners' intent that subdomain EHLOs are not authorized. I was not able to get agreement of the design team to say this in as many words in the spec. Nonetheless, the spec _is_ clear that any reputation service would be entitled to do this. Thus, IMHO, it is likely that this feature would not be available to be abused; and that at worst it might allow five extra queries. -- John Leslie <[email protected]>