From: Tony Finch
Sent: Thursday, May 20, 2004 5:30 AM
On Wed, 19 May 2004, Seth Goodman wrote:
First, is it feasible to create multiple private keys that can be
validated by the same public key with reasonably strong security?
I believe not.
If so, would it be possible when decrypting a signature to tell which
private key it was signed with? The motivation for this would be to
gain the ability to do per-user validation without having to publish a
separate public key for every user. Publishing per-user public keys
would certainly give a domain that capability, but it means publishing a
list of valid local addresses. That is something most businesses would
not be happy with.
You can solve the problem by using the SPF macro scheme to state where to
look up public keys in a per-user fashion, or this information could be
implicit in the address signature format. In either case you can avoid
publishing the list of users as a whole by disallowing zone transfers from
your nameservers.
That's what I was looking for: I was unaware that there was a DNS mechanism
to prevent the transfer of the entire set of domain records. The local user
address list stored in the DNS would still be subject to dictionary attack,
but could not be downloaded by a simple query, correct?
MTA's often have heuristics to detect and stop, or at least slow down,
dictionary attacks. Is there anything analogous for DNS today? Is the
possibility of dictionary attack on a nameserver a significant impediment to
a domain publishing per-user validation information in the DNS?
Sorry if these questions are naive, but I know much less about DNS than I
would like. The motive for all this is to consider an SES variation that
can do per-user validation and doesn't rely on CBV's. I'm not entirely sold
on the economics of this, but it's worth exploring.
For the combination SPF+SES system that we've discussed on the list so far,
the first hop would be validated by SPF and subsequent hops would require a
CBV. Each recipient in the message path would therefore do either zero or
one CBV per incoming message. The CBV requires some network bandwidth from
the recipient but not much CPU. The original sender would have to respond
to (N-1) CBV's, where N = number of message hops. Depending on the flavor
of SES they implemented, each CBV would require some network bandwidth plus
CPU to calculate the HMAC (if the signatures are not cached). This
appropriately puts higher average overhead on the sender, both for network
bandwidth and CPU.
If the validation were to take place by retrieving a DNS record, this
changes a bit. Each hop will generate DNS queries to the domain nameserver.
This is lightweight for both sender and recipient, though the sender's
nameserver will receive at least N queries per outgoing message, where N =
number of hops. The recipient, on the other hand, will have to expend a
significant amount of CPU to verify the asymmetric crypto signature. The
sender does have to similarly expend significant CPU to create the
asymmetric crypto signature. The net result is an almost equal load on both
sender and recipient, with a larger load on the sender's nameservers, though
this will be reduced somewhat by local DNS caching. This doesn't put a
significantly larger burden on the sender than the recipient, which is an
important characteristic of any spam-discouraging technology.
How do people feel about this? Is it better to require CBV's, which are not
terribly lightweight but do put more burden on senders than recipients, or
to use DNS with asymmetric crypto, which is lightweight in terms of network
bandwidth but produces a relatively equal load on sender and recipient?
The ultimate solution, proposed by Greg Connor in the "HELO vs. envelope
checks" thread, is to create a nameserver that can validate an SES
signature. This is lightweight in network bandwidth and puts the
computational load back on the sender, where it belongs. I can't address
the difficulty of implementing this, but it would solve the problem in a
fairly optimal manner.
--
Seth Goodman