Subject: [spfbis] FW: I-D Action: draft-mehnle-spf-scope-00.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Dec 2011 15:18:15 -0800

The missing draft has surfaced.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 01, 2011 2:40 PM
To: [email-masked]
Subject: I-D Action: draft-mehnle-spf-scope-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : "From" and other Message Header Fields as SPF Policy Scopes
	Author(s)       : Julian Mehnle
	Filename        : draft-mehnle-spf-scope-00.txt
	Pages           : 7
	Date            : 2011-12-01

   This document defines a new modifier for the SPF e-mail
   authentication protocol allowing the SPF record for a domain to be
   declared as being applicable to message identities other than the
   MAIL FROM identity, such as the "From" or "Sender" message header
   identities.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mehnle-spf-scope-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-mehnle-spf-scope-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 3 Dec 2011 00:58:24 +0000

All,

let me introduce the "draft-mehnle-spf(bis)-scope" document.

The document's introduction section should make the intent sufficiently 
clear, but in very few words:

SPF does not prevent the most relevant types e-mail phishing because it 
protects only the MAIL FROM identity, which is usually not exposed to the 
user by MUAs.  Sender ID tried to accomplish this by making the "From" 
header field subject of the authentication, but made two grave mistakes: 
(1) it allowed other identities that also aren't exposed to the user 
— "Resent-{From,Sender}" — to take precedence over "From", opening up a 
loophole, and (2) it broke compatibility with existing "v=spf1" policies 
by reusing them in an unexpected context.

The proposed "scope" extension avoids both of these mistakes, allowing 
domain owners to *opt in* to authentication of their domain in the "From" 
header field against "v=spf1" policies.

The importance of this extension lies in the need of large e-mail senders 
and receivers (secret cabal alert! the background will become public in a
few days!) for a path-based mechanism for authenticating the "From" header
field for certain (typically customer communication) types of e-mail 
domains.  SPF is widely deployed at these large e-mail senders and 
receivers and lends itself well to the problem — except for the fact that 
there is no standards-compliant and compatible way to apply it to the
"From" header field.  This extension seeks to provide it.

I unconsciously submitted the document as

    draft-mehnle-spf-scope

rather than

    draft-mehnle-spfbis-scope

Should I resubmit it under the latter name, which it is also being 
referred to as by the draft charter?

-Julian

---

From: SM <[email-masked]>
Date: Fri, 02 Dec 2011 20:12:58 -0800

Hi Julian,
At 16:58 02-12-2011, Julian Mehnle wrote:
>— "Resent-{From,Sender}" — to take precedence over "From", ", opening up a

Thanks for the clarifications about the 
document.  I suggest not getting into a 
discussion about the technical content while the charter is being discussed.

>referred to as by the draft charter?

The draft will be renamed once is it is adopted 
as a working group document.  The name could be changed then.

Regards,
-sm

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 02 Dec 2011 22:42:44 -0800

Folks,

On 12/2/2011 8:12 PM, SM wrote:
> The draft will be renamed once is it is adopted as a working group document.
> The name could be changed then.

If the working group's initial goal is to develop a standards-track version of 
SPF, then it needs to focus on this task and vigorously avoid activities that 
distract from the goal.

For an existing specification with widespread deployment, the standards effort 
needs the focus to be on stabilizing and refining specification for what is 
already deployed.  It should not simultaneously enhance the functionality 
provided in the specification.

As a consequence the working group charter should not provide for enhancements.

Once the initial standards-track specification is approved, the working group 
can recharter for pursuing enhancements.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Paul Midgen <[email-masked]>
Date: Sat, 3 Dec 2011 08:25:53 +0000

We need to align on our definition of "standards track SPF".

def #1: clean up 4408, making deletions or clarifications only (I'm opting for brevity over 100% correctness)

def #2: clean up 4408, making whatever modifications are necessary to reflect path authorization as it is done in practice. This implies additions as well as the deletions/clarifications in #1.

I'm more attracted to #2 because (from a receiver/webmail provider POV) I need the standard to enable me to legally test path authorization of the RFC5322.From domain, and I feel this gets us there sooner.

I do understand that from an IETF process perspective this may be the wrong way to do it, so in the spirit of "vision over implementation" I'm open to a WG charter that explicitly states #2 or commits us to #1, followed by the work to achieve #2 in whatever manner supported by operational data.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave CROCKER
> Sent: Friday, December 02, 2011 10:43 PM
> To: [email-masked]
> Cc: Julian Mehnle
> Subject: Re: [spfbis] draft-mehnle-spf(bis)-scope
> 
> Folks,
> 
> For an existing specification with widespread deployment, the standards
> effort needs the focus to be on stabilizing and refining specification for what
> is already deployed.  It should not simultaneously enhance the functionality
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Dec 2011 00:36:10 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Mehnle
> Sent: Friday, December 02, 2011 4:58 PM
> To: [email-masked]
> Subject: [spfbis] draft-mehnle-spf(bis)-scope
> 

No need; if/when it becomes a working group item, it will be renamed anyway.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 3 Dec 2011 00:49:02 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Once the initial standards-track specification is approved, the working
> group can recharter for pursuing enhancements.

This appears to contradict your earlier [1] sentiments that the proposed charter, which does include Julian's draft, is satisfactory.  It is, however, the only extension in scope for the initial charter we're discussing; the proposed charter proscribes all others.

As I've said before, I don't know how painful or painless a re-chartering can be.  If it's "easy", then I'd be fine with removing it for now.  But since it has some momentum behind it, we can possibly save ourselves that step simply by leaving the charter as-is and being diligent about tackling our few deliverables in sequence as much as possible.  I'm up for it.

