Subject: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-06.txt

From: [email-masked]
Date: Wed, 22 Aug 2012 21:40:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SPF Update Working Group of the IETF.

	Title           : Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
	Author(s)       : Scott Kitterman
	Filename        : draft-ietf-spfbis-4408bis-06.txt
	Pages           : 66
	Date            : 2012-08-22

Abstract:
   Email on the Internet can be forged in a number of ways.  In
   particular, existing protocols place no restriction on what a sending
   host can use as the "MAIL FROM" of a message or the domain given on
   the SMTP HELO/EHLO commands.  This document describes version 1 of
   the Sender Policy Framework (SPF) protocol, whereby an ADMD can
   explicitly authorize the hosts that are allowed to use its domain
   names, and a receiving host can check such authorization.

   This document obsoletes RFC4408.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spfbis-4408bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-spfbis-4408bis-06

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 23 Aug 2012 00:44:50 -0400

On Wednesday, August 22, 2012 09:40:25 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the SPF Update Working Group of
> the IETF.
> 
> 	Title           : Sender Policy Framework (SPF) for Authorizing Use of
> Domains in Email, Version 1 Author(s)       : Scott Kitterman

There is nothing radical in this update, but it seemed like there was enough 
change to make it better to publish the latest.  This includes many changes 
discussed on the list, but not yet the new security consideration that Hector 
proposed (Issue #33), since we don't seem to have converged on anything yet.

I believe that I've addressed all the other recent suggestions for changes.  
If I've missed something, please let me know.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 00:01:08 -0400

Scott,

Trying to figure out where out points differ, I think perhaps there is 
a presumption that all backends support user level policies or methods 
with automatic spam folder sorting/separation.  If so, I don't think 
that can be automatically assumed, it needs to be highlighted that it 
is important.  In this case, then the only security issue could be 
isolated to the RFC-based OFFLINE MUAs (Outlook, Live, TBird, Eudora, 
Opera, etc).  But I think it is safe to suggest that we normally can 
not place a high dependency on offline store and forward based MUAs to 
have the special protection required passed off to users via ACCEPT+MARK.

For the sake of an example, we would not be able to support 
Accept+Mark until separation is made available. We could only support 
SPF hard failures with a reject. We can not support Accept+Mark 
because our stock product does not separate mail in this way.  We have 
in total six different ways mail can be access (MUA) for our total 
mail framework product line.

1) Telnet:  telnet bbs.winserver.com
    MUA with Console/ANSI/VT100/102 Terminal Support

2) Frontend Native GUI MUA,
    http://www.winserver.com/public/wcnavigator.wct

3) Web-based MUA
    http://www.winserver.com

4) Sysop Editor with powerful mail management features (Stock)
4.1) Several 3rd party editors using our API

5) MAPI API hook for Outlook (Uses Exchange technology, obsolete)

6) Support for RFC based Offline/Online MUA NNTP 
(news://news.winserver.com)

7) Support for RFC based Offline MUA POP3 mail pickup

Overall, unless the logic is built in to separate, we will be exposing 
users to potentially harmful mail with any of these online and offline 
MUA methods.

So I guess, if you believe it is a presumed all MDA will separate 
mail, then maybe your text is sufficient. But that would be a rather 
large presumption of backend behavior. I am saying we can't 
automatically assume this design is natural for all backends and for 
this specific (accept+mark) mode, SPF -ALL protection is lost is 
separation is not part of the backend mail operations.

I really don't know how else I can state it.  We can't support 
ACCEPT+MARK simply because our mail software is not ready for it out 
of the box.  For SPF, a reject mode is the only filter and only for -ALL.

If we add a new option for example:

   SPF-HardFail-Action     Reject|AcceptMark   # default Reject

We will now be force to redesign the software to add different mail 
bins for users.  This is currently being done (sorting) by 3rd party 
mail bots but we can't depend on them to do this themselves for 
Received-SPF: fail results.   We need to make sure that out of the 
box, there are no surprises for any of the mail access methods for SPF 
accept+mark failed messages. It would not be made available and only 
Reject would be possible until the separation management logic is 
available.

Hope that better explains this.

Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Aug 2012 14:05:49 -0400

I don't expect anything of MDAs or MUAs.  I think highlighting the concern is where the demarcation between the Internet protocol and MDA/MUA is best drawn.  It's not a question of what they should or shouldn't do, but defining boundaries for the system under consideration.  Step one in any system engineering effort is to draw the boundary of your scope.

