Subject: [spfbis] SPFbis WG scope

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Dec 2011 19:52:36 -0800

Attempts to elevate SPF to a standards track document just as Carrier 
Grade or Large Scale NATs appear distracts from a greater need to 
provide scalable cryptographic validation for SMTP servers.  SPF 
provides little protection against spoofing since MAILFROM is not seen.  
Efforts to extend SPF to include PRA suffers from similar problems since 
malefactors can use unseen PRA header fields as well.

The macro expansion required for SPF processing risks DDoS threats with 
little justification.  For example, SPF evaluation may require 
subsequent transactions formed by email-address local-parts.  Since most 
spam campaigns already modify source address local-parts, any targeted 
attack against a domain (which may not be present within these messages) 
will not burden malefactor's DNS since SPF records referenced by the 
domain portion of the email address will have been cached.  This permits 
both spamming and DDoS to occur simultaneously that exploits SPF's 
burden placed upon recipient resources.  Use of "exists" macros is 
equally nonsensical.  Any message with an email address pointing to 
existing resource records as dictated by SPF macros reveals absolutely 
nothing about who sent the message!

The 10 mechanism macro limit must include subsequent transactions 
necessary to resolve authorized IP address lists.  Even this seemingly 
low limit can result in significant levels of network amplification 
oweing to processing burdens placed upon recipients.  While email 
providers are unlikely targets, and processing complex SPF macros are 
seldom logged, there would be few clues regarding this attack from a 
victims perspective.  Assumptions that a valid authorization confirms 
the action of a domain is also wrong.  Often these authorizations are 
essential to ensure delivery can be accomplished by various email providers.

Rather than expecting recipients to discern whether an entire sequence 
of email deliveries properly executed the "who's it" handshake and that 
no one is lying all depends upon the last provider in the sequence.  
Recipients should be allowed to either trust the last provider or not, 
where authentication of this last provider represents the only scalable 
solution.

http://tools.ietf.org/html/draft-kucherawy-dkim-atps-11 provides a 
"single" transaction method for DKIM signers to authorize all last in 
sequence providers.  There is no reason to muddle with the return path 
for DSNs since this will further lower email integrity.

-Doug

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 17 Dec 2011 04:56:33 +0000

Oh dear.

Douglas Otis wrote:

> Efforts to extend SPF to include PRA suffers from similar problems
> since malefactors can use unseen PRA header fields as well.

There are no such efforts.

BTW, you failed to clarify your concerns about the SPFbis WG scope as 
indicated by your subject line.  Are you saying this WG should not exist?

-Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 17 Dec 2011 21:07:58 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Mehnle
> Sent: Friday, December 16, 2011 8:57 PM
> To: [email-masked]
> Subject: Re: [spfbis] SPFbis WG scope
> 
> Oh dear.
> 
> Douglas Otis wrote:
> 

+1.

I would also add that all of the other points raised are explicitly out of scope per the proposed charter.  The discussion then needs to be about whether the scope should change to include them, or whether there's objection to creation of the working group altogether.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Dec 2011 11:23:37 +0100

On 18/Dec/11 06:07, Murray S. Kucherawy wrote:
> 
> I would also add that all of the other points raised are explicitly
> out of scope per the proposed charter.  The discussion then needs
> to be about whether the scope should change to include them, or
> whether there's objection to creation of the working group
> altogether.

Well, a point that does look somewhat obscure is the extension
mechanism itself.  It is necessary to read Julian's draft until the
final paragraph in order to find a NOTE that explicitly states how
extensions work in general.  Recent discussion on dpf-discuss shows
that it is not obvious how (not) supporting an extension may affect
SPF compliance.

It sounds undoubtedly self-appointing of an extension to specify the
extension mechanism itself.  I'd rather have a section about the
possibility of extensions in SPFbis.  However, that apparently
conflicts with the fifth paragraph of the charter, "Changes to the SPF
specification will be limited to..."  In any case, an extension
mechanism is something different from the first of its possible instances.

I'd propose to merge the seventh paragraph into the fifth, for example
like so:

  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, addition of clarifying
  language, and possibly the addition of an extension mechanism.  The
  extension mechanism will be developed along with the proposed
  "scope" extension found in draft-mehnle-spf-scope, and its
  specification may end up in either document.

