Subject: Re: [spfbis] SECDIR Review of draft-ietf-spfbis-4408bis-19

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 06:22:32 -0700

Hi Phillip,

I am responding to the comment about DKIM only and wait for the 
SPFBIS WG to address the other issues.

At 05:07 11-09-2013, Phillip Hallam-Baker wrote:
>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  Document editors and WG chairs should treat these comments just
>like any other last call comments.
>
>The document has been produced as part of a proposal to upgrade SPF 
>to standards track recognizing the state of deployment experience.
>
>Minor issues.
>
>1.1.3.  MAIL FROM Definition
>
>I found this section completely opaque and very confusing. It should 
>not be necessary to hunt through other specs to find a definition. 
>Particularly since the referenced specs do not give an explicit 
>definition for the term as used and the references point to the 
>whole spec rather than a particular section.

I am commenting on the following paragraph only:

>The Security Considerations section is adequate for the purpose 
>except that no mention is made anywhere in the specification about 
>DKIM and how a mail receiver should interpret presence of DKIM and 
>SPF policy at the same time. This is a legitimate concern since DKIM 
>is already a standards track proposal and SPF is only now being 
>promoted to Standards Track. Thus the SPF document should address 
>the question of dual use.

There was a BoF at the last IETF meeting to discuss proposals about 
how to interpret the presence of DKIM and/or SPF policy at the same 
time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc 
).  The dual use can be addressed as part of the DMARC effort.

>8.7.  Permerror
>
>"
>
>This signals an error condition that
>
>    definitely requires operator intervention to be resolved."
>
>I cannot imagine a circumstance which definitely requires a human to 
>be involved in mail delivery.
>
>
>11.2.  SPF-Authorized Email May Contain Other False Identities
>
>    Do not construe the "MAIL FROM" and "HELO" identity authorizations to
>    provide more assurance than they do.
>
>Document has quasi normative language that should be worded as 
>statements of fact rather than as direction.
>
>--
>Website: http://hallambaker.com/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 06:43:54 -0700

On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <[email-masked]> wrote:

> I am responding to the comment about DKIM only and wait for the SPFBIS WG
> to address the other issues.
>

Was the SecDir review for this draft posted to the spfbis list?  I haven't
seen it.

>
>  The Security Considerations section is adequate for the purpose except
>> that no mention is made anywhere in the specification about DKIM and how a
>> mail receiver should interpret presence of DKIM and SPF policy at the same
>> time. This is a legitimate concern since DKIM is already a standards track
>> proposal and SPF is only now being promoted to Standards Track. Thus the
>> SPF document should address the question of dual use.
>>
>
> There was a BoF at the last IETF meeting to discuss proposals about how to
> interpret the presence of DKIM and/or SPF policy at the same time (
> http://www.ietf.org/**proceedings/87/minutes/**minutes-87-dmarc<http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc>).  The dual use can be addressed as part of the DMARC effort.
>

DKIM has no intrinsic policy component.   Are we actually talking about
ADSP here?

Assuming we are, I think the best we could do is to note that it's possible
for ADSP and SPF to yield conflicting policy results; one could be a "pass"
while the other could be a "fail", meaning the receiving MTA now has one
"reject" instruction and one "accept" instruction.  The receiving ADMD will
have to make a decision about which one ought to get precedence.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 06:52:26 -0700

Hi Murray,
At 06:43 11-09-2013, Murray S. Kucherawy wrote:
>Was the SecDir review for this draft posted to the spfbis list?  I 
>haven't seen it.

The entire SecDir review is in the reply I posted a few minutes ago 
(SECDIR in the subject line).

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 07:08:28 -0700

Ah, sorry.  My MUA cut it off and wasn't caffeinated enough to notice.

---

From: Dotzero <[email-masked]>
Date: Wed, 11 Sep 2013 10:43:31 -0400

On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy
<[email-masked]> wrote:
>>> proposal and SPF is only now being promoted to Standards Track. Thus the SPF
>>> document should address the question of dual use.
>>
>>
>> http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ).  The dual use
>> can be addressed as part of the DMARC effort.
>
>
> DKIM has no intrinsic policy component.   Are we actually talking about ADSP
> here?
>

ADSP should be relegated to historical. Very little implementation on
the publishing side and even less validation on the receiving side. We
(all of the usual suspects in this space) made compromises to get it
out the door and we collectively got it wrong.

Having said that, I could live with some kind of note in the SPFbis
doc along the lines of what Murray suggests.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Sep 2013 07:50:58 -0700

