Re: [spfbis] Updated charter - final review

[Hector Santos <[e-mail]>]

The problem is that from your POV there is only one solution - STOP 
USING SPF.  In short, the ultimate conclusion when your security 
concerns is seriously considered, is to stop using SPF.  That's not a 
solution - a non-starter.

You keep talking about IPV6 and I don't know about others, thats still 
really very far for MOST people. I have yet to encounter one person 
that is only talking IPV6 and we can't deal with him. I can't even 
recall one company even inquiring about IPV6 support for any our 
internet servers.

==
HLS

Douglas Otis 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.
> 
> Regards,
> Douglas Otis
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com