(Note the draft's name is different.)

---

From: Julian Mehnle <[email-masked]>
Date: Mon, 19 Dec 2011 10:51:39 +0000

Alessandro Vesely wrote:

> extension mechanism itself.

It's not like draft-mehnle-spf-scope creates new extension modifier 
semantics.  http://tools.ietf.org/html/rfc4408#section-6 says:

    Unrecognized modifiers MUST be ignored no matter where in a record,
    or how often.  This allows implementations of this document to
    gracefully handle records with modifiers that are defined in other
    specifications.

So extension modifier semantics are already clearly specified in RFC 4408.  
I.e., "If you don't support a non-core modifier, don't worry."

Of course a non-core modifier has to ensure that its semantics remain 
comaptible with SPF implementations that don't implement it.  
draft-mehnle-spf-scope takes care of that by explicitly stating that
"v=spf1" records with "scope=" modifiers will always be applicable to 
checks against the helo/mfrom identities in addition to any identities 
listed in the "scope=" modifier.

I don't see an issue here.

> I'd rather have a section about the possibility of extensions in SPFbis.

I have no objections to clarifying the modifier semantics that are already 
defined in RFC 4408.

-Julian

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Dec 2011 13:26:17 +0100

> I.e., "If you don't support a non-core modifier, don't worry."

Yes, that it said.  But not loudly enough if discussion turned on what
2119-language should be able to ram extensions down somewhere.

There are different extension mechanisms that provide for flagging
what extensions are supported or required.  The one for v=spf1 is not
one of those.  It doesn't seem to be worth for domain owners to know
whether a given recipient supports a certain SPF extension, since
currently they even ignore if that recipient supports SPF at all.
Yet, it may be worth to make it known to consumers of the outcome
--both policy rejections and Authentication-Results.  And what about
included records?  What if v3 will want to introduce the possibility
of required extensions?

> I don't see an issue here.

Suppose someone will conceive an extension that addresses, say, the
display-name or comments in a "From:" field.  Should they reuse the
"scope=" construct?

> I have no objections to clarifying the modifier semantics that are already 

Failing that, I'd suggest that it be clarified in a prominent section
of your draft, rather than in the last paragraph.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Dec 2011 11:05:11 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Monday, December 19, 2011 4:26 AM
> To: [email-masked]

I'm at a loss to understand where all this rhetoric about forced extensions comes from.  A mandatory extension isn't an extension anymore, it becomes part of the base protocol, and I think the charter makes it clear that this isn't a goal of the working group.

> There are different extension mechanisms that provide for flagging what
> extensions are supported or required.

I don't know what a "required extension" is.  If you add something that is mandatory for interoperability, you haven't created an extension, you have revised the protocol.  That would require a new version of SPF altogether.

> > I have no objections to clarifying the modifier semantics that are
> > already defined in RFC 4408.
> 

That's fine, and probably a good idea, but that doesn't strike me as evidence of a problem with the charter.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Dec 2011 21:03:58 +0100

On 19/Dec/11 20:05, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
> 
> I'm at a loss to understand where all this rhetoric about forced
> extensions comes from.

I just meant it is not stated clearly enough.

> A mandatory extension isn't an extension anymore, it becomes part
> of the base protocol, and I think the charter makes it clear that
> this isn't a goal of the working group.

It is not a goal for spfbis.  However, discussions on what is the most
suitable extension syntax so as not to preclude future changes should
not be off-topic.

> I don't know what a "required extension" is.

Something that means "you must support extension X in order to
evaluate Y, if you don't support X then assume Z."

> If you add something that is mandatory for interoperability, you
> haven't created an extension, you have revised the protocol.  That
> would require a new version of SPF altogether.

We cannot do that for version 1.  However, version 3 could provide for
a feature that allows new extensions, even mandatory ones, without
requiring a new version of the protocol each time.

> That's fine, and probably a good idea, but that doesn't strike me
> as evidence of a problem with the charter.

The only nit with the charter is that it introduces the concept of SPF
extension, which is totally new AFAIK, /by example/, i.e. producing a
proposed extension and banning any other one, without referring what
an SPF extension actually is.  (Googling for "SPF extension" I found
some SQR Portable Format whose file names end that way.)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 19 Dec 2011 12:12:25 -0800

> Sent: Monday, December 19, 2011 12:04 PM
> To: [email-masked]
> >> what extensions are supported or required.
> >
> Something that means "you must support extension X in order to evaluate
> Y, if you don't support X then assume Z."

This is a totally foreign idea to me.  Can you point me to an existing example in any protocol?

> requiring a new version of the protocol each time.

Possibly, but do we need to spell out SPFv3 in an SPFbis charter?

> proposed extension and banning any other one, without referring what an
> SPF extension actually is.  (Googling for "SPF extension" I found some
> SQR Portable Format whose file names end that way.)

Section 6 of RFC4408 creates the extension mechanism by allowing for extension modifiers (which "scope" is), though it doesn't create an IANA registry for them.  I believe SPFbis intends to fix that.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Dec 2011 15:44:36 -0500

> some SQR Portable Format whose file names end that way.)

