Subject: [ietf-dkim] Reducing threat impact

From: Douglas Otis <[email-masked]>
Date: Tue, 16 May 2006 19:48:00 -0700

The assessments made in the threat review indicate a high impact  
threat affects the entire domain, and a medium impact affects  
specific users, and MTAs.  (A literalistic description of threat is  
"message classification subsequent to verification.")

Avoiding a domain-wide threat appears essential for preventing a high  
impact so...

How does DKIM ensure the scope of a threat is limited to specific users?
------------------------------------------------------------------------

Assuming the message is signed, when is a recipient assured that  
classifications based upon the email-address will provide a practical  
means to curtail abuse?

An assurance might be implied when the i= or g= parameter contain the  
local-part of the email-address.  There are no low impact threats  
without the i= or g= local-part, as there would be few reasons for  
the recipient to limit the scope of their message classifications.   
The number of potential email-addresses is unlimited, and a selective  
recipient will need to expend far greater resources to assess each  
email-address individually, rather than at the signing domain.

When an i= or g= local-part is not used, classifications will likely  
be domain-wide, where all related threats become high impact.  There  
is no means to assure a recipient that classifications based upon the  
signature s= parameter provides a practical means to curtail abuse,  
and thus limit the threat impact.  As such, how can DKIM limit the  
scope of a threat to a specific MTA?  There would need to be some  
means to assure the recipient that the associated s= key selector  
provides a practical means to curtail abuse, rather than the simpler  
method of classifying messages based upon the signing domain.

When a provider does not restrict the use of an email-address, any  
and all threats will therefore affect the signing-domain as a whole,  
and will produce a high impact.  Without recipients individually  
evaluating each email-address within a domain, and consumers of a  
signing domain being restricted to specific email-addresses, all  
classifications will likely be domain-wide and will create a high  
impact when abuses such as message replay occur.  The domain-wide  
impact of this abuse will also affect messages being annotated to  
convey greater trust.

Even a very large domain may not enjoy their normal accommodations  
that overlook a small percentage of abuse, as the signing domain will  
not have the ability to effectively rate limit messages classified by  
a signing domain.  A need to assert that all messages are signed to  
achieve non-repudiation protections creates a quandary.  The only  
solution currently available would be to place messages from less  
vetted sources into different domains.  This would be disruptive and  
confusing for recipients.

One method that can be used to limit the scope of the threat would be  
to employ the r= parameter.  The three categories created by the r=  
parameter require far less resources than assessing each email- 
address separately.  When a small subset of messages convey critical  
information, isolating this information with an r=1 requires less  
effort than restricting all email-addresses.  In addition, message  
annotations would not depend upon the recipient recognizing the email- 
address, which are often unknown email-addresses like do-not- 
replay@.  The r= parameter limits the scope of the threat.  This  
could be valuable when the signing domain is only interested in  
retaining trust for a category of messages, independent of email- 
addresses and any email-address use restrictions.

With the r= approach, the average consumer does not need to hear they  
can no longer use their email-address. With the r= approach, the  
average recipient is safer and better protected.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html