You still have to get the information INTO the database in a secure fashion.
Once you start to try to write a registration protocol you are into a lot of
work and a lot of complexity. If you have not got a registration protocol
you have a half-a-loaf solution.
The problem of code complexity is not half as much of a barrier to
deployment as the complexity that comes from having an incomplete solution.
The perfect is the enemy of the good but the incomplete is the enemy of the
customer.
If your proposal for per user keys does not have a registration story then
there is no story at all.
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
Sent: Wednesday, January 12, 2005 7:19 PM
To: ietf-mailsig(_at_)imc(_dot_)org
Subject: Re: Good as the enemy of OK
- 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.