It's not new at all.  RFC 4408 anticipates such things via it's unknown 
modifier rule.  There have been a number of proposals for such extensions over 
the years.  There is one in progress in the MARF WG at the moment that looks 
likely to be the first one to make it to be an RFC.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 19 Dec 2011 13:52:53 -0800

> I have no objections to clarifying the modifier semantics that are already
The scope of the charter should have recommended changes to better 
mitigate SPF related threats, especially when mechanisms posing greater 
concerns are seldom used.  Potential incompatibilities should be weighed 
against added security.  Even Schlitt's SPF library used reduced limits 
for subsequent mechanism transactions in view of potential network 
amplifications (x300 with 512 byte message restrictions).  As such, 
eliminating the local-part "l" macro component,  the "exists" mechanism, 
and separate limits on no server or no domain errors would better limit 
overall risks.

Handling of email is highly automated where DNS plays an essential 
role.  The volume of DNS traffic makes abuse monitoring difficult both 
from sourcing and mitigation perspectives.  Mitigation incurs greater 
difficulty when a protocol can turn otherwise legitimate resolvers into 
DDoS agents.  Such threats increase with greater DNSsec use.

SPF seems unlikely to soon play an increased role.  Excessive overhead 
is caused by combining all hosts using either IPv4 or IPv6 into 
resolving a common set just to potentially validate authorization of a 
Delivery Status Notification path.  Such validation neither protects 
SMTP servers from abuse, users from spoofing, nor the Internet as a 
whole.  To achieve the desired protections, cryptographic methods to 
authenticate SMTP servers is needed instead.  IMHO, the authorization 
role of SPF can be safely replaced by ATSP.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Dec 2011 15:24:05 -0800

On 12/19/2011 11:05 AM, Murray S. Kucherawy wrote:
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alessandro Vesely Sent:
>> Monday, December 19, 2011 4:26 AM To: [email-masked] Subject: Re: [spfbis]
>> SPFbis WG scope
>>
> I'm at a loss to understand where all this rhetoric about forced extensions
> comes from.  A mandatory extension isn't an extension anymore, it becomes
> part of the base protocol, and I think the charter makes it clear that this
> isn't a goal of the working group.

An extension can certain declare normative behavior... if the extension is in 
force.  And the behavior can actual define modifications or new behaviors to the 
base protocol... if the extension is in force.

Beyond that, +1 to both the distinction between 'extension' vs. change of the 
base, as well as the clear intent to have spfbis avoid any additions to the 
protocol.

I believe that it is not (yet) out of scope to consider /simplifications/ to the 
protocol, by /removing/ features.  But of course, that's a matter for group 
consensus.

>> Failing that, I'd suggest that it be clarified in a prominent section of
>> your draft, rather than in the last paragraph.
>

+1

I do think it's worth querying folks about specific items to /remove/ from SPF. 
  I think this thread has introduced some possibilities.  I suggest that folks 
who believe something should be removed should post a fresh note about only that 
one item and with its own Subject: line.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 19 Dec 2011 19:30:15 -0800

On 12/19/2011 1:52 PM, Douglas Otis wrote:
> The scope of the charter should have recommended changes to better mitigate SPF
> related threats,

Document them.  Get community consensus about the need to 'fix' SPF.

Specify candidate changes to cover them.  Get community consensus that they are 
reasonable fixes or, at least, approaches to fixing the problems.

Then deal with the fact that such changes will be enhancements and therefore 
will slow down standardization of SPF.

Absent the above, you are, as usual, merely repeating the vague concerns that 
you've been expressing in many venues for many months.

Perhaps I've missed the groundswell of community support for your concerns? 
Goodness knows there has been plenty of opportunity for it to be expressed.

Absent that groundswell, this continual posting on the deficiencies of these 
technology looks an awful lot like a denial of service attack.

d/
-- 

   Dave Crocker

---

From: Tim Draegen <[email-masked]>
Date: Mon, 19 Dec 2011 23:30:34 -0500

> I would also add that all of the other points raised are explicitly out of scope per the proposed charter.  The discussion then needs to be about whether the scope should change to include them, or…

