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

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 08:07:27 -0400

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 <http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-19#section-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.

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.

8.7 <http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-19#section-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 <http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-19#section-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: 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:
>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
>
>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
>
>Document has quasi normative language that should be worded as 
>statements of fact rather than as direction.
>
>--

---

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
> 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: 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.

>> 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 (

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.
>>>
>>
>> Was the SecDir review for this draft posted to the spfbis list?  I
>> haven't seen it.
>>
>

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: 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.
>
> 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: 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: 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):

    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.

>the question of dual use.

I commented about the above in my previous reply.

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

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:

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

Regards,
S. Moonesamy (as document shepherd)