Subject: Re: [spfbis] Updated charter - final review

From: Alessandro Vesely <[email-masked]>
Date: Wed, 01 Feb 2012 12:37:24 +0100

On 01/Feb/12 07:50, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Pete Resnick
> 
>> Please review the below and see if there is anything that makes your
>> head explode.
> 
> Looks okay to me.

+1

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Feb 2012 06:52:39 -0500

On 2/1/2012 1:29 AM, Pete Resnick wrote:
> addition of any enhancements
>      that have already gained widespread support,

What additions are being proposed and considered?

This clause broadens the scope significantly.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 07:08:08 -0500

>This clause broadens the scope significantly.

FWIW, I'm not aware of anything that would currently meet that criteria and the only thing that might in the time frame we're discussing is the SPF failure  feedback report going on in MARF.

If this language lets us transition the SPF modifier registry into 4408bis, then it's probably useful.

Scott K

---

From: Pete Resnick <[email-masked]>
Date: Wed, 1 Feb 2012 09:39:14 -0600

> This clause broadens the scope significantly.

This line has been in the charter since it went to the IESG and for IETF 
review.

My read of the line has always been that there is a burden on the 
proposer to show that any particular enhancement already has 
implementation and that the community has already (past tense) given the 
feature widespread support. I am willing to leave to the judgment of the 
chairs (and myself) whether the WG has clear consensus on the 
"widespread support" of such an enhancement should one come forward.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 10:45:45 -0500

On Wednesday, February 01, 2012 12:29:11 AM 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.
> 

Looks good to me.  Let's get started.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 01 Feb 2012 10:48:53 -0500

On 2/1/2012 10:39 AM, Pete Resnick wrote:
> My read of the line has always been that there is a burden on the proposer to
> show that any particular enhancement already has implementation and that the
> community has already (past tense) given the feature widespread support. I am
> willing to leave to the judgment of the chairs (and myself) whether the WG has
> clear consensus on the "widespread support" of such an enhancement should one
> come forward.

mumble(*)

d/

(*) that's a synonym for 'grumble'.

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Wed, 01 Feb 2012 11:28:29 -0500

+1, looks good to me.

--
HLS