As of now I'm current on this thread, and I'd like to reiterate support for the proposed charter (I've previously published my support and reasoning for it).

I see no reason for the scope of the charter to expand to include any of the bits in this thread.  The only charter-changing proposal I could find is:

On Dec 19, 2011, at 4:52 PM, Douglas Otis wrote:
> The scope of the charter should have recommended changes to better mitigate SPF related threats, especially when mechanisms posing greater concerns are seldom used.

I'm of the mind to relegate an effort to "better mitigate SPF related threats" to a proper research project - outside of the IETF - where "SPF related threats" can be defined, measured, and demonstrated.  To use risk-management language -- such an effort will likely yield scenarios that are both extremely low in probability of occurring and extremely low cost in terms of damage.

Sans real data showing otherwise, it doesn't make sense to me to change the charter to introduce work that may or may not fix a problem that hasn't been shown to exist yet.  I'd like to reiterate my support for the existing scope of the WG as presented in the proposed charter.

-= Tim

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 00:52:44 -0500

On Monday, December 19, 2011 03:24:05 PM Dave CROCKER wrote:
> I believe that it is not (yet) out of scope to consider simplifications to
> the  protocol, by removing features.  But of course, that's a matter for
> group consensus.

I think it's only in scope for features that aren't used or to resolve 
demonstrated operational problems.  I don't think it's in scope to remove 
something based on theorizing that features which are in use may be in some 
way harmful.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 04:00:43 -0500

Douglas Otis wrote:

> IMHO, the authorization role of SPF can be safely replaced by ATSP.

DKIM/ADSP+ (w/ extensions)  can only help non SPF setups or SPF setups 
with SOFT FAIL results (~ALL), not for HARD FAIL (-ALL) SPF policies. 
  The SPF -ALL policies 100% reduces the effectiveness and need for 
DKIM or its related technologies.  SPF still helps address the legacy 
abuse of NON-DKIM mail abusers and if the Author-Domain is different, 
it doesn't help.

We need to remember the #1 benefit of SPF and DKIM technologies -  you 
can only 100% get with false positives results with your own DOMAINS - 
not others.  So that is the #1 need all SPF and DKIM setups must first 
address in their setups - first protect your own domains.

While:

    SPF HARD FAIL policy is effectively the same as ADSP DISCARDABLE 
policy.
    SPF SOFT FAIL policy is effectively the same as ADSP ALL policy.

In short, you still need both because receivers may support SPF and/or 
ADSP+ or both (or none).

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

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 04:09:54 -0500

> indicated by your subject line.  Are you saying this WG should not exist?

Julian, in IMO, Doug's main point was missed and its one of my 
problems with the proposed charter.

SPF is a not a payload technology and any idea that attempts to 
promote payload processing MUST BE carefully scrutinize for the same 
reasons SENDER-ID had problems.

Any idea that promotes PAYLOAD transfers is going to have a problem 
out of the gate.

Again, don't under estimate this problem and concern with the scope 
extension. Microsoft had to produce the SUBMITTER protocol as a 
compromising solution to pass the PRA to 5321 level only SPF 
processing. IMO, this solves the same problem you are trying to 
address, so I have a problem why this scope= extension is needed if 
SUBMITTER is already available and supported by many SPF receivers.

AGAIN, whatever is consider, you are not sympathetic to the sensitive 
nature of avoiding payload transfers, then the adoption of this scope= 
extension will have a barrier and even even higher if comes with 
semantics that mandate any form of behavior change to preempt the SMTP 
processing and download the payload.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Dec 2011 13:50:00 +0100

On 19/Dec/11 21:12, Murray S. Kucherawy wrote:
>
> Section 6 of RFC4408 creates the extension mechanism by allowing
> for extension modifiers (which "scope" is), though it doesn't
> create an IANA registry for them.  I believe SPFbis intends to fix
> that.

I welcome the IANA registry.

For the charter, I just noted that the term "extension", consistently
with the wording of RFC 4408, does not appear in Julian's draft
(although the short title mentions "extended scopes").  OTOH, I see no
occurrence of the term "modifier" in the charter's text --the version
posted on 30 Nov.  I assume that's something that we can live with...

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 11:50:27 -0500

> reasons SENDER-ID had problems.

I don't think that was Doug's main point at all (I'm not sure he had one, but 
I'm pretty sure that this isn't it).

Sender ID tried to do a number of things and did many of them wrong (IMO).

> Any idea that promotes PAYLOAD transfers is going to have a problem

The idea isn't to promote payload transfers, but if you are going to go to 
DATA and eat the payload anyway, is there something useful you can do.  Since 
this is a totally opt-in approach (unlike Sender ID), I don't see an issue.

> SUBMITTER is already available and supported by many SPF receivers.

None of the SPF implementations I'm aware of support it (I'm not saying there 
aren't implementations that do, but that the primary open source 
implementations don't).  Since the extension being proposed for the charter 
doesn't use PRA, I think Submitter is irrelevant.  In the end, Sender 
ID/PRA/Submitter can be trivially made to select an identity other than the 
one the user sees.  The proposed extension tries to do something much narrower 
and I think more likely to be useful.

> processing and download the payload.

I don't think anyone is arguing anything different.  Nothing in the proposed 
extension mandates anything about receiver policy (RFC 4408 itself is almost 
void of receiver policy mandates by design).  Receivers will determine if they 
want to accept the payload or not and this extension won't affect that.

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 09:17:36 -0800

> something based on theorizing that features which are in use may be in some

Scott, the above is helpful.  It suggests criteria and that's what I think we 
should discuss and agree on.

Determining factual points, such as what is or is not used, can be a challenge, 
but at least the question is about objective points rather than opinions about 
wonderfulness.

My own view of criteria:

1.   Unused

      A feature that has not yet received a significant degree of use should be 
dropped.

      For a feature that creates significant complexity, it is actually 
important to drop it, since complexity invites programming and operations 
errors.  Examples of complexity are recursion, indirection or complicated 
decision-trees.

2.   Problematic

      Features that have established a pattern of causing significant, 
widespread problems for which there are no obvious fixes.

3.   Specification Clarity

      This is /not/ a basis for removing something, unless we find that we 
cannot figure out how to write a clear specification.  Improving specification 
clarity is, in fact, the primary constructive work of this phase in a 
specification's life.

I don't know how Scott's above second sentence relates to the list.  I'm not 
sure what is meant by 'theorizing', but I'll take a guess:  Something has not 
yet established a pattern of causing problems (or benefit) but a static analysis 
points in the direction that it will or should.

My own opinion is that if something is used and has not already demonstrated a 
pattern of being problematic, it is not a reasonable candidate for removal, no 
matter how much some folk might wish to remove it.  The particular basis for 
retention is stability:  we need to make as few changes to the operational base 
as we can reasonably get away with.

d/
-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 09:19:10 -0800

> I'm pretty sure that this isn't it).

