Just the last one:
Jim Fenton wrote:
Stephen Farrell wrote:
9. (Part of #2 above really but worth calling out) DKIM creates new
opportunities for service providers (key managers, DNS providers) to
sort-of
revoke a domain's ability to send mail. Those should be discussed so
we can
minimise them to the extent possible.
I'm not sure why this would more of an issue here than revoking a
domain's ability to receive mail by fiddling with their MX records.
Not necessarily more of an issue, but isn't it a bit different
since the DNS provider for the sending domain is now most likely
causing the vulnerability, rather than the DNS provider of the
receiving domain? IMO that's a significant enough difference.
I'm trying to understand why this would be an issue. What would be the
motivation for the DNS provider to do this, especially when a domain can
very easily move to a different provider?
True, but there're two answers here:
a) While I'm doing the vulnerability analysis I don't care about
motivation (which is roughly related to the probability of occurrence),
but I should still recognise the vulnerability. This vulnerability is
I think different to the MX record case where we're messing with the
recpient's DNS data and so ought be recognised.
b) I could bribe someone to make the mail from your domain less
likely to arrive, in which case motivation == € :-)
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org