Subject: [spfbis] Formal Request to Reopen ISSUE 29 to close security loophole

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 11:56:22 -0400

I am getting mixed input on issue 29 as closed or not.

I would like to have it reopen and proposed a new 10.7 section added 
to help implementators closed the SPF fail result security loophole.

10.7 Marked Failed Mail Exposure

    Section 2.5.4 and 9.3.2 reinforces the local policies concept
    that SPF receivers have no formal protocol requirement to
    enforce rejection of mail which were detected using -ALL policies.
    Section 2.3 highlights the domain intent and expectation for
    such negative classification.  However, the receiver is under
    no technical obligation to take any action for SPF failed results.

    If the alternative marking is done, it is conceivable local backends
    will still pass the mail to users with no additional red flags or
    indicators of SPF fail. This will require more advanced MUA to
    understand the Receive-SPF headers.

    Thus under such cases, there is a possibility users can be exposed
    to harmful mail when the backend added the Receiver-SPF but did not
    further separate the message from the user's normal everyday mode of
    reading/accessing mail.  For example, for POP3, the stream may need
    to be separated and not made available for pickup.  For online access,
    like Web-based Mail or IMAP, the backend has better control of how
    mail is filtered, sorted, displayed and rendered.

    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.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 10:01:01 -0700

Hi Hector,
>to help implementators closed the SPF fail result security loophole.

Issue #33 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/33 ) has 
been opened in response to the above request.  I will post a message 
to the SPFBIS mailing list when the topic is open for discussion.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 13:03:45 -0400

> I am getting mixed input on issue 29 as closed or not.

It's still open in the issue tracker.  The last status I put there is:

" New text in the -04 draft should address this issue.

Waiting for WG review.'

As I've said many times before, me putting something in a draft doesn't carve 
it in stone.

>     prescribed in section 2.5.4.

There's no prescription for rejection in 2.5.4.  

I think this gets into too much detail about internals of final delivery to the 
user.  I think it would be sufficient to add a sentence to the second paragraph 
of 9.3.2.  How about:

   SPF fail results can also be used as one input into a larger set of
   evaluations which might, based on the overall evaluation result in
   the email being marked negatively in some way (this might be via
   delivery to a special spam folder, modifying subject lines, or other
   locally determined means).  Developing the details of such an
   approach have to be based on local conditions and requirements.
   Using SPF results in this way does not have the advantages of
   resource conservation and immediate feedback to the sender associated
   with SMTP rejection, but could produce fewer undesirable rejections
   in a well designed system.  Such an approach might result in email that was
   not authorized by the sending ADMD being unknowingly delivered to end
   users.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 22 Aug 2012 10:49:12 -0700

I still think all of this is unnecessary.  The current document
doesn't demand either rejection or marking, and that's the right thing
to do, and in fact reflects the varied current practices.

With respect to the proposal:

>    not authorized by the sending ADMD being unknowingly delivered to end

I guess I hadn't read 9.3.2 in a while.  The first sentence of this
paragraph seems to be mangled.

Apart from that, the added sentence seems fine to me.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 15:36:42 -0400

My engineering assessment:

Either 2.5.4 is very clear and precise with formal protocol design 
behavior for -ALL policy operations, or a new security section as 
proposed is added to highlight the possible repercussions of borrowing 
too much on the new Local Policies highlighting being added to 4408BIS.

Scott, this is the same thing that happen to DKIM with SSP when at the 
last minute with the same concerns, the following informative note 
regarding local policies as added to section 5.3. item 10 to the SSP 
requirements document RFC5016:

    5.3.  Practice and Expectation Requirements

   10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

The same mindset is materializing and in my strong opinion, this late 
minute information note not only begin the demise of POLICY for DKIM, 
it altered and redefined how optimization designs could or would be done.

I see the same thing happening here.  Thats my concern.  So being very 
explicit about both operations (reject and mark) is necessary despite 
the obvious that this is already a local policy mode of operation - 
they can be doing what they want. Some will be slapped for being 
broken, others will not.  So what. that shouldn't change what we want 
in the protocol and if REJECT is one option, what is the other option? 
  Well, its marking - define it and don't leave holes in it.

The question I poise, well the reader of this RFC doc will be able 
pull all everything he/she need to do for implementation some code? 
Maybe, sure, I think so, but we are also very close to understanding 
all this. Can't expect that of the next reader.

Anyway, my answer is your sentence is fine, but I believe the proposed 
10.7 section as it or with a rewritten/revised text (I don't care) is 
needed in the security section to highlight it is indeed a security 
issue relative to both the DOMAIN and the END-USER, and quite frankly, 
a personal opinion, the receiver as well who should care about 
filtering -ALL failures first, ask questions later.

I'm done with expression my part for this.

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

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 22 Aug 2012 13:01:36 -0700

Hello,

I would like to close this thread.  Please do not post any messages 
on it or about Issue #29.  I have already mentioned that I will post 
a message to the mailing list when Issue #29 is open for discussion ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02197.html ).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "John Levine" <[email-masked]>
Date: 22 Aug 2012 20:04:29 -0000

In article <[email-masked]> you write:
>I still think all of this is unnecessary.

Agreed.  SPF does what it does, and we're not going to invent a whole new
framework of what mail systems do with its results.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 22 Aug 2012 18:04:53 -0400

John Levine wrote:
> Murray wrote:

Agreed, but there is no suggestion to do so.

It is prudent that we close all possible loopholes and that is what 
this issue and proposed new section section 10.7 addresses.  No new 
framework, just adding implementator awareness for the responsibility 
to make sure users are not harmed when implementators add code for 
deployments to use SMTP accept/mark modes of operation as opposed to 
SMTP rejection modes of operation for -ALL policy results.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 22 Aug 2012 23:50:50 -0400

On Wednesday, August 22, 2012 10:49:12 AM Murray S. Kucherawy wrote:
> > I think this gets into too much detail about internals of final delivery
> > to the user.  I think it would be sufficient to add a sentence to the
> > second paragraph> 
> > of 9.3.2.  How about:

It seems OK to me.

       SPF fail results can also be used as one input into a larger set of
       evaluations which might, based on the overall evaluation result in the
       email being marked negatively in some way (this might be via delivery
       to a special spam folder, modifying subject lines, or other locally
       determined means).  

What did you have in mind?  Reading it again, I think can also is probably 
better put as can alternately, but I don't think that qualifies as mangled.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Aug 2012 06:46:54 -0700

> better put as can alternately, but I don't think that qualifies as mangled.

The "might" near the front seems to be dangling.  Might what?  Maybe
this is what's meant:

SPF fail results can also be used as one input into a larger set of
evaluations which might, based on the overall evaluation result of the
message, be marked negatively in some way (...).

If so, "might ... being" is the mangling I'm detecting, coupled with
the need for commas.

Also, "the overall evaluation result" might be better expressed as "a
combination of other evaluation techniques".

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:38:07 -0400

On Thursday, August 23, 2012 06:46:54 AM Murray S. Kucherawy wrote:
> >        the

I think adding a comma in the right place was enough.  Please take a look at 
07 when it comes out and let me know if you think it needs more.

> combination of other evaluation techniques".

Did that too.

Scott K