ietf-dkim
[Top] [All Lists]

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

2007-08-03 16:31:23

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


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

<Prev in Thread] Current Thread [Next in Thread>