Phill,
DNS Cache poisoning etc attacks are actually quite hard to do if you
do not know the address of the resolver asking the question.
And this address is protected how? It is easy to discover, commonly
advertised (think ISPs), and at best weak security by obscurity.
If however the attack does turn out to be a problem we fix the
broken-ness of DNS. A flooding attack is easily deleted with a
unique request ID cookie, we do not need to even go as far as
deploying DNSSEC.
The request ID within DNS is 16 bits. If you propose adding such a
larger cookie to both sender and recipient then you have to deploy
that which is again another problem to solve which adds over all
complexity to problem of deploying a fixed to the SMTP protocol.
b) the sender can choose the TTL on his forged DNS response, making it
last for weeks;
Sounds like a pretty recognizable signature.
Incorrect. There will be a wide variety of TTLs used in the field,
they can legitimately change over time; all the attacker has to do is
choose a plausible looking and long TTL.
It is in any case a simple matter to limit the TTL that the cache
recognizes.
Which tends to impacts performance.
On top of that DNSSEC presumes a PKI, which as we've seen over the
last 5 years is a hard thing to deploy in and of itself.
Also untrue.
This is a political debate for another list. Hardly "untrue", at the
very least it's a debatable point, stock prices and recent histories
of PKI bankruptcies could be read to indicate PKI has it's own
technical and economic infrastructure deployment problems.
Anyway my point is more to the overall complexity of a scheme. An
anti-spam scheme that starts with "step 1 deploy global PKI", I think
is undisputably more complex than a system like hashcash which has no
infrastructure requirements.
Adam
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg