[ietf-dkim] DKIM Threat Analysis v0.06

[Scott Kitterman]

Arvel Hathcock wrote:
> I suppose bad actors could also be construed as any person or process 
> which introduces unauthorized email message content change.  I for one 
> will have to think on this one before answering.
> 
> Does anyone else have anything to say on this thread?  Please post and 
> help us out.
> 
> -- 
> Arvel
> 
>> Here's what I think.
>>
>>> 1.  Who are the bad actors that DKIM is trying to thwart?  Put another
>>> way, if DKIM is deployed, what bad actors will have to find a different
>>> way to perform their bad acts.

I think this is right on.

>> The bad actors are anyone who would use a domain name in an identity 
>> header of an email message without authorization from the domain 
>> owner. The same will have to discover a new means of doing so.
>>
>>> 2.  Where are these bad actors in the protocol environment?  Where in
>>> the email system do they pop up to perform the acts that DKIM is trying
>>> to prevent.  Again, different bad actors may appear at different places.

This is probably easier to answer in the negative.  Where don't they pop 
up?

A better question to answer might be where in the SMTP architecture can 
they be stopped.  At what points in the architecture is DKIM attempting 
to stop them.  Unauthorized use might in theory be stopped anywhere in 
the MUA-->MSA-->[insert arbitrary number of MTAs here]-->MDA-->MUA chain.

It isn't entirely clear to me exactly where DKIM wants to live in this 
chain.  Is it a tool for the SMTP server to reject messages from SMTP 
clients that are doing something unauthorized?  Is it a tool for 
post-acceptance filtering and routing in the MDA?  Is it a tool meant to 
give MUAs information to display to end users?

Given the transient nature of information in DNS, I think that any 
technology that relies on DNS needs to be primarily a tool for the MTA 
with the potential for secondary use at the MDA level if the latencies 
are low enough.  For MUAs, results need to be captured by the MTA/MDA 
for display by upgraded MUAs.

I would answer this that these bad actors can pop up nearly anywhere in 
the SMTP environment and so DKIM does not presume to try and figure out 
the source of bad actors, just to detect and stop them as close to the 
edge of the receiver's network as possible.  I believe that the design 
goal should be to enable DKIM rejection after DATA, but before 
acceptance of a message from an SMTP client.  This might also be a 
useful MSA check.

>>> 3.  What are the bad acts that DKIM is trying to thwart?  The first two
>>> questions are really background for this question.
>>
>>
>> These are so related it's hard for me to separate.  Unauthorized 
>> domain use is a means to several ends.  The 'end' will determine 
>> where, in the email delivery chain, the bad actor "pops up".  When the 
>> goal is to trash the reputation of a domain owner in the eyes of an 
>> email user or ply some scam part of which requires the unauthorized 
>> use of a domain to lend it credibility, the "pop up" is the MUA of an 
>> email user and the effect takes place in the mind of that user.  When 
>> the goal is to thwart filtering agents or attempt to manipulate a 
>> receiving domain's incoming email policy in some way the "pop up" is 
>> at the point wherein those processes are invoked and the effect is in 
>> reducing or rendering useless the effectiveness of those processes.
>>
>> -- 

The bad act that DKIM is, I think, trying to prevent is unauthorized use 
of 2822 mail identities.  If that's so, some link to the policy 
established by the 2822 mail identity domain owner would seem to be 
essential.

I'm curious what those of you who have been arguing against inclusion of 
SSP in the working group effort would define as the bad act that DKIM 
will prevent in the absence of a sender policy of some kind.

Scott Kitterman