Cullen Jennings writes:
in section 9.1.1 an attack is considered where all the email addresses are
spoofed and sent to many locations to cause an DOS attack on the key server.
I have been thinking about this a bit, and given the magnification of
mailing lists, it seems this might be a practical attack.
Say there were a bunch of list servers that did not check signatures. The
attacker sends a message that is spoofed from flufffy(_at_)cisco(_dot_)com
to say a
10^3 lists that magnifies it to say 10^6 messages which all result in a hit
to the cisco.com KRS.
I believe that we have some real-life experience with this
given the existence of RBL's which act essentially like a
KRS using IP identities for a huge number of domains, though
the comparison is not exact. AFAIK, they manage to do their
job even when there's an attack against a given domain. So
looking at the average DNS cache size for the domain's
normal email needs may give a clue as to how large the scale
we're talking about actually is. Note: web caches can also
probably play a similar part of the overall solution as DNS
caches.
I'm not sure if this is a problem or not, perhaps they will skew enough to
smooth out over a reasonable time. Perhaps the keys users on the lists will
correlate enough that caching ends up significantly reducing the hits to the
KRS.
As far as I can tell, it does manage to significantly reduce
traffic, especially between sites that exchange lots of
email. The thing that I'm not as sure about is negative
caching for unsigned message policy checks; it is not entirely
clear whether that's a good or bad thing to me, though for
the most part that ends up being an artifact of DNS caching
rather than KRS caching since non-participating domains
almost never get past the DNS lookup stage.
In summary, I think that the issue deserves thought, but it
deserves thought *regardless* of where the authorization
data interface actually resides.
Mike