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

["Murray S. Kucherawy" <[e-mail]>]

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

> On Wed, Sep 11, 2013 at 9:43 AM, Murray S. Kucherawy <[e-mail]>wrote:
>
>> On Wed, Sep 11, 2013 at 6:22 AM, S Moonesamy <[e-mail]>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 [e-mail] doesn't cover it? I
> thought that was the point.
>

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


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

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.


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

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