Re: [spfbis] Updated charter - final review

[Douglas Otis <[e-mail]>]

On 2/2/12 3:33 AM, Scott Kitterman wrote:
  Douglas Otis <[e-mail]> wrote:
>> On 2/1/12 5:53 PM, Scott Kitterman wrote:
>>>   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.
>> Dear Scott,
>>
>> Perhaps express this as requirement to establish a realistic Security
>> Consideration section.  It seems unlikely email providers will notice
>> their role in what might be devastating DDoS attacks impossible for
>> victims to mitigate.  Depending on email provider's perspectives of
>> "operational problems" unfortunately overlooks these broader Internet
>> concerns.
> Your wording assumes a problem. That's not appropriate. Either these attacks you claim are devastating someone exist and there will be evidence somewhere or they aren't a problem. Redesigning protocols for invisible attacks that no one can find is nonsense.
>
> The work of this group needs to be about engineering facts and not flights of fancy.
Dear Scott,

When dealing with security "whatever can happen will happen" could be 
termed "Murphy's law" and this provides a good basis for assessing 
security.  Architectural flaws within Internet infrastructure become 
pernicious when those impacted are unable to take corrective action.  
Draft-otis-spf-dos-exploit-01 demonstrates the possible.  Fortunately, a 
majority of large providers do not use SPF for message acceptance 
because they do not wish to deal with complaints arising from 
assumptions the SMTP Mail From parameter fully describes the path of a 
message in conjunction with SPF records ending in "-all".

Including a limit in the SPF validation process for the number of name 
errors or no data errors permitted would make the SPF process 
significantly safer.  IMHO, a large factor contributing to undesired 
SMTP traffic is the lack of domain authentication of outbound servers, 
which should be possible within a few transactions.  Unfortunately, SPF 
recommends resolving SPF records for both HELO/EHLO and Mail From SMTP 
parameters obtained from otherwise unknown sources using as many as 200 
DNS transactions that can be directed against non-existent resources!

We have a large number of customers within the pacific region, and are 
currently seeing a greater amount of traffic against absolute IPv6 
addresses than those against our own servers across a range of 
services.  Email providers deciding to not accept IPv6 traffic will 
likely be receiving it through Large Scale NATs.  At which point, no 
number of SPF transactions will be sufficient.

SPF currently provides a useful utility in determining which reputation 
service has listed an IP address authorized by the domain, or to 
white-list their authorized addresses.  Use of local-part macros would 
defeat the value of this utility and should be deprecated.

Regards,
Douglas Otis