Pete Resnick wrote:
> ---
> Working Group Name:
>     SPF Update (SPFBIS)
> IETF Area:
>     Applications Area
> Chair(s):
>     TBD
> Applications Area Director(s):
>     Pete Resnick<[email-masked]>
>     Peter Saint-Andre<[email-masked]>
> 
> Applications Area Advisor:
>     Pete Resnick<[email-masked]>
> 
> Mailing Lists:
>     General Discussion:[email-masked]
>     To Subscribe:    https://www.ietf.org/mailman/listinfo/spfbis
>     Archive:    http://www.ietf.org/mail-archive/web/spfbis/
> 
> Description of Working Group:
>     The Sender Policy Framework (SPF, RFC4408) specifies the publication
>     of a DNS record which states that a listed IP address is authorized
>     to send mail on behalf of the listing domain name's owner.  SMTP
>     servers extract the domain name in the SMTP "MAIL FROM" or "HELO"
>     command for confirming this authorization.  The protocol has had
>     Experimental status for some years and has become widely deployed.
>     This working group will summarize the result of the experiment and
>     revise the specification, based on deployment experience and listed
>     errata, and will seek Standards Track status for the protocol.
> 
>     The MARID working group considered two specifications for
>     publication of email-sending authorization:  Sender-ID, which
>     eventually became RFC4405, RFC4406 and RFC4407, and SPF, which
>     eventually became RFC4408, all in the end published under
>     Experimental status.  By using IP addresses, both protocols specify
>     authorization in terms of path, though unlike SPF, Sender-ID uses
>     domain names found in the header of the message rather than the
>     envelope.
> 
>     The two protocols rely on the same policy publication mechanism,
>     namely a specific TXT resource record in the DNS.  This creates a
>     basic ambiguity about the interpretation of any specific instance of
>     the TXT record.  Because of this, there were concerns about
>     conflicts between the two in concurrent operation.  The IESG note
>     prepended to RFC 4405 through RFC 4408 defined an experiment with
>     SPF and Sender-ID, and invited an expression of community consensus
>     in the period following the publication of those specifications.
> 
>     Both technologies initially enjoyed widespread deployment.  Since
>     that time, broad SPF use has continued, whereas use of Sender-ID has
>     slackened.  Furthermore, SPF's linkage to the envelope (as opposed
>     to Sender-ID's linkage to identifiers in the message content) has
>     proven sufficient among operators.
> 
>     Formation of the SPF Update Working Group is predicated on three
>     assumptions:
> 
>     1. The SPF/Sender-ID experiment has concluded.
> 
>     2. SPF has been a qualified success, warranting further development.
> 
>     3. Sender-ID has had less success, and no further development is 
> justified.
> 
>     The working group will produce a document describing the course of
>     the SPF/Sender-ID experiment, thus bringing that experiment to a
>     formal conclusion.  The group will complete additional work on SPF
>     (described below), but will not complete additional work on the
>     Sender-ID specification.
> 
>     Changes to the SPF specification will be limited to the correction
>     of errors, removal of unused features, addition of any enhancements
>     that have already gained widespread support, and addition of
>     clarifying language.
> 
>     Specifically out-of-scope for this working group:
> 
>     * Revisiting past technical arguments where consensus was reached in
>       the MARID working group, except where review is reasonably
>       warranted based on operational experience.
> 
>     * Discussion of the merits of SPF.
> 
>     * Discussion of the merits of Sender-ID in preference to SPF.
> 
>     * Extensions to the SPF protocols.
> 
>     * Removal of existing features that are in current use.
> 
>     Discussion of extensions to the SPF protocols or removal of
>     existing features shall only be discussed after completion of
>     current charter items in anticipation of rechartering the working
>     group.
> 
>     An initial draft of an updated SPF specification document is
>     draft-kitterman-4408bis. The working group may choose to use this
>     document as a basis for their specification.
> 
> Goals and Milestones:
>     Aug 2012:    A document describing the SPF/Sender-ID experiment
>             and its conclusions to the IESG for publication.
> 
>     Dec 2012:    A standards track document defining SPF,
>             based on RFC4408 and as amended above,
>              to the IESG for publication.
> 

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

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 01 Feb 2012 12:45:52 -0500

Long ago, Nostradamus foresaw that on 02/01/2012 07:08 AM, Scott 
> If this language lets us transition the SPF modifier registry into 4408bis, then it's probably useful.
Since 4408 already reserves unknown modifiers for extensions, there is 
no need to mention specific extensions, except perhaps to reference the 
IANA registry for such extensions.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Feb 2012 17:15:01 -0800

On 1/31/12 10:29 PM, Pete Resnick wrote:
> 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.
>
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.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 01 Feb 2012 20:53:42 -0500

>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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 01 Feb 2012 20:32:39 -0800

On 2/1/12 5:53 PM, Scott Kitterman wrote:
> >> 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,
> >
> > 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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 02 Feb 2012 06:33:01 -0500

>"operational problems" unfortunately overlooks these broader Internet 

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.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Feb 2012 06:59:57 -0500

On 2/1/2012 7:08 AM, Scott Kitterman wrote:
> Dave CROCKER<[email-masked]>  wrote:
> FWIW, I'm not aware of anything that would currently meet that criteria and
> the only thing that might in the time frame we're discussing is the SPF
> failure  feedback report going on in MARF.

That's a useful observation, since it should help to bias the group against
spending very much time considering "additions", absent extremely compelling
deployment experience.

d/

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Feb 2012 09:18:35 -0500

> Perhaps express this as requirement to establish a realistic Security
Consideration section.

Regardless of what we put in the charter, reviewing the security
considerations and considering revising them appropriately is clearly an
in-scope -- I might even say *required* -- activity.  It will be up to the
chairs to ensure that happens and to manage the discussion.  It will be one
responsibility of the participants to come to consensus on it, and to
accept when the consensus is against them, and move on.

Barry

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 2 Feb 2012 10:08:20 -0500

Hi Doug,

On Wed, Feb 01, 2012 at 08:32:39PM -0800, Douglas Otis wrote:

