[ietf-dkim] DNS delegation takes care of the authorization
dotis at mail-abuse.org
Tue Jan 29 14:29:33 PST 2008
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:
>> 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
> And being authorized doesn't make them a Good Actor...
> 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.
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
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
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.
More information about the ietf-dkim