[ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

[Rolf E. Sonneveld]

On 5/2/11 10:22 PM, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From:ietf-dkim-bounces at mipassoc.org  [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Rolf E. Sonneveld
>> Sent: Monday, May 02, 2011 1:14 PM
>> To:dcrocker at bbiw.net
>> Cc:ietf-dkim at mipassoc.org
>> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"
>>
>>> In other words, DKIM has nothing to do with the rfc5321.From field, and
>>> therefore it is entirely inappropriate -- that is, out of scope -- for the
>>> specification to suggest dealing with it.
>> You mean 5322.From?
> Yes, I think that's what he meant.
>
>> And how should we read par. 3.2.2 of RFC4686 if it is out of scope for
>> DKIM to deal with it?
>>
>>      Bad acts related to email-based fraud often, but not always, involve
>>      the transmission of messages using specific origin addresses of other
>>      entities as part of the fraud scheme.  The use of a specific address
>>      of origin sometimes contributes to the success of the fraud by
>>      helping convince the recipient that the message was actually sent by
>>      the alleged author.
>>
>>      To the extent that the success of the fraud depends on or is enhanced
>>      by the use of a specific origin address, the bad actor may have
>>      significant financial motivation and resources to circumvent any
>>      measures taken to protect specific addresses from unauthorized use.
>>
>>      When signatures are verified by or for the recipient, DKIM _is
>>      effective in defending against the fraudulent use of origin addresses_
>>      on signed messages.
>>
>> Although 5322.From is not mentioned here, how can DKIM provide any level
>> of defense against fraudulent use of origin addresses, if d= is the one
>> and only mandatory output of the verification process?
> Why does the output of DKIM need to include something when the consumer of that output already has that information?

Because a consumer should/must not have to re-do the work of the DKIM 
verifier. Or put it differently: a consumer is just consuming the output 
of the DKIM verification process, it will rely on it (provided there's a 
trust relation between consumer and verifier), and it normally will not 
re-do the work of the DKIM verifier. It has no knowledge of DKIM rules 
(bottom up etc.). Just like a MUA has no information about how two MTA's 
exchange a mail over SMTP.

So for the consumer it is essential to get, in addition to the d= and 
the status, the From address that was used to construct the signature. 
That way the consumer can act upon this triplet of information.

>> Or should we declare this paragraph obsolete?
> It could stand some revision, I suspect.
>
> Nevertheless, the overall threat model doesn't require that DKIM itself, i.e. the protocol being defined, also be the thing that evaluates origin addresses for validity or value.

Agreed.

> It's certainly legitimate to leave that to other modules, just like SMTP isn't required to do any evaluation work of the payload it carries.

Agreed.

> But DKIM is a key component to that overall system.

Because DKIM is a key component to the overall system, it must provide 
reliable information about the origin address to those 'other modules'. 
If DKIM is not designed to provide that, we'll have to declare par. 
3.2.2 of RFC4686 to be 'status: historical'.

Question: does DKIM say anything about the 5322.From header value? If we 
agree with Dave, we'll have to admit that DKIM does not address the 
threat described in par. 3.2.2 of 4686, do you agree?

/rolf