Subject: Re: [spfbis] Authentication-Result (Issue 10?)

From: Arthur Thisell <[email-masked]>
Date: Thu, 30 Aug 2012 07:59:07 -0700 (PDT)

> Received fields are not explicitly carrying security information,
> merely trace data, so RFC5322 didn't need to point this out in
> Security Considerations.

Uh, yes they did.  Forging Received fields is a very common practice by spammers to mislead people (and poorly written anti-spam programs) into thinking that the email ok.   Forged Received fields, and depending on the order of those fields, is almost exactly like Received-SPF fields.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 12:22:56 -0700

> Uh, yes they did.  Forging Received fields is a very common practice by spammers to mislead people (and poorly written anti-spam programs) into thinking that the email ok.   Forged Received fields,…

Uh, no they didn't.  Which part of Section 5 of RFC5322 talks about
Received field ordering?

Section 3.6 even warns about this:

   It is important to note that the header fields are not guaranteed to
   be in a particular order.  They may appear in any order, and they
   have been known to be reordered occasionally when transported over
   the Internet.  However, for the purposes of this specification,
   header fields SHOULD NOT be reordered when a message is transported
   or transformed.  More importantly, the trace header fields and resent
   header fields MUST NOT be reordered, and SHOULD be kept in blocks
   prepended to the message.  See sections 3.6.6 and 3.6.7 for more
   information.

That text seems to make reliance on header field ordering or
positioning unreliable at best.  DomainKeys also tried this and it was
not something that was carried forward into DKIM.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 30 Aug 2012 14:42:41 -0700

>Uh, no they didn't.  Which part of Section 5 of RFC5322 talks about

As I may have misunderstood the comment from Arthur Thisell, I won't 
comment about that.

>not something that was carried forward into DKIM.

My understanding is that there is some (unrelated) discussion of the 
Received: header field in RFC 5321.  Murray Kucherawy covered most of 
the issues in the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02475.html 
The working group might end up having to reference DKIM if it decides 
to tackle header protection.  I mentioned "leeway" as it is easier 
for me to get a view of what the WG wants and suggest a path from there.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Aug 2012 20:48:40 -0400

S Moonesamy wrote:

> The
> working group might end up having to reference DKIM if it decides to 
> tackle header protection.  

What you (speaking in general) are saying is that a RECEIVER will now 
have to sign local incoming mail. Then you need a SIGNER POLICY that says:

       This mail is expected to be signed by the receiver to protect
       ACCEPT+MARK deployments.

Please don't.  While I appreciate a new focus and emphasis in BIS to 
support accept+mark with a deemphasis in SMTP level 55x permanent 
responses mode of operations, I don't think its necessary to revamp 
the protocol for this accept+mark operation.

Thank you for your WG consideration.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 20:29:56 -0700

On Thu, Aug 30, 2012 at 2:42 PM, S Moonesamy <[email-masked]> wrote:
> The
> working group might end up having to reference DKIM if it decides to tackle
> header protection.

I don't think that's necessary.  RFC5451 already talks about all of
that.  DKIM is one of several possible solutions for ADMDs where
internal forgery is a concern.

We don't need to copy all of that, just make informative references to
the relevant bits.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Thu, 30 Aug 2012 22:57:27 -0700

Hi Hector,
At 17:48 30-08-2012, Hector Santos wrote:
>What you (speaking in general) are saying is that a RECEIVER will 
>now have to sign local incoming mail. Then you need a SIGNER POLICY that says:
>

No, it's not about setting requirements.  It is up to the author 
(well, the WG) of the specification to analyze the threats and 
provide guidance about how to mitigate those threats.  This is not 
about signer policy.  It is about security.

>the protocol for this accept+mark operation.

It is not about accept+mark.  Even if I do a SMTP reject there would 
still be an issue as I will be adding a header field in other cases.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 30 Aug 2012 23:27:44 -0700

Hi Murray,
>internal forgery is a concern.

Yes.

>We don't need to copy all of that, just make informative references to

There are different ways to tackle this.  You don't have to provide 
an elaborate explanation if you provide the necessary warnings and 
ways to mitigate the threats.  Let's me know whether I should 
elaborate on this.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 Aug 2012 04:12:01 -0400

>> internal forgery is a concern.

No.  Please don't advocate this.

> There are different ways to tackle this.  You don't have to provide an 
> elaborate explanation if you provide the necessary warnings and ways to 
> mitigate the threats.  Let's me know whether I should elaborate on this.

You are missing the point.  If the system is already compromized 
internally, then the system is already hosed.  Nothing can't protect 
it, Not even DKIM and in fact, all other security warnings are out the 
door. If the internal system has to begin adding DKIM or any other 
error correction/checking, CRC or otherwise to protect Receiver-SPF, 
then why not for Received, From, Return-Path and all other headers? 
It isn't about protecting Receiver-SPF but developing a new local 
system protocol to protect the entire message from local system itself.

-- 
HLS

---

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

Yes, it is about security which is what SPF is by definition from the 
perspective of ALL parties; email domains, her senders and her 
receivers.  Its all the above (or below) when we begin to advocate 
protecting headers that the SMTP is adding especially those 
recommended, suggested or even mandated the the protocol such as 
RFC5322, RFC5321, RFC4408.

This is way out of scope and new level of protocol talk.

S Moonesamy wrote:
> No, it's not about setting requirements.  It is up to the author (well, 
> the WG) of the specification to analyze the threats and provide guidance 
> about how to mitigate those threats.  This is not about signer policy.  
> It is about security.
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 07:16:50 -0700

On Fri, Aug 31, 2012 at 1:12 AM, Hector Santos <[email-masked]> wrote:
> You are missing the point.  If the system is already compromized internally,
> then the system is already hosed.  Nothing can't protect it, Not even DKIM
> and in fact, all other security warnings are out the door. If the internal
> system has to begin adding DKIM or any other error correction/checking, CRC
> or otherwise to protect Receiver-SPF, then why not for Received, From,
> Return-Path and all other headers? It isn't about protecting Receiver-SPF
> but developing a new local system protocol to protect the entire message
> from local system itself.

That's all true, but that's not the point being made here.
Received-SPF appears to claim safety behind the notion that it will
never be reordered, while RFC5322 warns that that's not a good idea.
The sponsoring AD, as the author of that RFC, will almost certainly
notice that.  RFC5451 has a way of dealing with that, and we would
therefore only benefit from using it.

-MSK