> Perhaps express this as requirement to establish a realistic
> Security Consideration section.

If we're going to do that, we ought to list all the other standard
things that published WG documents are supposed to do, like reflect WG
consensus, have correct boilerplate, have correct references --
indeed, the charter would end up having all the PROTO instructions,
the instructions to genart and secdir, and so on.

And, indeed, every charter ought to contain this.

I think it's an unreasonable request.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Leslie <[email-masked]>
Date: Thu, 2 Feb 2012 10:12:34 -0500

Barry Leiba <[email-masked]> wrote:
> considerations and considering revising them appropriately is clearly
> an in-scope -- I might even say *required* -- activity.  It will be
> up to the chairs to ensure that happens and to manage the discussion.
> It will be one responsibility of the participants to come to consensus
> on it, and to accept when the consensus is against them, and move on.

   I was thinking of posting the same thing: there's no reason to put
a Security Considerations item in the charter.

   FYI, this charter is on today's IESG agenda. Hopefully Pete will
advise us of any action taken.

   (Barry will be trying on his brand-new-AD hat in about an hour. :^)

--
John Leslie <[email-masked]>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Feb 2012 11:13:16 -0500

>   (Barry will be trying on his brand-new-AD hat in about an hour. :^)

It's still just a propeller-beanie right now.  It becomes a proper hat
in Paris (so I suppose it should be a beret).

Barry

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Feb 2012 12:55:29 -0500

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:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Feb 2012 12:08:09 -0800

On 2/2/12 3:33 AM, Scott Kitterman wrote:
  Douglas Otis <[email-masked]> wrote:
>>>   Douglas Otis<[email-masked]>  wrote:
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

---

From: Hector Santos <[email-masked]>
Date: Thu, 02 Feb 2012 16:31:34 -0500

Douglas Otis wrote:

> Fortunately, a

Did you ever consider they were not candidates to use SPF?

I always viewed SPF benefited private user domains, companies, of any 
size, institutions, etc, where there is less to no unknown variables 
in their networking.

But I think that is all depends on your definition for "Large 
Providers."  FaceBook.com and gmail.com can be viewed as "very large" 
Email Providers.  Facebook.com, I presume has a very large pool of 
outbound senders and it has a well defined network with a -ALL final 
result.

On the other hand, gmail.com with its ?ALL is a major overhead and 
resource "waster" - its completely useless for gmail.com to use 
UNKNOWN condition.  Nothing good comes from it:

    MATCH    - IP is on the GMAIL Network - Whoopie!
    NO MATCH - IP is not on the GMAIL NETWORK

In both cases, abuse can and still occurs but with the latter, its 
where major abuse would be with bad guys using gmail.com with a 
wasteful record, and worse, it is always two lookups for what is most 
likely a wasteful yield.

At least with Facebook.com, there is a measurable yield. Its 
protecting itself from any foreign abuse.

Recently, I got a smile when I saw my old employer Mobil Oil (now as 
Exxon Mobil) corporate domain has a HARD FAIL SPF Record!

Processes with hard failure detection mechanism is where the maximum 
benefit is found. A PASS or anything else still generally requires 
even more filter checks and even if you couple it with reputation or 
scoring,  it is still not deterministic unlike a hard fail.

Any system operation, large or small, that can not establish a well 
defined network was never really a candidate for SPF - I think we 
always knew that.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Feb 2012 16:31:28 -0800

On 2/2/12 1:31 PM, Hector Santos wrote:
>  Douglas Otis wrote:
> > 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".
>
>  MATCH - IP is on the GMAIL Network - Whoopie! NO MATCH - IP is not
>  on the GMAIL NETWORK
>

Dear Hector,

Many providers of email services run on thin margins threatened by 
answering support calls caused by erroneous assumptions, such as whether 
an email alias is used to arrive at a recipient's mailbox.  The Mail 
 From parameter indicates where Delivery Status Notifications are to be 
sent, and nothing more can be assumed.  At most, SPF Pass indicates the 
last hop was authorized, however authorization does not authenticate the 
originating domain.  Refusing messages based upon SPF HARD FAIL is also 
likely to demand expensive exceptions for these refusals.