On 9/11/2013 6:22 AM, S Moonesamy wrote:
>> that no mention is made anywhere in the specification about DKIM and
>> how a mail receiver should interpret presence of DKIM and SPF policy
>> at the same time. This is a legitimate concern since DKIM is already a
>> standards track proposal and SPF is only now being promoted to
>> Standards Track. Thus the SPF document should address the question of
>> dual use.
>
> There was a BoF at the last IETF meeting to discuss proposals about how
> to interpret the presence of DKIM and/or SPF policy at the same time (
> http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ).  The dual
> use can be addressed as part of the DMARC effort.

At the level of a fully-integrated email anti-abuse system, concern 
about possible SPF and DKIM presence and interaction effects is, of 
course, essential.

However SPF is only a component technology.  It's specification is not 
the place for discussing higher-level interaction effects.

By way of example, imagine the specification for an automobile tire 
being expected to talk about design and operations issues when the tire 
is linked to 3 siblings and a suspension system, and a motor and... 
That's an important topic, but the tire spec is wrong venue.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 10:33:45 -0400

> Was the SecDir review for this draft posted to the spfbis list?  I haven't

The [email-masked] doesn't cover it? I
thought that was the point.

> DKIM has no intrinsic policy component.   Are we actually talking about

If a message has a DKIM signature and it is valid for the sending domain
then that is strong evidence that the owner of the domain intended to send
it. Hence DKIM Signature overlaps with SPF policy.

Regardless RFC 5617 is standards track and it is a part of DKIM and the SPF
document should probably mention it as well.

> Assuming we are, I think the best we could do is to note that it's
> possible for ADSP and SPF to yield conflicting policy results; one could be
> a "pass" while the other could be a "fail", meaning the receiving MTA now
> has one "reject" instruction and one "accept" instruction.  The receiving
> ADMD will have to make a decision about which one ought to get precedence.
>

I suspect that the answer is that SPF will take precedence simply because
the MailFROM will be received and acted upon before the MTA has enough
information to act on DKIM information. An MTA that decides email is spam
on the basis of SPF is likely to drop the connection or tar pit it. I doubt
it is going to bother to check a DKIM signature.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 11 Sep 2013 09:35:09 -0700

On Wed, Sep 11, 2013 at 7:33 AM, Phillip Hallam-Baker <[email-masked]>wrote:

>> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <[email-masked]>wrote:
>>
>>> I am responding to the comment about DKIM only and wait for the SPFBIS
>>> WG to address the other issues.
>>>
>>

I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole
WG.

> it. Hence DKIM Signature overlaps with SPF policy.

Ah, I see where you're going now.

>
> Regardless RFC 5617 is standards track and it is a part of DKIM and the
> SPF document should probably mention it as well.
>

ADSP has seen so little adoption that I think it would actually be a
mistake to pay it any homage here.  I think your point above about DKIM
proper is the more interesting one.

> it is going to bother to check a DKIM signature.

Right, I had forgotten about this as well.  I shouldn't reply to SecDir
without being appropriately caffeinated.

It's not necessarily the case that an SPF failure will be acted upon before
DKIM even gets evaluated.  Though that is clearly for many installations
the optimal use because you don't have to deal with the body, any MTA that
wants to give DKIM due consideration as well will have to store the SPF
result and then decide on it later.  And there are sites that do prefer it
that way, not the least of which is the entire DMARC community.