Trying to guess or assert what someone else meant is almost never productive. 
In fact, it's often the path down a rathole.

Either they've said things clearly or they haven't.  It's their responsibility 
to offer clear statements and to recruit support for them.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 12:46:12 -0500

On Tuesday, December 20, 2011 09:17:36 AM Dave CROCKER wrote:
> > something based on theorizing that features which are in use may be in
> > some way harmful.
> 
> Scott, the above is helpful.  It suggests criteria and that's what I think
> we should discuss and agree on.

Thanks.

> Determining factual points, such as what is or is not used, can be a
> challenge, but at least the question is about objective points rather than
> opinions about wonderfulness.

Agreed.
> 
> My own view of criteria:
> 
> 
> 1.   Unused
> 
>       A feature that has not yet received a significant degree of use should
> be dropped.
> 

Fortunately, for SPF, I think most of the questions around feature use can be 
resolved by examining SPF records published in DNS, so there's no need to 
guess about what people are using.  We do need to keep in mind that sometimes 
a feature might be not used broadly, but very significant for specific use 
cases.  Since there are multiple independent implementations that are 
available for inspection, I think determining if features are problematic to 
implement is a tractable problem.

> widespread problems for which there are no obvious fixes.

Agreed.

> cannot figure out how to write a clear specification.  Improving
> specification clarity is, in fact, the primary constructive work of this
> phase in a specification's life.

Fortunately a lot of work around this has been done already.  Based on a 
paragraph by paragraph (and in some cases line by line) review of RFC 4408, 
the people active in SPF development at the time produced a test suite:

http://www.openspf.net/Test_Suite

This is meant to provide data inputs and outputs for protocol compliance.  
Where there were differing opinions about the specified output, they were 
documented and a preferred result defined based on the rough consensus of the 
people doing the work.  This test suite has been used by at least three 
independent SPF library implementations (for Perl, Python, and Java).

Based on that body of work, there is already a good basis for consideration of 
where the specification needs refinement.

> sure what is meant by 'theorizing', but I'll take a guess:  Something has
> not yet established a pattern of causing problems (or benefit) but a static
> analysis points in the direction that it will or should.

Or that some people think it will.  SPF has been in widespread use long enough 
now that I believe that the potential for major operational suprises with the 
current protocol is small.

> My own opinion is that if something is used and has not already demonstrated
> a pattern of being problematic, it is not a reasonable candidate for
> removal, no matter how much some folk might wish to remove it.  The
> particular basis for retention is stability:  we need to make as few
> changes to the operational base as we can reasonably get away with.

Agreed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Dec 2011 12:52:28 -0500

> this is a totally opt-in approach (unlike Sender ID), I don't see an issue.

It's an issue depending on the RFC 2119 language that will be used and 
a new market of people using something that will not be supported 
widely unless there is a strong "recommendation" to support it.

In other words, will people depend on scope= tag usage and prepare 
correct author-domain::ip associations and will ignore correct 
return-path-domain::ip associations?

