Re: [spfbis] Updated charter - final review

Douglas Otis <dotis@mail-abuse.org> Thu, 02 February 2012 04:32 UTC

Return-Path: <dotis@mail-abuse.org>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B68911E80BF for <spfbis@ietfa.amsl.com>; Wed, 1 Feb 2012 20:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.325
X-Spam-Level:
X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgqmozJ5c3Hr for <spfbis@ietfa.amsl.com>; Wed, 1 Feb 2012 20:32:40 -0800 (PST)
Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 18DCE11E807F for <spfbis@ietf.org>; Wed, 1 Feb 2012 20:32:40 -0800 (PST)
Received: from US-DOUGO-MAC.local (SJDCLUXGATEWAY1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EB3A6174010F for <spfbis@ietf.org>; Thu, 2 Feb 2012 04:32:39 +0000 (UTC)
Message-ID: <4F2A11E7.10409@mail-abuse.org>
Date: Wed, 01 Feb 2012 20:32:39 -0800
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: spfbis@ietf.org
References: <4F28DBB7.5070101@qualcomm.com> <4F29E395.3020100@mail-abuse.org> <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com>
In-Reply-To: <5905d04c-42eb-42f0-b580-1fb654cfe5af@email.android.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [spfbis] Updated charter - final review
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Feb 2012 04:32:40 -0000

On 2/1/12 5:53 PM, Scott Kitterman wrote:
>  Douglas Otis <dotis@mail-abuse.org> 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