Re: Scalability of keys

From: Zenon Panoussis <oracle_at_provocation.net>
Date: Thu, 05 Aug 2010 05:41:53 +0200

Murray S. Kucherawy wrote:

>> BIND works wonderfully with LDAP [...]

> Wow, that got past me. I didn't realize bind had those interfaces.

Then again, there's a downside to everything. Not entirely by coincidence,
but rather by the same impulse that brought me to DKIM, I've been reading
up again on DNSSEC tonight. Now, try to DNSSEC-sign an LDAP-backend zone
and see how many hairs you have left on your head at the end of that
excercise.

Hint: if your girlfriend has a soft spot for shining bald guys, combine
DNSSEC with an LDAP backend and ever-changing DKIM selectors. Even better,
use the same short lifetime policy on DNSSEC keys as on DKIM selectors,
but slightly out of sync with each-other. And for the ultimate sadist
kick, delegate DNSSEC and DKIM on the same zone to different departments.

> The argument against use of DNS, mostly from the DNS operations people,
> from the beginning was twofold: (a) that's not what the DNS is for; and
> (b) it will create undue load on the DNS infrastructure. The first is
> a religious argument, but the second is unknown still as DKIM hasn't got
> as wide a deployment as would be sufficient to gauge its true impact.

Uhm, I'd just put on a smug face and say that, if any of this is a problem,
then DNS is the victim of its own success.

At the end of the line, it's neither the DNS nor the DKIM people who have
to feel the impact of DNS load, but the users. And the users don't care
where the load is; they only care how big it is. For any sizeable ISP (in
the long run, assuming that DKIM provides the long-term benefits that it
has the potential to), it would be a serious gain to save 30 mail servers,
even if that comes at the expense of having to add 3 extra DNS servers.
It's the overall cost that counts, not where the money went.

>> Keys on the web, on the other hand, would first require a DNS query in
>> order to find the webserver to query for the key, and then an HTTP
>> transaction for the key itself.

> In theory, the A or AAAA query for the key server would be cached, and
> since (also in theory) most signed mail comes from a small number of
> common sources (the big ESPs and big senders), the DNS impact would
> ultimately be minimal. And if a domain signs with multiple keys, the
> A or AAAA query is the same for all keys rather than having to query
> and cache a TXT for every selector the receiver sees.

True, but the number of selectors will always be an infinitesimal fraction
of the number of queries. Hence, if we can respond to a million queries
from cache, it makes no difference whatsoever whether we seeded our cache
with just one A query or with three dozen TXT queries.

Besides, caching in general is in itself an argument for DNS and against
HTTP. DNS is cached by general rule and practice, but the times of web
caching are long gone. Which means that DNS queries, no matter if they're
for A or TXT records, will usually only go from the originator to his
nearest DNS server, while HTTP requests will almost invariably travel
around the world every time, until they hit the original key issuer. Even
if the cost of producing a response is equal across methods (from cache
or from origin, by DNS or HTTP), the bandwidth costs of uncached HTTP
will always eclipse those of cached DNS.

Now then, after all this vehement argumentation which makes me appear
as the sworn enemy of anything HTTP that I am not, I can still see some
benefits to an HTTP variant. HTTP keys can and will be mirrored in
trusted webs in a way that DNS keys cannot (for example: if I can't
get your key from you because you're currently being DDoS'ed, I would
still trust a copy of your last known key from spamhaus.org) and such
mirroring and archiving can provide backward checking capabilities that
DNS cannot. But these are extras, so they should be used as such: on
top of DNS, not instead of it.

Z
Received on Thu Aug 05 2010 - 03:42:12 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:48 PST