I say that is exactly what is going to happen and high likelihood of 
experiencing more failures.

> implementations don't).  

We supported SUBMITTER since the beginning and I have years of logs 
that show clients are indeed sending the SUBMITTER= keyword with the 
5321.Mail From command.  In fact, it is so prevalent that we have to 
make sure it recorded and remains persistent in any sort of forwarding 
with additional mail software.

> Since the extension being proposed for the charter 
> doesn't use PRA, I think Submitter is irrelevant.  

And thats another concern of mine where we begin to decide things 
because if one owns knowledge of what's happening and doesn't reflect 
the total market.  The PRA "Purported Responsible Author" for the most 
part is the AUTHOR-DOMAIN.

> In the end, Sender 

I disagree its more narrower because it will only work by pushing a 
PAYLOAD download requirement.  Otherwise it is useless, and that fact 
is very troublesome and material for an appeal.  Opt-in or not, its 
changes the SPF protocol and if you have options like this, it will be 
used and that changes the framework of the protocol unlike what SPF + 
SUBMITTER did.

> want to accept the payload or not and this extension won't affect that.

I disagree. If you put something in the spec that will only work by 
requiring the payload, then that inherently begins to change the 
fundamental framework of SPF.

Many systems will reject at the SMTP level and not allow the DATA 
state to be reached. This extension is proposing to change that and 
thats very troublesome and I don't think this is BIS work.

You will have to use an v=SP3 and if SP3 is stronger in mandating the 
payload download, not because you are not saying it is, but rather it 
is the only purpose to make it work, we now have compliancy issues 
with those that may want to use the clean BIS improvements and ignore 
this scope extension.

At the end of the day,  this is violating the boundary layers and it 
will certainly be problematic and indicating its "opt-in" is not an 
excuse for breaking the SPF protocol fundamentally.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 10:00:44 -0800

On 12/20/2011 9:46 AM, Scott Kitterman wrote:
> guess about what people are using.

Hmmm.  That's certainly the best place to start.  I'm wondering whether it is 
always definitive?

Often choices are made by default rather than intent, such as copying someone 
else's files.  In addition, there's the small question of whether the 
receive-side pays attention to the usage.  If something is widely used by 
publishers but widely /ignored/ by receivers, what is the justification for 
retaining it?

 >  We do need to keep in mind that sometimes
> cases.

Right.  And trying to understand market /segments/ can be a challenge.  But it's 
certainly important to try, for the reason you cite.

> Fortunately a lot of work around this has been done already.

Ack.  My list was for due-diligence on the question of criteria, not to imply 
anything about SPF particulars (yet...)

> current protocol is small.

The mere passage of time and even the mere fact of widespread use are not 
necessarily definitive proof that there will be no new surprises.  Certainly 
extensive time and use provide a prima facie case, but we should explore any 
concerns that do get raised for plausible dangers.

Anyone believing there are new surprising lurking has the responsibility to make 
their case and make it compelling.  The rest of us have the responsibility to 
consider the concern constructively, rather than be too quick to dismiss the 
concern.

Again, I'm being formally diligent here, not claiming any expectation about SPF.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 10:17:03 -0800

> Sent: Tuesday, December 20, 2011 4:50 AM
> To: [email-masked]
> > Section 6 of RFC4408 creates the extension mechanism by allowing for
> > extension modifiers (which "scope" is), though it doesn't create an
> > IANA registry for them.  I believe SPFbis intends to fix that.
> 

A modifier in SPF terms is an extension in general terms.  So yes, I think that mushy language is tolerable at this point.  We can just be careful how they're spelled out in the drafts.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 10:21:38 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Tuesday, December 20, 2011 9:18 AM
> To: Scott Kitterman
> Cc: [email-masked]
> Scott, the above is helpful.  It suggests criteria and that's what I
> think we should discuss and agree on.
> 
> challenge, but at least the question is about objective points rather
> than opinions about wonderfulness.
> 
> My own view of criteria:
> 
> 1.   Unused
> 
>       A feature that has not yet received a significant degree of use
> should be dropped.
> 
> important to drop it, since complexity invites programming and
> operations errors.  Examples of complexity are recursion, indirection
> or complicated decision-trees.

For a real world example, between RFC4871 and RFC6376, DKIM dropped "g=" from key records.  Observation of signatures received over a long period showed near-zero use of that feature.

Are there any installations that are collecting the properties of observed SPF records that might be able to tally up which modifiers/extensions/whatever are actually in use out there?  If not, could such be constructed easily?

> clarity is, in fact, the primary constructive work of this phase in a