This draft is already worded such that one can merely observe the SPF
result and record it rather than enacting it as soon as possible, possibly
using it as one input to a larger equation.  This use case could bolster
that argument by providing an example, and could even be done without
naming DKIM specifically.  Of course, the downside is that the receiver has
to deal with accepting the body.  As long as the tradeoff is made clear (if
it isn't already), we might consider adding it.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 11 Sep 2013 16:41:29 -0000

>> There was a BoF at the last IETF meeting to discuss proposals about
how to >> interpret the presence of DKIM and/or SPF policy at the same
time ( 
>>><http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc>).  The
>>dual use can be addressed as part of the DMARC effort.

>DKIM has no intrinsic policy component.   Are we actually talking about

Looks like DMARC to me.  I don't see any reason to mention in in 4408bis.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Wed, 11 Sep 2013 13:15:15 -0400

I had an issue with SPFBIS limiting discussion with integrated 
technology that is 100% related and exist in the market place. 
Protocols SenderID and Submitter SMTP extension which can alter the 
way an SPF compliant package will work.

Related, I had an issue with the limited modeling of check_host() 
function I/O which WOULD NOT fit the reality of an integrated system 
with SUBMITTER support with extended input parameters:

     spf_result = check_host(ehlo, mailfrom [,submitter])

I didn't see why this was not important other than to believe that 
SenderID/Submitter doesn't not exist.

DKIM is not RELATED to SPF.  To talk about unrelated DKIM required to 
talk about a very related item such as SenderID, SUBMITTER.

In this vain, until the IETF can say something about a SPF-related 
technology in SenderID and especially SMTP level SUBMITTER protocol 
which will require to be fitted with a Check_Host() function, the 
"Experiment" was not really completely concluded.

Keep in mind that SPF is a SMTP level technology (doesn't require the 
payload). DKIM requires the payload to be transferred and this 
diminished the optimization of an SPF method.  For DKIM, like ADSP, 
DMARC also now depended on that Author Domain anchor (the single 
binding requirement for DKIM).  SPF or the SenderID Submitter protocol 
do not depend on receiving the payload in other to function.

A DKIM discussion will require how SMTP transaction is done with SPF 
receivers, that is mainly to always receive the payload.

On 9/11/2013 9:22 AM, S Moonesamy wrote:
> time ( http://www.ietf.org/proceedings/87/minutes/minutes-87-dmarc ).
> The dual use can be addressed as part of the DMARC effort.
>
>> 8.7.  Permerror
>>
>> "
>>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 11 Sep 2013 13:53:28 -0700

Hi Scott,

I am copying the parts of the SECDIR review to which there hasn't 
been any response:

Issue 2:

>8.7.  Permerror
>
>"This signals an error condition that definitely requires operator 
>intervention to be resolved."
>

>statements of fact rather than as direction.

Could you please comment about the three issues?

Thanks,
S. Moonesamy (as document shepherd)

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 17:53:30 -0400

> >whole spec rather than a particular section.

It's a challenge, but I think it's better than inventing a new definition for 
SPF that may be different.  Would someone be willing to dive into the relevant 
RFCs and see if they can make a recommendation about how better to reference 
this?

> >be involved in mail delivery.

These are permanent DNS errors or SPF record errors.  For example, if an SPF 
record requires too many DNS lookups, someone has to change the record to make 
the error go away.

The definitely was intended to distinguish from cases such as a DNS SERVFAIL 
that may or may not be permanent, but are temperrors in SPF.  In the case of 
ambiguity about if an error is temporary or permanent, it's treated in the 
design as assumed to be temporary.

If this is confusing, someone please suggest an alternative.

> >statements of fact rather than as direction.

How about:

   The "MAIL FROM" and "HELO" identity authorizations do not provide assurance
   about the authorization/authenticity of other identities used in the
   message.

> Could you please comment about the three issues?

See above.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 11 Sep 2013 17:59:15 -0400

Submitter is unrelated to SPF and it would be wrong to treat anything related 
to submitter as an "spf_result".  If you disagree, please point to me to the 
reference in RFC 4408 or documents referenced by RFC 4408 where submitter is 
described.

Scott K

On Wednesday, September 11, 2013 13:15:15 Hector Santos wrote:
> >>    Do not construe the "MAIL FROM" and "HELO" identity
> >> 
> >> authorizations to
> >>

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 12 Sep 2013 10:23:03 +0200

Hi, Scott,

> RFCs and see if they can make a recommendation about how better to reference

To avoid confusion it's better not to mention a whole list of possible 
names/aliases in this Definition paragraph.

May I suggest the following text:

    This document is concerned with the identity of the sender of a
    mail message, as referred to in [RFC5321]:

        "The transaction starts with a MAIL command that gives the
        sender identification."

.  Since there are many other names for this identity, it is
    important to choose a name that is:

    1. commonly used
    2. well defined

    As such, throughout this document the term "MAIL FROM" will be used,
    which is defined as the RFC5321.MailFrom identity described in 
[RFC5598].

--

/rolf

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 14 Sep 2013 01:05:54 -0400

> I'm pretty sure it's authors, shepherds, and co-chairs only, not the whole

It also includes the sponsoring AD.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Sep 2013 13:20:53 -0700

Hi Rolf,
At 01:23 12-09-2013, Rolf E. Sonneveld wrote:
>To avoid confusion it's better not to mention a whole list of 
>possible names/aliases in this Definition paragraph.
>

Thanks for suggesting text.  I'll comment below.

>    which is defined as the RFC5321.MailFrom identity described in [RFC5598].

The issue raised in the SecDir review [1] is "the referenced specs do 
not give an explicit definition for the term as used and the 
references point to the whole spec rather than a particular 
section".  The suggested text (see above) does not address that in my 
opinion.  The question being asked is what is the definition for 
"MAIL FROM".  The first sentence in your comment explains what can 
cause confusion.

Regards,

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg04110.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sun, 15 Sep 2013 00:04:41 +0200

Hi, SM,

On 09/14/2013 10:20 PM, S Moonesamy wrote:
> references point to the whole spec rather than a particular section".  
> The suggested text (see above) does not address that in my opinion.  
> The question being asked is what is the definition for "MAIL FROM".  
> The first sentence in your comment explains what can cause confusion.

I intentionally did not refer to a specific paragraph within the 
referenced specs, as new versions of those referenced specs might 
invalidate the references in this spfbis document. Granted, chances that 
RFC5321 and/or RFC5598 will become obsoleted by newer versions are 
small, so here's an attempt to address part of the raised issue:

    This document is concerned with the identity of the sender of a
    mail message, as referred to in par. 3.3 of [RFC5321]:

    1. commonly used
    2. well defined

    As such, throughout this document the term "MAIL FROM" will be used,
    which is defined as the RFC5321.MailFrom identity, described in par. 
4.1.4 of [RFC5598].

I'm not sure I agree with the SecDir review re. "the referenced specs do 
not give an explicit definition for the term as used [...]', as RFC5598 
par. 4.1.4 describes the RFC5321.MailFrom identity quite well:

    RFC5321  <http://tools.ietf.org/html/rfc5321>.MailFrom:  Set by - Originator

       This field is an end-to-end string that specifies an email address
       for receiving return control information, such as returned
       messages. [...]

Regards,
/rolf

---

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Sep 2013 23:21:35 -0700

Hi Rolf,
At 15:04 14-09-2013, Rolf E. Sonneveld wrote:
>invalidate the references in this spfbis document. Granted, chances 
>that RFC5321 and/or RFC5598 will become obsoleted by newer versions 
>are small, so here's an attempt to address part of the raised issue:

Ok.

>    which is defined as the RFC5321.MailFrom identity, described in 
> par. 4.1.4 of [RFC5598].
>
>I'm not sure I agree with the SecDir review re. "the referenced 
>specs do not give an explicit definition for the term as used 
>[...]', as RFC5598 par. 4.1.4 describes the RFC5321.MailFrom 
>identity quite well:
>
>
>    RFC5321.MailFrom:  Set by - Originator
>

I'll adapt your proposed text as follows:

    This document uses "MAIL FROM" to refer to RFC5321.MailFrom (reverse-path).
    The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598 as an end-to-end
    string that specifies an email address for receiving return control
    information, such as returned messages.

I inserted the word "reverse-path" because of Section 2.4.

If you are okay with the above I'll use it to respond to the SecDir review.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 17 Sep 2013 01:19:44 -0700

Hi Phillip,
>whole spec rather than a particular section.

The text below is to address the comment about Section 1.1.3 (credits 
to Rolf E. Sonneveld):

>the question of dual use.

I commented about the above in my previous reply.

>be involved in mail delivery.

These are permanent DNS errors or SPF record errors.  For example, if 
an SPF record requires too many DNS lookups, someone has to change 
the record to make the error go away.

The definitely was intended to distinguish from cases such as a DNS 
SERVFAIL that may or may not be permanent, but are temperrors in 
SPF.  In the case of ambiguity about if an error is temporary or 
permanent, it's treated in the design as assumed to be temporary.

>statements of fact rather than as direction.

The following change is proposed is response to the above:

Regards,

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Sep 2013 23:47:43 -0400

On Thursday, September 12, 2013 10:23:03 Rolf E. Sonneveld wrote:
> > It's a challenge, but I think it's better than inventing a new definition
> > for SPF that may be different.  Would someone be willing to dive into the
> > relevant RFCs and see if they can make a recommendation about how better
> > to reference this?
> 

Thanks.  After much delay, I've added this to my local copy.  Diff from the 
last changeset I posted attached.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Sep 2013 23:58:53 -0400

On Saturday, September 14, 2013 23:21:35 S Moonesamy wrote:
>     This document uses "MAIL FROM" to refer to RFC5321.MailFrom
> (reverse-path). The RFC5321.MailFrom is defined in Section 4.4 of RFC 5598
> as an end-to-end string that specifies an email address for receiving
> return control information, such as returned messages.
> 

I added reverse-path to what I just published on 1.1.3.  I'm not going to 
publish another diff just for that.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 26 Sep 2013 00:02:43 -0400

> return control information, such as returned messages.

Incorporated as already mentioned.

> I commented about the above in my previous reply.

I don't think there's anything that's actionable within the charter on this.

> permanent, it's treated in the design as assumed to be temporary.

I'm not making any changes for this.

>     The "MAIL FROM" and "HELO" identity authorizations do not provide
> assurance about the authorization/authenticity of other identities used in
> the message.

Incorporated locally.

Scott K