Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does no

On Aug 24, 2005, at 7:00 AM, Scott Kitterman wrote:

> It seems to me that your proposed approach is anything but simple.  It
> would appear to me that you want to trade the direct, obvious, near- 
> term
> benifits of a defined deterministic Sender Signing Policy (I'm not  
> saying
> the current draft is perfect) for an uncertain, undesigned, and
> undocumented automated abuse reporting infrastructure.

A desire for "near term" email address protection is provided by S/ 
MIME now.
By "near term" I assume you have some time frame in mind.  What would  
that time frame be?  What benefit, or limits to these benefits would  
there be?  What exceptions will be needed?  What exploits remain  
possible?  What is required to administer this new mode?  What email  
use behavior changes will be required?

> You get to call this 'simple' from a DKIM perspective only by  
> declaring all
> this complexity external to DKIM.

Mappings of authorizations between various mailbox-domains and  
signing-domains will be expensive from an administrative and likely  
from a DNS standpoint.  DKIM can become embroiled in debates about  
whether the From header is sacrosanct.  The mailing list used to  
debate that topic would seem to mock such a view.
Rather than depending upon administrators to tell their customers  
what they can no longer do (a bad idea), or receiving calls asking  
why email no longer works (another bad idea), there is another  
approach that does not run into these issues and yet provides  
_better_ protections.  Because this approach involves less  
administrative overhead and imposes fewer restrictions, it should  
also be less expensive.  I see expense as a significant impediment  
for deployment.  This deployment would be over many years where  
expenses matter more than "near term" hype.
Rather than creating a labyrinth of conditions each message must  
navigate, the signing domain may add an opaque-identifier to the  
message that relates internally to some static element (such as  
account).  When there are no internal elements that can be used, this  
opaque-identifier could simply be sequential.  This is done with an  
expectation that DKIM aware MUAs will be able to opportunistically  
bind the mailbox-address (both the routing and the pretty name), with  
the signing-domain, and this opaque-identifier.  Binding approvals  
assume the recipient has reason to trust the message, and has been  
shown the elements being bound.
The signing domain could suggest what level of binding is needed to  
protect the identity of the "author(s)".  A large institution that  
restricts mailbox-address use for their domain, may indicate that  
only the mailbox-domain and signing domain needs to be captured  
within an MUA binding.  Such a broad binding would encompass  
subsequent messages from that domain.  When this assertion is seen by  
the MUA, and the mailbox-domain and the signing-domain match, then it  
should be safe for the MUA to automatically establish this binding.   
That leaves those attempting to spoof messages, where there has been  
prior correspondence, immediately identified as suspicious.
When a key has been delegated, there should be a flag that indicates  
a lower level of trust, where the opaque-identifier should be derived  
by the key-selector and a binding exception made.  Binding exceptions  
could be due to an innocent change that causes an alert of a  
suspicious message, where the user could be prompted with the binding  
details and asked whether to accept, merge, replace, ignore, or  
refuse.  There would be no need to call the email provider to repair  
some relationship in DNS.  Opportunistic identification can detect  
most cross-domain forgery, even when no restrictions are placed upon  
the mailbox-address use.
Just by signing the message, the protective information can be  
transferred directly without expecting the use of any domain-wide  
assertions.  The other use for an opaque-identifier (not related to  
any mailbox-address) would be to provide a means to deal with message  
replay abuse.  This opaque-identifier also significantly aids  
correlation of abuse from a large domain.  Zombies are a major issue,  
where those running zombies would be extremely adept at hiding within  
an authorization maze published within DNS.  With an opaque- 
identifier, zombies will be readily apparent.
-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org