Re: [Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Wed, 28 Aug 2013 10:43:24 -0400 Jerry Leichter leich...@lrw.com wrote: On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com wrote: It's not as if this isn't a design we have that we know works: DNS. Read what I said: There's a *design* that works. I never suggested *using DNS* - either its current physical instantiation, or even necessarily the raw code. In fact, I pointed out some of the very problems you mention. What defines the DNS model - and is in contrast to the DHT model - is: - Two basic classes of participants, those that track potentially large amounts of data and respond to queries and those that simply cache for local use; - Caching of responses for authoritative-holder-limited amounts of time to avoid re-querying; - A hierarchical namespace and a corresponding hierarchy of caches. DNS and DNSSEC as implemented assume a single hierarchy, and they map the hierarchy to authority. These features are undesirable and should be avoided. I'm unsure how to use a DNS-like model when there is no real linkage between hierarchy in the names used and the storage location of particular mappings. In particular, if I have names like f...@example.com, and I want just anyone to be able to enroll at any time without administrator input, and I don't want state authorities to be able to shut down or alter the contents of the system, I don't see how to accomplish all my goals with something DNS-like. That said, if you have a concrete proposal, I would of course find it interesting to hear about. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com wrote: It's not as if this isn't a design we have that we know works: DNS. As I said elsewhere: as a practical matter, almost no one using email is a DNS administrator. This therefore cannot possibly deploy in finite time for the average user. If your mailbox is in a domain name controlled by someone else, you may wait effectively forever for permission. Indeed, DNSSEC itself has waited forever as a result of that. Furthermore, this is unacceptable because the trust model is unacceptable. If you are a user of gmail, for example, it implies that Google is in the trust loop for telling the world security critical information, like, for example, your key. Sovereign threats can order Google to insert different keys at will. As I've said elsewhere: the DNS is a very architecturally tempting idea for all of this. I fully understand why people would want to do it that way. It is not, however, practical if one wants to deploy in months and not decades, and it makes trust entirely hierarchical. Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] Why not the DNS? (was Re: Implementations, attacks on DHTs, Mix Nets?)
On Aug 28, 2013, at 8:34 AM, Perry E. Metzger wrote: On Tue, 27 Aug 2013 23:39:51 -0400 Jerry Leichter leich...@lrw.com wrote: It's not as if this isn't a design we have that we know works: DNS. Read what I said: There's a *design* that works. I never suggested *using DNS* - either its current physical instantiation, or even necessarily the raw code. In fact, I pointed out some of the very problems you mention. What defines the DNS model - and is in contrast to the DHT model - is: - Two basic classes of participants, those that track potentially large amounts of data and respond to queries and those that simply cache for local use; - Caching of responses for authoritative-holder-limited amounts of time to avoid re-querying; - A hierarchical namespace and a corresponding hierarchy of caches. DNS and DNSSEC as implemented assume a single hierarchy, and they map the hierarchy to authority. These features are undesirable and should be avoided. -- Jerry ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