Regards,
Douglas Otis

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 02 Feb 2012 12:50:58 -0500

On 2/2/2012 9:18 AM, Barry Leiba wrote:
> Regardless of what we put in the charter, reviewing the security considerations
> and considering revising them appropriately is clearly an in-scope -- I might
> even say *required* -- activity.

Still, it might be worth adding the suggested extra text to the charter. 
Personally, I was planning on trying to establish an UNrealistic Security 
Considerations section, but would not pursue it if the charter prohibited it...

Perhaps the charter should also contain a proscription against meaningless 
charter content?

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Feb 2012 10:15:44 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Thursday, February 02, 2012 9:51 AM
> To: Barry Leiba
> Cc: [email-masked]
> Subject: Re: [spfbis] Updated charter - final review
> 
> Perhaps the charter should also contain a proscription against
> meaningless charter content?

We need a BCP for that.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 03 Feb 2012 11:21:37 -0800

>> meaningless charter content?

Perhaps an analysis of the ecological impact of additions to charters and 
specification of material that is redundant, obvious or otherwise useless?

Extra words mean extra paper.  They also reduce the information salience of the 
document.  That is, it makes it harder to find the parts that /are/ imporant. 
No doubt there are other implications.

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Fri, 03 Feb 2012 13:27:42 -0800

On 2/2/12 9:50 AM, Dave CROCKER wrote:
> > considerations and considering revising them appropriately is
> > clearly an in-scope -- I might even say *required* -- activity.
> >
>  Still, it might be worth adding the suggested extra text to the
>  charter. Personally, I was planning on trying to establish an
>  UNrealistic Security Considerations section, but would not pursue it
>  if the charter prohibited it...
>

Dear Dave,

No one denies email confronts significant levels of abuse, however other 
services respond by establishing safe and efficient cryptographic 
authentications compliant with Today's Internet.

SPF path authorizations employ recipient resources processing macros 
defined in a draft that never reached consensus within an IETF Marid WG 
prior to closure.  Initial drafts proposed XML encoded 2KB resource 
records without limit, modified to tag/value text with 20 deep recursion 
limits, and modified again to limits of 10 macro mechanisms with each 
allowing 10 subsequent DNS transactions just prior to the closure.  
Although some progress being made, the closure seemed related to a lack 
of consensus about whether SMTP Mail From parameter rewriting or PRA 
algorithm would facilitate unauthorized path refusal.

The concern expressed was to ensure the WG charter was not seen as 
endorsing the current scheme that allows 200 directed DNS transactions 
reflected against non-existent resources.  Comments about the charter 
were to highlight potential concerns admittedly unlikely to directly 
impact SMTP, but were about the granting of unknown entities poorly 
constrained access to recipient resources.

A WG outcome based upon realistic assessment of SPF's current utility 
and related risks is welcome.  Introducing limits on the number of DNS 
Name or No Data errors will not impact how SPF might be used, only how 
it might be abused.

Regards,
Douglas Otis

---

From: Stuart Gathman <[email-masked]>
Date: Sat, 04 Feb 2012 21:18:59 -0500

Long ago, Nostradamus foresaw that on 02/01/2012 08:15 PM, Douglas Otis
would write:
> An SPF ‘mx’ or ‘ptr’ mechanism limit corresponds to a ten times
> greater number of DNS resource record resolutions.
Actually, the PTR mechanism is essentially "free" for SPF DoS concerns
in that it has already been resolved and cached by the MTA. 

Doug has several valid points:

1. Each uncached MX query served by an attacker's DNS can result in 10
uncached A record queries by a 3rd party triggered via SMTP.   RFC4408
limits each SMTP transaction to 10 DNS oriented mechanisms, so with one
SMTP MAIL FROM (or HELO) transaction and 10 uncached MX queries served,
an attacker can trigger 100 uncached A queries by a 3rd party (the MTA). 

2. The macro features allow an attacker to vary the domains with each
SMTP MAIL FROM or HELO transaction to prevent caching.  (By
"transaction" I mean sending the TCP packet with the MAIL FROM or HELO
command, and receiving the response so as to enable the next transaction.)