One thing that might be worth clarifying, which has already come up, is the "modifier" vs. "extension" point.  I think it's fine the way it is, but Alessandro's pointed out the potential for a mis-read.  We might want to take a run at fixing that, and be careful about naming the proposed IANA Registry, etc.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 10:37:37 -0800

On 12/20/2011 10:21 AM, Murray S. Kucherawy wrote:
>> 3.   Specification Clarity
>> >
>> >         This is/not/  a basis for removing something, unless we find that we

In an earlier note, you used the word 'mushy'.  It turns out that it is apt 
vocabulary with respect to my brain, today, for this issue.  I'm not 
understanding the issue or the choices.

Pedagogy about this, using simple words and sentences, would be appreciated.

Thanks and sorry.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 20 Dec 2011 10:47:04 -0800

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Tuesday, December 20, 2011 10:38 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> In an earlier note, you used the word 'mushy'.  It turns out that it is
> apt vocabulary with respect to my brain, today, for this issue.  I'm
> not understanding the issue or the choices.
> 

An SPF record can contain several different kinds of "clauses", such as:

	v=spf1 +mx a:colo.example.com/28 -all

The first ("v=spf1") is a version clause.  The remaining set in this example are all called "directives".  In this one:

	v=spf1 redirect=_spf.example.com

The latter is called a "modifier".

A directive is composed of a qualifier (+/-/?/~) followed by a "mechanism".  The set of mechanisms is fixed in RFC4408, which means adding one requires a redefinition of the protocol.  However, the set of modifiers is fluid insofar as unrecognized ones are to be ignored, but RFC4408 didn't create an IANA registry of these, which is something this group will have to fix.

Thus, the available extension mechanism is the declaration of new modifiers.  The "scope" extension document refers to itself as an extension, not a new modifier.  That's the mushy language that probably could use some tidying in one of the documents or both.

-MSK

---

From: Tim Draegen <[email-masked]>
Date: Tue, 20 Dec 2011 13:48:07 -0500

> Are there any installations that are collecting the properties of observed SPF records that might be able to tally up which modifiers/extensions/whatever are actually in use out there?  If not, cou…

Aye.  We have the technology.  Glad to dig in and share once the WG gets its legs.

-= Tim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Dec 2011 12:14:54 -0800

> Sans real data showing otherwise, it doesn't make sense to me to change the charter to introduce work that may or may not fix a problem that hasn't been shown to exist yet.  I'd like to reiterate m…
Here is draft demonstrating reflected network gain resolving 
authorization for a single return path using existing SPF libraries 
based upon essentially the existing draft.  The system sending the 
message may be unaware of the results caused by the resolution of the 
return path requested by the submitter.

http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01

The demonstration spf record using 10 mechanisms was as follows:

cert-test.mail-abuse.org.  IN  TXT  "v=spf1
     mx:0.%{l}.%{d} mx:1.%{l}.%{d} mx:2.%{l}.%{d}
     mx:3.%{l}.%{d} mx:4.%{l}.%{d} mx:5.%{l}.%{d}
     mx:6.%{l}.%{d} mx:7.%{l}.%{d} mx:8.%{l}.%{d}
     mx:9.%{l}.%{d} ?all"

Assuming PRA is never resolved, this illustrates how a small email

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Dec 2011 15:42:19 -0500

On Tuesday, December 20, 2011 12:14:54 PM Douglas Otis wrote:
...
> http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01
...

This is a 2006 draft that has been given a thorough technical scrub:

http://www.openspf.net/draft-otis-spf-dos-exploit_Analysis

The conclusion at the time was that the alleged threats are not particularly 
SPF unique.  I don't know of any reason to believe that's changed.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Dec 2011 14:24:31 -0800

> SPF unique.  I don't know of any reason to believe that's changed.
http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01#appendix-B

Perhaps I am at fault for not making examples more explicit.  
Nevertheless, this draft clearly shows in exacting and non-theoretical 
terms that resolving a single SPF Return-Path authorization using a 
compliant SPF library can cause recipients to issue 40,436 bytes in DNS 
requests directed against victim domains not seen within messages.  This 
amount can double when PRA is resolved as well. The requests are 
initially prompted by 29,650 bytes from an attacker's DNS.

Because SPF includes "l" local-part macro constructs, answers for 
"[email-masked]" can not be assumed the same as that for 
"[email-masked]".  In addition, the 100 NX domains issued by victim's 
name servers NEVER caused the SPF compliant library to quit.  In fact, 
SPF could have ended with "+all" and obtain PASS in addition to the DDoS 
aimed at anyone's DNS.

