[ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

[Scott Kitterman]

Douglas Otis wrote:
> 
> 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.

What is the standardized process by which a receiver can determine if a 
sign using S/MIME?  As a positive assertion S/MIME can be useful.  I use 
it when I think it appropriate.  If there were some kind of a mechanism, 
let's just call it perhaps a sender signing policy for the moment, that 
would let me express a signing policy to mail receivers then I think 
would bother to sign all my mail.
> 
> 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?
> 
Tomorrow would be fine with me.  Waiting for the world to upgrade to 
new, unwritten versions of MUAs to see benifit is not.

What you are asking is what won't SSP accomplish.  It's difficult to 
answer those questions before the design work is done.  So lets quick 
arguing about if it should be done.  Get it done and see what it buys us.
> 
>> 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.
> 
Pretty well making my point about complexity for me.

I'm not going to point by point go through that as there isn't anything 
in your message you haven't said before.

I want SMTP time rejection of unauthorized messages.  More/better 
filtering is of little interest.  The last thing I want is to require 
end users to evaluate message authorization.

Oh, it turns out that if you want a DK aware MUA, you can already have it:

https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&category=Message%20Reading&numpg=10&id=345

Scott Kitterman