4 ms·
TLDR taken from one of those slides: > Query privacy: Queries do not reveal domain name > Record confidentiality: Values in DHT are signed and encrypted by zo
by southerntofu 5y ago
TLDR taken from one of those slides:
> Query privacy: Queries do not reveal domain name
> Record confidentiality: Values in DHT are signed and encrypted by zone owner.
> Zone privacy: Zones cannot be enumerated
> Censorship and DDoS resistance
That's the key security properties compared to DNS.
- a-dub 5y agowent back and watched the video. actually only 20m and totally worth it. i'm left with a few big questions: 1) how can you have query privacy and zone privacy in the same system? seems like query privacy would open the system up to dictionary attacks at least; with a possibility that depending on how the dht is implemented, perhaps even high performance locally distributed dictionary attacks could be executed? 2) the issues of economics and property rights (as well as invested parties in the economy of name sales and registration) seem like they could collide with the technical goals with something like this gaining traction, has there been any thought given as how these political/economic concerns could be addressed?
- schanzen 5y agoTo 1) Yes, IF you know the zone key (which is a public key). You can perform a dictionary attack for common label values. This is discussed in the security considerations To 2) This is a governance issue. Theoretically, you could deploy GNS with an ICANN root zone. BUT, the system is designed to give users the freedom to override defaults if necessary (see the root zone section in the draft). GNS clients will likely ship with a default zone configuration. If you operate a zone and are a considered trustworthy third party, nobody can prevent you from taking coin for adding delegations to your zone or offering a platform on which you can trade the labels.