On May 25, 2006, at 10:23 PM, John Levine wrote:
The arguments against parent signatures seem to me to boil down to
two: parents may be untrustworthy, and foolish people can do
foolish things.
I concur with Jim's rebuttal to the first. The DNS works on the
basis of delegation from the top down, subdomains are 100% at the
mercy of their parent domains whether you like it or not, and it's
25 years too late to change it. Sorry.
Any weakness or exploit related to selections of algorithms or keys
within the DNS hierarchy related to DKIM parent signing precludes an
effective response at affected levels. If a TLD used DKIM with 768
bit keys for example, that might be adequate when this domain's
messages are seldom targeted. On the other hand, <big-
financial>.<tld> may need to react to a highly targeted attack
employing greater resources, perhaps necessitating 1024 bit keys or
greater.
Critical and targeted domains will be in an awkward position
insisting unusual (movie plot) exploits are something that all their
TLDs must defend against. When allowing parent signing, <big-
financial>.<tld> will be unable to directly respond to all threats
affecting them. By allowing parent signing, messages for <big-
financial>.<tld> might be validated by a compromised key at <tld>.
Perhaps <tld> retains keys for too long, or uses a key too small to
resist the level of attack amassed against <big-financial>.<tld>. Of
course, the greater number of messages compromised by a single key,
the greater the threat.
This concern is not directly related to how DNS works, but rather
what message email-addresses are considered confirmed by a
signature. There is a significant reduction in security in this
regard when parent signing is permitted. When disallowing parent
signing as directly validating some sub-domain email-address, the
parent domain can still sign these messages, but would be properly
considered a third-party signing-domain. For most messages, this
should not cause any problem.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html