On Feb 15, 2006, at 11:05 AM, Frank Ellermann wrote:
John Levine wrote:
RFC 3833 already has a threat analysis of the DNS. Please,
let's just point to that and be done with it.
+1
It would obscure real issues in threats-01 if all details of doing
interesting things with DNS are analyzed. We can pick
an obvious worst case like "evil name server" as example, say that
DKIM isn't DNSSEC or ICANN or what else, point to some relevant
documents, and then focus on the real DKIM threats:
So far that's apparently replay, and attack from the inside. As
worst case their combination into "chosen message replay".
"Stolen key" and similar oddities are less relevant. Bye
This problem is _not_ related to DNS specific threats. The concern
is limited to whether the 'i=' referenced email-address can be allied
with the signing-domain. A TLD sending email from their domain would
permit a vast number of email-address alliances with their signing-
domain, when in reality, most such alliances would be invalid. The
TLD may have done _nothing_ wrong with respect to any DNS records or
'i=' parameter. If they do not have ultra-secure access to their
outbound email, then a bad-actor could exploit a great number of the
email-address, when the signing-domain is not the basis for trust.
This would be especially true when an assurance is given the
recipient based solely upon the email-address being within the
signing-domain.
If the TLD was the bad actor, then again no DNS records would need to
change for exploits to look extremely convincing.
s=some-key.example d=co.uk i=example.co.uk
When the TLD is a good actor, but their outbound access is not very
secure...
s=some-key d=co.uk
With this signature lacking any optional 'i=' parameter, a vast
number of email-addresses would be assumed allied with this signing-
domain.
Example.co.uk is considered allied. The default for 'i=' is *.co.uk.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html