Spammers often cycle originating local-parts in campaign runs.  Once a 
run extends beyond the negative caching interval employed by their 
recipients, repeating the sequence will satisfy subsequent queries for 
MX records from cache.  Ignoring the relatively smaller bandwidth used 
in the related activity called spamming, the overall DNS DDoS gain 
becomes extremely large without even leveraging EDNS0 extensions.

Any value from SPF records can not be obtained when local-part macros or 
"exists" mechanisms are used.  Use of APL RRsets (RFC3123) provide 
safer, more extensive and extendable information.  There is 
justification for overloading TXT RRsets.

-Doug

---

From: Tim Draegen <[email-masked]>
Date: Tue, 20 Dec 2011 17:56:46 -0500

On Dec 20, 2011, at 5:24 PM, Douglas Otis wrote:
> Perhaps I am at fault for not making examples more explicit.  Nevertheless, this draft clearly shows in exacting and non-theoretical terms that resolving a single SPF Return-Path authorization using a compliant SPF library can cause recipients to issue 40,436 bytes in DNS requests directed against victim domains not seen within messages.  This amount can double when PRA is resolved as well. The requests are initially prompted by 29,650 bytes from an attacker's DNS.

It was very difficult for me to understand this draft, but I believe I now get it.  Then Scott Kitterman pointed me to Julian Mehnle's write up; I'm clear.

I agree that this attack vector is not unique to SPF.  As a one-time implementor of high-volume DNS servers, I don't see this particular attack as being viable.  In a research environment, maybe.  But the cost of constructing this attack does not make the resulting DoS attack very likely.. if the actual effect is considered to be anything more than a nuisance.  Toss in caching (there appears to be some confusion in the draft on how modern DNS caches work in terms of ability to clear caches by overflowing them when junk results -- its not that simple), and the threat is reduced to "low in probability of occurring and extremely low cost in terms of damage".

Given the reality of today's internet and constant DoS attacks against various services, there are easier and cheaper ways to get this job done.  I believe this write up (or maybe a far simpler one) would have greater impact as guidance to SPF developers to make sure they write better code.

=- Tim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Dec 2011 15:53:10 -0800

On 12/20/11 2:56 PM, Tim Draegen wrote:
> I agree that this attack vector is not unique to SPF.  As a one-time implementor of high-volume DNS servers, I don't see this particular attack as being viable.  In a research environment, maybe.
Tim,

The test demonstrated a _simple_ SPF record can attack _any_ DNS server 
not related to any domain supporting the email exchange.  It does not 
take a research environment to construct the attack since it does not 
require _any_ knowledge of the victim's DNS.  It simply takes advantage 
of poorly considered constraints placed upon SPF macros able to 
introduce any portion of an email-address local-part or domain into a 
request.  This ability permits DNS prompting to originate from any 
unrelated domain and directed toward any other unrelated domain.  This 
attack can be sustained from domains unrelated to those supplying the 
initial SPF record.  Such an ability allows attacks to side-step 
reputation filters, for example.
> But the cost of constructing this attack does not make the resulting DoS attack very likely.. if the actual effect is considered to be anything more than a nuisance.
A 150x gain (based upon a single email message sent to a single 
recipient) is only a nuisance?  Much of this traffic originates from 
compromised systems numbered in the millions that will be sending spam 
anyway.  Why allow DoS of DNS to be virtually free as well?
> Toss in caching (there appears to be some confusion in the draft on how modern DNS caches work in terms of ability to clear caches by overflowing them when junk results -- its not that simple), and the threat is reduced to "low in probability of occurring and extremely low cost in terms of damage".
The clearing of caches is not in question!  Better caching will increase 
the effectiveness of an SPF initiated DoS attack.  The attack is not 
against the reflectors, it is against targeted victims.  These 
reflectors likely represent legitimate resolvers which makes any remedy 
disruptive, if not impossible.
> Given the reality of today's internet and constant DoS attacks against various services, there are easier and cheaper ways to get this job done.  I believe this write up (or maybe a far simpler one…
The reason for the extensive sequence was to illustrate the potential 
level of activity from a single 1KB message using the SPF strategy 
purportedly aimed at mitigating abuse.  The activity logged clearly 
illustrates the potential for reflected activity caused by use of this 
poorly considered macro language.  The definition of this protocol 
should be modified into a much safer form.  It is unwise to expect 
implementations will exceed the qualify of the protocol specifications.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 20 Dec 2011 22:02:16 -0800

On 12/20/2011 2:56 PM, Tim Draegen wrote:
> I agree that this attack vector is not unique to SPF.

This continues the consistent pattern of responses that assess the concern as 
being outside the scope of the current working group.

I have seen no pattern of comments that support pursuing the concern in this 
working group.  (Nevermind pattern, I haven't seen /any/ support.)

d/
-- 

   Dave Crocker