domainkeys-feedbackbase01(_at_)yahoo(_dot_)com wrote:
Even if your claim is true, it's not clear that the differences, even if
quantifiable, are "sizeable" as you put it. For a start, the key has to be sent
to the recipient in some way. In terms of traffic, whether the key is sent in
the SMTP stream, making it bigger or sent in the DNS response, making it bigger
seems to be a very marginal difference in the scheme of things.
One could even argue that on average, embedding the key in the email will often
increase the total number of packets involved by one since the SMTP stream may
increase across a packetsize boundary whereas a DNS response never does.
Having said all that, I don't think the traffic difference arguments are of
particular relevance in either case. There are many other cost factors above
and beyond the raw bits exchanged between routers.
You basically need to get the key there one way or the other, and if the
transmission cost wasn't incredibly cheap, we wouldn't have a spam
problem (instead, one would pay to send messages). It's just a tradeoff
between using DNS and the message itself to convey the key. Putting the
key in the message lightens the load on DNS (some), and I have been
concerned about the impact on DNS caches (impacting hitrate and
performance, beyond the email application itself). But perhaps that can
just be solved with more memory.
It may also be desirable to decouple the retrieval of they key from
determining its authorization, particularly if one wants to use the
public key that has been obtained elsewhere, such as in an X.509
certificate.
In a world where a fleet of zombies can send a million mails in a matter of
minutes (nay seconds), the only reliable revocation system is one which is
directly queried for every inbound email thus obviating all possible caching
benefits.
If you want to go down the "cannot cache anything path" then you don't need
digital signatures at all! You can achieve verification with a simple existence
query of the message hash.
This requires that the sending domain maintain a lot of state
information (the hashes for all of the messages sent by the domain).
Even if you don't cache the public key (or more precisely, the
authorization associated with the key), you don't need to maintain that
kind of state.
In many senses, PK signature verification is, in effect, nothing more than a
cachable database existence test. Eliminate the caching and you eliminate most
of the need for PK as well.
-Jim