On Wed, 2005-01-12 at 16:19 -0800,
domainkeys-feedbackbase01(_at_)yahoo(_dot_)com
wrote:
- 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?
DNS can be configured to provide hundreds of mega-bytes of data. : )
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?
I did not say it could not be done. Considering practical aspects, this
larger amount of data (more than currently used for mail) MAY represent
deployment issues and impact the amount of data stored and exchanged
within the DNS infrastructure. Email is a major consumer of this
service. How much more UDP traffic and DNS cache load does it take
before one would describe possible detrimental impacts as not being
practical? As a technical body, this question should be explored. This
does seem to be where there is a departure in design criteria between
the two proposals as well.
I offered a possible means to reduce the size of this data without
resorting to fingerprints to retain a salient feature, being able to
promptly disable an account as a means to squelch a possible stream of
spam. I suspect this will be a useful feature. I did this to ensure I
was not attempting to rule out either approach.
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.
Although the ease and possible need for additional tools to handle the
potential size of these structures represents a component of a practical
consideration, I don't see this issue as that important however.
Software is adaptive. The transport is virtually set in stone.
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?
Depending upon the nature of the traffic, the average mail payload is
4-8 kbytes of data. This is exchanged using TCP which is reasonably
good at avoiding congestion and packet loss. Should there be a need to
both obtain and store a sizeable (compared to the typical DNS record
needed for mail) on a per user rather than a per domain basis, there
will be an increase in DNS traffic. There are two factors affecting
this. One, the size of the record is larger. Two, more records are
needed, as a record is needed per user rather than per domain.
Even if your claim is true, it's not clear that the differences, even if
quantifiable, are "sizeable" as you put it.
Engineers enjoy these questions. It is really just an exercise to
assuage or dispel potential concerns. It is better done now than
regretting having not considered such concerns.
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.
Regarding this issue, there are three things to be considered. One, DNS
traffic is running on UDP. This traffic is rather poor at avoiding
congestion and preventing packet loss. Two, the number of "new" keys
needs to be considered. If done for the domain globally, then the miss
rate for these keys will be much lower than a miss rate when required
for each user. Three, would it be beneficial to further reduce the
exchange within DNS?
A conservative design would use only a key per domain and exchange just
the fingerprint via DNS. There are some hard to quantify trade-offs
that makes this third question difficult to judge. Having the key
within the message allows immediate processing while confirmation via
DNS can proceed in parallel. There will be a small increase in the SMTP
traffic load, (perhaps a few hundred bytes) but there will less UDP
traffic and less DNS cache consumed.
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 packet size boundary whereas a DNS response never does.
But unlike with UDP, there is more immediate feedback on congestion with
SMTP.
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.
It would seem to be worth the effort to estimate these effects at least.
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.
There are two layers of protection needed. One is at the network. The
email signature offers protection for the user. Being able to
selectively squelch spam would seem to be where there is great value
having the signature. This advantage is lost when one can not disable a
flow a spam using the domain's signature within a reasonable period of
time. A week later does not seem to be an effective tool.
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.
Are you now saying a solution is to use a per message record?
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.
This is a per user lookup however. I was not advocating avoidance of
the DNS cache, but rather a consideration of the effects of the two
proposals. By looking at these issues, participants may find these
choices easier.
-Doug