[ietf-dkim] DNS delegation takes care of the authorization

On Jan 29, 2008, at 12:02 PM, Dave Crocker wrote:
> Jeff Macdonald wrote:
> > > > Is that agent authorized to work "on behalf of" the author?
> > > Seems so:
> > >
> > >  <http://www.bartleby.com/64/C003/0169.html>
> > I guess I wasn't clear. A Bad Actor can decide to be an agent to  
> > work "on behalf" any other. It doesn't mean he was authorized to do  
> > so.
> And being authorized doesn't make them a Good Actor...
Agreed.

> Further, DNS delegation takes care of the authorization question,  
> since it subsumes the actor explicitly and directly under the name  
> (and reputation) of the delegator.  No additional (sub-)mechanism is  
> needed in another specification to accomplish this. The DNS-based  
> approach is therefore simpler and well-established.
> Whatever the claims about DNS administrative effort, they cannot be  
> better for a new mechanism that has no history and requires the same  
> level of maintenance.
Strongly disagree.

Key exchanges might be a method to delegate DKIM signing to third- 
parties.  Unless an ad-hoc private key exchange is employed,  
redirection or delegation will not provide a means to restrict the  
scope of a DKIM key.  However, ad-hoc private key exchange is neither  
safe, simple, or well-established.
Private key exchanges or public key redirection obfuscates who handled  
the message.  DKIM servers contain private keys that, if exposed,  
might compromise thousands of other domains when DKIM keys are used as  
a method for delegating message handling to third-parties.  If such an  
exposure were to occur, who actually handled the message becomes  
critical.  However, private key exchanges or public key redirection  
necessitates a number of forensic details be reported before others  
will be able to assess who handled the message.  The potential scope  
of these details may also make reporting these security breaches  
impractical.
With many methods where DKIM key delegation might be achieved, and the  
number of DKIM specific key details involved, DKIM public key  
redirection should not be described as either simple or well- 
established.  Attempting to redirect public keys using DNS requires  
two or more administrative entities to routinely co-ordinate the  
details they publish.  Details that coincide with specific real-time  
DKIM message handling across multiple administrative domains.  Such a  
complex system can not be described as simple.  With respect to DKIM,  
public key redirection as a third-party message handling delegation  
method on a large scale is not well-established either.  If adopted as  
a solution by large providers, public key redirection also creates  
significant security issues.
On the other hand, TPA-SSP provides a method where third-party  
delegation is handled autonomously and without any exchange of keys.   
Although TPA-SSP makes use of DNS, each administrative entity is able  
to publish information without co-ordination with specific real-time  
message handling within different administrative domains.  In  
addition, the TPA-SSP third-party authorization does not require  
periodic modification, as will DKIM key publications.  There is little  
to suggest that DKIM public key redirection or ad-hoc DKIM key  
exchange is not a disaster in the waiting.  In addition, other  
applications beyond email may attempt to utilize these keys for other  
purposes.
The motivation behind DKIM was to establish a responsible domain to  
enable correction of various types of abuse.  Has this goal changed?   
Anything that obfuscates who the responsible domain introducing the  
message is diminishes that effort.  IMHO, SSP should standardize a way  
to signal a domain's use of the TBD TPA-SSP.  Other than that, SSP can  
remain unchanged.  However, third-party delegation by way of key  
redirection or exchanges should be strongly discouraged.
-Doug

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