-MSK

[1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00009.html

---

From: Dotzero <[email-masked]>
Date: Sat, 3 Dec 2011 15:02:03 -0500

> [1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00009.html

I don't know if this is considered an enhncement or a refinement but
someone from US Cert recently passed the following comment to me
regarding SPF:

"When the RFC is revised for the next version of SPF, would you mind
asking them to include language that specifies what delimiters are
appropriate for use in an SPF record?  I’ve seen tabs, spaces, cr, lf,
and pipes while scanning some domains."

-Mike

---

From: Julian Mehnle <[email-masked]>
Date: Sat, 3 Dec 2011 22:13:31 +0000

> and pipes while scanning some domains."

It would be a clarification, most likely in scope of SPFbis.  However, RFC 
4408 <http://tools.ietf.org/html/rfc4408#appendix-A> already specifies 
this:

    record           = version terms *SP
    version          = "v=spf1"

    terms            = *( 1*SP ( directive / modifier ) )

So terms (mechanisms or modifiers) are separated by one or more SP, which 
is defined by RFC 4234 <http://tools.ietf.org/html/rfc4234#page-14>:

    SP               =  %x20

It could be made clearer in 4408bis, of course.

-Julian

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 03 Dec 2011 21:52:49 -0500

On 12/03/2011 01:42 AM, Dave CROCKER wrote:
> If the working group's initial goal is to develop a standards-track
> version of SPF, then it needs to focus on this task and vigorously avoid
> activities that distract from the goal.
> 
> effort needs the focus to be on stabilizing and refining specification
> for what is already deployed.  It should not simultaneously enhance the
> functionality provided in the specification.
> 

I think we can manage the prioritization of the work by giving the one
proposed extension a spot on the schedule enough after 4408bis to make
it clear where the priority is.  I think there is enough interest in
both efforts that we can afford some degree of parallelism in the process.

Scott K

---

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

This note discusses some principles driving my views on the charter's scope and 
for some reason, higher-level constructs seem to require verbosity (for me, at 
least.)

On 12/3/2011 12:49 AM, Murray S. Kucherawy wrote:
> This appears to contradict your earlier [1] sentiments that the proposed
> charter, which does include Julian's draft, is satisfactory.  It is, however,
> the only extension in scope for the initial charter we're discussing; the
> proposed charter proscribes all others.

Well, self-contradiction isn't a goal.  If it's happening, it probably reflects 
more thought on the topic...

> As I've said before, I don't know how painful or painless a re-chartering can
> be.

It's subject to the vagaries of working group charter-writing tension and IESG 
charter-review tension.  I believe that a well-functioning working group that 
has so far been productive, typically has a reasonably easy time.  Unlike 
financial statements, past performance /is/ (usually) taken to be a predictor of 
future performance.

> If it's "easy", then I'd be fine with removing it for now.  But since it
> has some momentum behind it, we can possibly save ourselves that step simply
> by leaving the charter as-is and being diligent about tackling our few
> deliverables in sequence as much as possible.  I'm up for it.

It's clear it has some momentum on this list, as a topic.  That ought to be 
necessary for anything added to the charter, but I'll suggest strongly that it's 
not sufficient...

In case it is not clear, let me stress that nothing I'm posting on the topic of 
the charter has anything to do with my own technical opinions.  I am offering no 
comment on any feature, new or old, in terms of whether I 'like' it. I am solely 
concerned with what process is the most likely to produce a successful document. 
  I measure success in two way.  One is timely production of a document that 
gains standards status.  The second is that the document gains widespread use by 
the community.

The challenge in achieving that success is guessing the right balance of 
specification details to match what the market wants/needs.  In the case of an 
effort like SPFbis, it needs to hit the operational vector that the market has 
/already/ established.  That is, spf already is in use and this working group 
needs align with that reality very carefully. Certainly that sometimes requires 
adding features not in the existing specification, if the market is already 
using those features.  This is an example of that oft-touted and oft-forgotten 
-- yes, both, simultaneously -- documenting existing practice.

Where risk increases dramatically, for something that already has a significant 
installed base, is when the charter claims that the market wants something not 
yet in widespread use.  And to be clear, if it is not already in use /for the 
specific mechanism being discussed/, it does not qualify as being in widespread 
use for this discussion, no matter where else it might be in use; integration to 
a mechanism is inherently risky.

The assessment of the enhancement's need and efficacy might be entirely valid -- 
it might be a really good idea -- but I claim that the simple fact that the 
feature is not yet in widespread use makes adding it to an initial working group 
effort risky.  The principle reason for this is that it does not have objective 
data to dictate the details or the market demand.  It has guesses.  No matter 
how excellent the idea and insightful the guesses, they are still guesses. 
Guesses invite debate and they invite errors.  That's called risk.

In contrast, to justify its content, a document that is based strictly on 
existing practice only has the requirement to /document/ the existing practice; 
it does not have to figure out what will work. The 'risk' is  in observing 
existing practice, not guessing the vector to desired practice.

Assessing existing practice is not automatically trivial.  We have to be careful 
even with that modest requirement.  Assessing "desire" however is always a 
challenge, absent overwhelming market clarity and I am pretty sure we don't have 
that here.

So my strong recommendation is that we defer anything that is not already in 
widespread use, specifically for SPF.  (And for the purposes of the current 
discussion, I believe Sender-ID needs to be treated as independent of SPF.) We 
will have enough challenges in debating what to retain versus was to remove.

Once we have done that and achieved the very notable success of a 
standards-track document, it will be massively easier to pursue an enhancement, IMO.

d/

-- 

   Dave Crocker