I don't think the current language in 4408bis requires you to implement any new receiver policy.  The fact that there is non-normative text that describes one approach for SPF receiver side doesn't obligate you to support it.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 14:22:24 -0400

Scott

I see your objection now and Levine's confusion now.

Please read the proposal again and my follow up.  The resolution of 
this security issue with accept-failures-mark operations can not 
depend on the MUA to resolve.  The BACKEND would need to resolve it.

I hope I did not convey the idea that an MUA can resolve this. Of 
course, in theory it CAN but as stated in the proposal, it would 
require to be an ADVANCED MUA.

This needs to be resolved at the BACKEND so that regardless of the 
connectivity, the mode of user mail access, the user is not exposed to 
the accept+failed+marked mail without some special form of backend 
display rendering.

I provided examples of this with Hotmail in the April/May message. I 
repeated yesterday with the gmail example, and I illustrated how the 
6-7 multiple Mail Access methods AKA (MUA methods) we have all need to 
have the backend to resolve it.

The proposal states in the final paragraph:

    Backends needs to take precautions of marking messages resulting
    from SPF -ALL failed transactions but were not rejected as
    prescribed in section 2.5.4.

I don't see that saying anything regarding MUAs dependencies, nor 
backend mandate to resolve it, but a security precaution and insight 
to be aware.   Ideally, I would like that to be stronger, like

     "The backend MUST separate the accept+failed+marked messages"

but I don't think that would be acceptable.  But then again, who 
knows, that may depend on who states it.

-- 
HLS

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Aug 2012 14:49:03 -0400

Hector,

> depend on the MUA to resolve.  The BACKEND would need to resolve it.

If I understand your suggestion, it sounds very much like a
modification of what RFC 4408 says.  Am I correct about that?  If not,
how?

If I understand the discussion, it sounds like this modofication is
not an enhancement "that ha[s] already gained widespread support" as
required by our charter, since several people seem opposed to your
suggestion.  If I am incorrect about this, please provide an argument
as to why.

If I am correct in my understanding, then I do not believe we are
chartered to make the change you request.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Aug 2012 14:55:28 -0400

I disagree.  In most cases when SPF is used as one input out of many, some of the inputs will require inspection of message content and that's not properly the business of an MTA.  This is an MDA/MUA issue.

Scott K

Hector Santos <[email-masked]> wrote:

>> I don't expect anything of MDAs or MUAs.  I think highlighting the
>concern is where the demarcation between the Internet protocol and
>MDA/MUA is best drawn.  It's not a question of what they should or
>shouldn't do, but defining boundaries for the system under
>consideration.  Step one in any system engineering effort is to draw
>the boundary of your scope.
>> 
>> I don't think the current language in 4408bis requires you to
>implement any new receiver policy.  The fact that there is
>non-normative text that describes one approach for SPF receiver side
>doesn't obligate you to support it.
>> 
>> Scott K
>> 
>>>>> 	Title           : Sender Policy Framework (SPF) for Authorizing
>Use
>>> of
>>>>>    host can use as the "MAIL FROM" of a message or the domain
>given
>>> on
>>>> There is nothing radical in this update, but it seemed like there
>was
>>> enough

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 24 Aug 2012 11:57:30 -0700

> I disagree.  In most cases when SPF is used as one input out of many, some of the inputs will require inspection of message content and that's not properly the business of an MTA.  This is an MDA/M…

Does that mean MTAs shouldn't be doing inline spam filtering or DKIM
evaluation?  Many do.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 24 Aug 2012 15:07:00 -0400

"Murray S. Kucherawy" <[email-masked]> wrote:

>> I disagree.  In most cases when SPF is used as one input out of many,
>some of the inputs will require inspection of message content and
>that's not properly the business of an MTA.  This is an MDA/MUA issue.
>

DKIM doesn't care what the content is (only that the body hash matches), so I think that's fine.  Personally, I see spam/virus filtering as an MDA function.  I would be surprised if everyone agreed.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 15:51:55 -0400

Andrew Sullivan wrote:
> modification of what RFC 4408 says.  Am I correct about that?  

I don't believe so.

> If not, how?

Many ways to review this and explain it. Obviously I have not been 
successful in clearly stating it and its quite frustrating to 
understand why that is the case.  I tried to explain it many different 
ways, from many angles.

