- Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
Practical aspects of administrating this amount of data
via DNS would tend to constrain the number of users such a scheme could
support
Why? What part of the DNS protocol constraints you in any way?
Clearly one must use the right DNS content server for the job - no one
implementation will solve every need.
Possible solutions include having a shim DNS layer that backends to XKMS. Or
how about using one of the DNS servers that use a real database as a backend?
Both examples can trivially support many millions of keys and the content can
be change in real-time without disruption.
Certainly if you want to go down the path of extensive per-user keys, then you
do have a key management issue to resolve. However the protocol used to make
such keys available externally is not really part of the management issue is
it? I don't see how any of HTTP or XKMS or DNS or embedded-within-the-email
affect the backend storage and management of per-user keys directly.
and represents a sizeable growth in the amount of data exchanged.
You've said this a couple of times but it's not as intuitively obvious to me as
it might be to others. Perhaps you could elaborate on this?
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.
This check would be done commensurate with obtaining a public key.
Large sites with potential account problems could flag within their
headers the availability of this feature. A lack or presents of an
account revocation record (A 127.0.0.1) would be much smaller than
offering unique keys per user and should help thwart an obvious spam
technique.
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.
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.
Mark.