3. The victim of the A record queries will only see the IPs of
legitimate MTAs, obscuring the perpetrator.

The MX mechanism is not going away for 4408bis.

Neither are the macro features.

The next working group (for spf3 or whatever) can consider such surgery:
for example removing the MX mechanism, or simply counting each MX record
as an A mechanism for processing limit purposes.

And again, SMTP enabled DoS does not require SPF.  For example,  with
IP6 - just connect from random IP6 ips, and serve a big list of PTR
records with names in your targets DNS when the MTA tries to identify
the connect IP, none of which match your random IP.  In my opinion,
replacing SMTP would be a better use of energy than trying to stop
deployment of IP6 or SPF (replacing SMTP gets rid of SPF as a bonus!).

---

From: Hector Santos <[email-masked]>
Date: Sun, 05 Feb 2012 01:30:17 -0500

Pete,

Now that I have a better change (more time) to review the charter, 
there is one item that I think may be important related to SENDER-ID 
from the standpoint of RFC 4405 SUBMITTER SMTP Extension.

To begin the WG spec discussions, I was going to propose the following 
to modify section 4.1:

4.1.  Arguments

    The check_host() function takes these arguments:

    <ip>     - the IP address of the SMTP client that is emitting the
               mail, either IPv4 or IPv6.

    <domain> - the domain that provides the sought-after authorization
               information; initially, the domain portion of the "MAIL
               FROM" or "HELO" identity.

    [submitter] - RFC 4409, SUBMITTER keyword passed to the "MAIL FROM"

but then I though it may not fit the charter with the way SENDER-ID is 
discussed.

Background:

In our implementation, if the SUBMITTER keyword is provided to the 
MAIL FROM, it is passed to our SPF implementation check_host() function:

   result = check_host(ip, domain [, submitter])

The tie-in, even for the SPF implementator who may not directly 
support SENDER-ID, it could be supporting RFC 4405 because it is a 
SMTP level protocol and it allows SMTP systems the NON-PAYLOAD 
affordability to support SENDER-ID indirectly.

In my opinion, I think it has technical and operational merit to 
consider how implementations has supported SENDER-ID via the SUBMITTER 
keyword.

However, the charter does ring with the idea that the industry are no 
longer interested in SENDER-ID. I don't think we can make that 
decision for anyone. Perhaps a statement should be added to the 
charter or revised it to clarify the lack of WG consideration for 
SENDER-ID does not imply it is no longer supported and that RFC4405 
MAY be supported via SPF-BIS.

If anything, the check_host() arguments SHOULD be changed to be 
flexible with optional parameters and not locked in and using RFC4405 
is a valid technical rational as an example optional parameter without 
having to introduce SENDER-ID discussions.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 6 Feb 2012 07:19:28 -0500

Dear Hector, colleagues,

> from the standpoint of RFC 4405 SUBMITTER SMTP Extension.

Unfortunately, it is now too late to make changes to the charter
without undertaking a WG rechartering exercise.  I'd like to ask
everyone to close this thread, please.

> To begin the WG spec discussions, I was going to propose the
> following to modify section 4.1:

We've decided to begin the WG discssions a different way.  Please see
the threads about this I kicked off on Friday.  Perhaps your
suggestions could be made as part of a review, or else perhaps you
have some evidence about the experiment you wish to share.

> consider how implementations has supported SENDER-ID via the
> SUBMITTER keyword.
> 
> However, the charter does ring with the idea that the industry are
> no longer interested in SENDER-ID. I don't think we can make that
> decision for anyone.

Please see the thread asking for evidence about the experiment.

Thanks and best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: SM <[email-masked]>
Date: Mon, 06 Feb 2012 06:09:05 -0800

Hi Stuart,

Andrew Sullivan posted a message, as WG co-chair, about changes to 
the WG charter ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00280.html 
).  I suggest opening a new thread for your review of RFC 4408.

>Doug has several valid points:

I suggest that Doug posts the points as part of a review of RFC 4408 
so that they can be tracked as issues.

>as an A mechanism for processing limit purposes.

As the WG is working on RFC 4408, this is the time to request changes 
to the SPF specification.

Regards,
S. Moonesamy
SPFBIS WG co-chair