[ietf-dkim] user-based keys / another protocol

[Douglas Otis]

On Aug 3, 2007, at 3:17 PM, Florian Sager wrote:

> In June 2006 Eric Allman wrote:
>
>> From eric+dkim at sendmail.org Thu Jun 1 07:36:07 2006
>> Date: Thu Jun 1 07:36:57 2006
>> Subject: [ietf-dkim] base-03: Key lookup parameters
>>
>> The point of passing i= is to allow extension in the future to  
>> possible per-user keying. You wouldn't do this in DNS, but another  
>> protocol should be able to handle it easily.
>> eric
>
> In the last days I was thinking about an easy way to deploy  
> multiple selectors/public keys (e.g. for per-user keying) to  
> different DNS servers in an environment of a mailserver with  
> multiple virtual mail domains: a typical webhosting scenario with  
> DNS-zones at different providers.
>
> At the point of view of an administrator it seems to be best that  
> public keys have to be provided directly by the authorities signing  
> outgoing mail (reason: cost efficiency).
> I outlined s.th. at http://dkim-connector.agitos.de/trac/wiki/ 
> DeploymentVersionTwo to support this idea. I'm sure this kind of  
> deployment was already considered earlier - is there any  
> information available about that?

Per user keys would be a bad idea.

Consider how TPA-SSP can replace key distribution:

http://www1.tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt

Rather than distributing keys, the mail-server is authorized in a  
simple and scalable fashion instead.  This better protects DKIM from  
a calamity when a private key becomes compromised at a highly shared  
MTA.  Using TPA-SSP, the resulting security warning would be limited  
to a single domain.

When distributing keys are employed, a single compromised server  
might then impact thousands of domains.  A compromised server is not  
that uncommon.  Reporting thousands of domains have been compromised  
when a single server has been compromised key will result in a much  
greater loss of confidence.  Of course, distributing keys imposes  
greater administrative costs as well.

-Doug