There is no mandate or change being advocating outside the fact that 
4408BIS is gaining a new focus for ACCEPT+MARK methods of operations 
(based on the input here).  Despite on how real that is,  the 
protocol, IMV, MUST provide insight on the security impact of using 
one of two alternatives where one is 100% secured and the other is not 
unless the additional methods in the protocol defines it so.

I honestly do not know how else to state this.  I even used my own 
system where it would not be feasible to switch to a ACCEPT+MARK for 
the very reason cited by the security note.  We would need to begin to 
separate the mail in the stock software otherwise a loophole is opened 
up by accepting plus marking the failed mail.  According to our latest 
August 2012 stats,

http://www.winserver.com/public/spamstats.wct

SPF yields 16% among the total 82% rejection rate of the transactions. 
  By switching to accept+mark, we would be exposing these currently 
SPF -ALL rejects to end users.  Having this security note will help 
implementators under the same situations.

Consider the alternative, by not having the security note, in effect, 
4408 is mandating a certain design all mail systems must have to help 
protect the accept+mark mail recipients and the domains that are using 
-ALL.

I am not going that far. My security note helps in avoid this implicit 
consideration for a specific user level policy mail design where SPAM 
FOLDERS are par for the course.

> suggestion.  If I am incorrect about this, please provide an argument

There seems to be an misunderstanding of an old and often discussed 
view that MUA can be part of the solution for SPF and even DKIM.  That 
is not what the proposal is asking for the same reasons consensus 
always had - the backend is better equip to do the mail filtering to 
help/assist the layman user and also one where we can not practically 
mandate how various offline RFC-BASED Mail Reader/Writers will behave 
and/or when they will be updated.   In other words, unless the backend 
can control the access and rendering,  the backend can not put trust 
on 3rd party MUAs.

> chartered to make the change you request.

There is no request for a change.  This is a security loophole with 
the accept+marked protocol option for -ALL policies where 2.3 has MUST 
level language for what a DOMAIN needs to do in order to get a 
negative filter consideration by the receiver.

-- 
HLS

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Aug 2012 16:10:57 -0400

On Fri, Aug 24, 2012 at 03:51:55PM -0400, Hector Santos wrote:
> SPF yields 16% among the total 82% rejection rate of the
> transactions.  By switching to accept+mark, we would be exposing
> these currently SPF -ALL rejects to end users.  Having this security
> note will help implementators under the same situations.
> 
> Consider the alternative, by not having the security note, in
> effect, 4408 is mandating a certain design all mail systems must
> have to help protect the accept+mark mail recipients and the domains
> that are using -ALL.

I think you may be conflating "implementation" and "deployment" here.

I think you have observed, correctly, that under some deployment
scenarios the MTA that receives mail that does not pass a check
probably does need to reject the mail, because that MTA's clients may
not have the capability to evaluate the mail in question.  That is not
the same thing, however, as saying that this or that action on the
part of the MTA are required as part of the protocol, for
interoperability reasons strictly construed.  

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 20:24:51 -0400

> I think you may be conflating "implementation" and "deployment" here.

Perhaps, since we are software vendors with an implementation that 
need to service various deployment options, methods and flexibility. 
We also have our own support site and I champions and users of the 
products we design, develop and market.  My responsibility is to lead 
my customers with the best options for them, out of the box, by 
default and hopefully it matches (I think so), practical and industry 
methods.

> interoperability reasons strictly construed.  

I think the topic has been pretty simple.  The protocol has semantics 
for a functional specification.  The technical specification reveals 
an security issue that in my engineering experience, MUST be noted, 
otherwise it can fall thru the cracks.  It has nothing to do with 
local policies, mandates, receiver vs sender policies,  This is a 
client/server protocol. The "S" in SPF does say "Sender" (client) but 
it means nothing with the Receiver (server).  Whatever the functional 
specs says is possible, is also important to make sure all views, 
including mail security related, are make available.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 24 Aug 2012 20:28:29 -0400

correction:

Hector Santos wrote:
> for a functional specification.  The technical specification reveals a 
> security issue that in my engineering experience MUST be noted, 
> otherwise it can fall thru the cracks.  It has nothing to do with local 
> policies, mandates, receiver vs sender policies,  This is a 
> client/server protocol. The "S" in SPF does say "Sender" (client) but it 
> means nothing without the Receiver (server).  Whatever the functional specs 
> says is possible is also important to make sure all views, including 
> mail security related, are made available.

-- 
HLS