Stephen Farrell wrote:
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.
Fair enough. Since this threat is not discussed in DKIM -base I have
added an additional subsection under "Attacks on Message Signing"
describing this. But the threat goes in both directions: the attacker
that can influence DNS could add records as well as interfere with the
domain's ability to send mail, and I have noted that.
b) I could bribe someone to make the mail from your domain less
likely to arrive, in which case motivation == € :-)
I agree that's a motivation (and that motivation or the lack thereof
shouldn't be a factor in what we document). But hopefully the bribery
part is out of scope, otherwise we will have a _very_ long list of threats.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org