Re: [spfbis] Updated charter - final review

[Scott Kitterman <[e-mail]>]

Douglas Otis <[e-mail]> wrote:

>On 1/31/12 10:29 PM, Pete Resnick wrote:
>> All,
>>
>> I have made some updates to the charter based on feedback during IESG
>
>> review. If I can sneak it onto the Thursday telechat this week, I 
>> might, but the IESG might be none too pleased for me to put it on so 
>> late, so it may wait two more weeks. We'll see.
>>
>> Please review the below and see if there is anything that makes your 
>> head explode.
>Dear Pete,
>
>At any inbound SMTP server, there may be attempts to resolve an 
>extensive list of IPv4 and IPv6 addresses associated with SPF records 
>whether referenced from insecure SMTP Mail From or HELO/EHLO
>parameters. 
>SMTP services must cope with an extensive amount of unwanted traffic
>and 
>will therefore have extensive provisioning. SMTP distributed attacks 
>will be extremely difficult for any single SMTP recipient to detect.
>Nor 
>will victims of an attack be aware of the triggering messages. Victims 
>of this type of attack may not even exchange SMTP traffic.
>
>Most sources of unwanted SMTP traffic originate from insecure hosts. 
>Resulting SPF related DNS transactions performed by receiving SMTP 
>servers will obfuscate their source. In addition,
>Authentication-Results 
>header fields, that may be added to forwarded messages, exclude source 
>IP addresses. Even when victims of targeted attacks are known,
>proactive 
>protection at either SMTP or DNS services can be thwarted by SPF’s
>macro 
>capabilities. SPF’s macros makes it impractical to identify records or 
>messages involved in an attack which may also lead to extensive traffic
>
>amplification.
>
>DDoS vulnerabilities may result from the distributed nature of SMTP 
>messages and receipt of DNS traffic related to SPF validation which may
>
>consume all of a victim's available resources. Whether an attack 
>leverages HELO/EHLO subdomains or more significantly an email-address 
>local-part, the overall number of transactions involved can be
>extensive 
>while demanding little of the sender’s resources. An SPF ‘mx’ or ‘ptr’ 
>mechanism limit corresponds to a ten times greater number of DNS 
>resource record resolutions. SPF deployment would be significantly
>safer 
>where recipients employ reasonable limits for the permitted number of 
>resulting DNS failures.
>
>Determining reasonable DNS error limits for SPF should be part of the
>WG 
>charter. Potential victims of SPF amplifications will not represent 
>those needing to change the SPF process.

The charter already covers this. If there are operational problems with the current design, it's in scope to address them.

Scott K