On Sep 7, 2005, at 12:29 PM, Hallam-Baker, Phillip wrote:
1) The document is useful as a proof of concept even if it is not
necessary to necessarily define a standard for these things.
I was attempting to make the points clear by expressing them "as if"
part of the standard.
2) On per-user certificates I think that the real argument here is
in the context of spam and phishing the aggregate reputation is much
more interesting than the individual. Distinguishing the behavior of
pbaker(_at_)verisign(_dot_)com from *.verisign.com is not very useful where we
talking about the decision to deliver or not.
Absolutely. The domain represents a practical and defensible limit
for accruing reputations. As said in the draft, DKIM must adopt a
defensive strategy. Establishing DoS protections at the HELO is a
means to defend resources and establish name-based accrual of
reputations. This seems to be a practical solution. Successful DKIM
deployment depends upon being able to deal with the current situation
confronting email receivers. The concept of mailbox-domain
authorization is fundamentally flawed. It is asking the receiver to
go well beyond what can be defended by amplifying the impact a
There are cases where this is relevant but I suggest that these are
less common and likely to be a subset in most organizations. For
end user keying might be relevant for professionals at their place of
work, I do not see it as being essential for people with a hotmail
It would seem to make sense to use S/MIME or some type of secure
document rather than burden the basic email system by attempting to
provide user-verification. The opaque-identifier can act as a pseudo-
certificate and permit out-of-band verifications that can strengthen
the association of the opaque-identifier and the user. After all,
any verification method attempted at the MTA is limited by the
account authentication for server access.
I think that it is better to make the case for domain based keys in
their own right, it is a very strong one and does not depend on
attacking end user keys. The best way to deploy end user keys is to
begin with domain keys. That allows a thousand or a million users
added at a time, not one at a time.
My concerns about considering domain-keys being suitable for user-
keys is that DNS and SMTP is likely to suffer a negative impact from
this type of over-reach.
3) On the key lengths I think that 1024 is sufficient for transport
keys, in fact it is arguable that 512 is acceptable since the
time is much much longer than the message validity. On the other hand
the effort required to argue for 512 bits is not worth the performance
The time to crack a 512 bit key is measured in minutes.
Here is the link for the twirl reference:
I would however argue for 2048 bits as a minimum for any new end-user
keying scheme and I would want the ability to handle up to 4096 bits.
From what I have read, it seems that 1024 bit keys should be okay
for the limited duration that keys should be used for email transit.
The use of the expiry feature in DKIM may allow for sloppy practices
in that regard however.
ietf-dkim mailing list