.bit Spec & NMControl: remove external NS lookups

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

.bit Spec & NMControl: remove external NS lookups

Post by phelix »

In the specification for .bit and also in the implementation in NMControl (though currently disabled by default) there are functions that can need/cause lookups to external nameservers. These are "alias", "translate", "ns", "ds".

External lookups are a risk for privacy and security. The implementation of external lookups is complex whereas the benefits of external lookups are small.

I don't see a good reason to cling to this legacy stuff and consequently suggest to remove any lookups outside the blockchain from both specification and implementation.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

domob
Posts: 1129
Joined: Mon Jun 24, 2013 11:27 am
Contact:

Re: .bit Spec & NMControl: remove external NS lookups

Post by domob »

Sounds good to me.
BTC: 1domobKsPZ5cWk2kXssD8p8ES1qffGUCm | NMC: NCdomobcmcmVdxC5yxMitojQ4tvAtv99pY
BM-GtQnWM3vcdorfqpKXsmfHQ4rVYPG5pKS
Use your Namecoin identity as OpenID: https://nameid.org/

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit Spec & NMControl: remove external NS lookups

Post by biolizard89 »

So, this is a little bit complicated.

Some benefits of using ns+ds compared to the blockchain:
  • No need to pay a transaction fee to update a name.
  • No need to pay for an extra name if you want to go over 520 bytes.
  • As a result of the above, the blockchain, UTXO set, and UNO set are smaller.
  • The DNS configuration of the domain is somewhat more private, because running a dictionary/bruteforce attack against the nameserver is needed if the attacker wants to enumerate the subdomains, while with the blockchain it's all public. Note that this advantage is security by obscurity and shouldn't be used for anything where security actually matters. Note that this could partially be fixed in the blockchain by using hashed names and subdomains rather than plaintext (this has been a suggested GSoC project, and Ryan and I have posted some suggestions on how this could work).
  • The nameserver can give you a different answer depending on your IP address, which makes geobalancing easier. Note that it is possible to implement this with the blockchain too, there's just no spec for it (I think making such a spec is on Ryan's to-do list).
  • Somewhat better interoperability if your server host maintains their own nameserver but doesn't want to maintain a blockchain entry. This can be mitigated by running DyName, which will automatically update the name when the value needs to change, but this requires that a machine that has Internet access run DyName constantly (doesn't have to be the same server that the name points to). If the machine running DyName is compromised, then whatever parts of your name configuration that DyName has access to, are also compromised.
Drawbacks of using ns+ds compared to the blockchain:
  • Name lookups are slower because you need a round trip to the nameserver. This metric mattered a lot to the Google DNS guy I talked to a couple years ago.
  • Name lookups are less private because the nameserver and everyone else on the network path will see your request.
  • Implementation of ns+ds lookups over Tor is nontrivial, though maybe possible if the nameserver supports DNS over TCP (which not all do).
  • Replay attacks are easier, because DNSSEC signatures last circa a month (I think), while a blockchain DMMS is considered outdated if it's 2 hours old. This means that if someone compromises your TLS key, they can MITM your web server until the DNSSEC key expires (by MITMing your nameserver too), even if you fix the TLSA record on your nameserver. I am not sure whether DNSCurve or DNSCrypt makes this problem less of an issue; note that DNSCurve/DNSCrypt keys are not in the d/ spec at the moment.
Drawbacks of using alias/translate:
  • All drawbacks of ns+ds, except Tor support (which is pretty easy to do, I think).
  • The ICANN DNSSEC key is trusted, as is the DNSSEC key of whatever TLD the alias/translate points to. This can be mitigated by instructing the resolver to not trust such domains, by clearing the AD bit in all such DNS responses (this is a little bit tricky, but not super hard). Using such a mitigation will make TLS errors show up for all .bit domains that use it.
Drawbacks of using ns without ds, or alias/translate with target domains that don't have DNSSEC:
  • All drawbacks of ns+ds and alias/translate respectively.
  • Authenticity of responses is impossible to verify at all since the responses will not be signed. By default, Unbound will clear the AD bit in all such cases; this will make TLS errors show up for all .bit domains that use it.
I disagree with Phelix on the complexity of implementing external lookups. With Unbound/madns (which is what NMControl will presumably use going forward), it is no harder than implementing IP lookups.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: .bit Spec & NMControl: remove external NS lookups

Post by phelix »

biolizard89 wrote:So, this is a little bit complicated.
[...complicated details...]
Your answer seems to support my suggestion :D
I disagree with Phelix on the complexity of implementing external lookups. With Unbound/madns (which is what NMControl will presumably use going forward), it is no harder than implementing IP lookups.
Note that it will require calling an external software (written in a different language in the case of madns).
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit Spec & NMControl: remove external NS lookups

Post by biolizard89 »

phelix wrote:
biolizard89 wrote:So, this is a little bit complicated.
[...complicated details...]
Your answer seems to support my suggestion :D
I wouldn't say it's quite that simple. If the only considerations are lookup integrity, lookup speed, and lookup privacy, then I think requiring the blockchain to be used is a logical conclusion. But I'm not certain that those are the predominant considerations. For example, has anyone actually done any empirical analysis on how large the blockchain would end up being if we remove external lookups? Analysis of that would be very useful for figuring out whether your suggestion is a good idea. I'm not saying I disagree with your suggestion; I'd just like more information on how this will affect users.
phelix wrote:
I disagree with Phelix on the complexity of implementing external lookups. With Unbound/madns (which is what NMControl will presumably use going forward), it is no harder than implementing IP lookups.
Note that it will require calling an external software (written in a different language in the case of madns).
Well, we need Unbound and madns anyway since we need interoperability with client software that supports DNSSEC, and there aren't any native Python libraries that support DNSSEC.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit Spec & NMControl: remove external NS lookups

Post by biolizard89 »

I just ran some numbers, hopefully I didn't make math errors:

Assumptions:

There are 300 million unsquatted domain names.
Each domain name has 2 subdomains: an alias of main domain and a second different domain.
Each subdomain has IPv4, IPv6, Tor, I2P, and TLSA.
IP addresses are stored in a dd/ name, separate from the crypto keys in a d/ name.
All IP addresses for a given 2nd-level domain are dynamic and change every 24 hours.
All crypto keys for a given 2nd-level domain are assumed compromised and replaced every 60 days.
A name_update transaction is approximately 418 bytes, plus the length of its name and value.
All domains, subdomains, and import names are 20-character DNS labels (assuming no
IDN's).

Format of crypto keys name:

Code: Select all

{"import":"dd/12345678901234567890","tor":"duskgytldkxiuqc6.onion","i2p":"vsd2vtgtuua2vwqsal2mpmxm2b2cpn3qzmqjoeumrrw2p4aot7uq.b32.i2p","map":{"_tcp":{"map":{"_443":{"tls":[[0,0,1,"0qveJA180+5rSyjFTfA0uXmDodFuikEORWHLEGYY6XE="]]}}},"12345678901234567890":{"translate":"@"},"01234567890123456789":{"tor":"duskgytldkxiuqc6.onion","i2p":"vsd2vtgtuua2vwqsal2mpmxm2b2cpn3qzmqjoeumrrw2p4aot7uq.b32.i2p","map":{"_tcp":{"map":{"_443":{"tls":[[0,0,1,"0qveJA180+5rSyjFTfA0uXmDodFuikEORWHLEGYY6XE="]]}}}}}}}
The above is 496 bytes.

Format of IP addresses name:

Code: Select all

{"ip":["100.100.100.100"],"ip6":["2001:0db8:85a3:0000:0000:8a2e:0370:7334"],"map":{"01234567890123456789":{"ip":["100.100.100.100"],"ip6":["2001:0db8:85a3:0000:0000:8a2e:0370:7334"]}}}
The above is 184 bytes.

So, we have:

300,000,000 transactions of 418+22+496 bytes every 60*24*6 blocks = 32,500,000 bytes per block for keys
300,000,000 transactions of 418+23+184 bytes every 24*6 blocks ~= 1,302,000,000 bytes per block for IP's

For reference, this comes out to several orders of magnitude more than Bitcoin's block size limit.

Obviously, these numbers are designed to be near worst case. But it appears that blockchain storage adds up quickly.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: .bit Spec & NMControl: remove external NS lookups

Post by phelix »

biolizard89 wrote: Well, we need Unbound and madns anyway since we need interoperability with client software that supports DNSSEC, and there aren't any native Python libraries that support DNSSEC.
Could you elaborate on your plans with DNSSEC?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit Spec & NMControl: remove external NS lookups

Post by biolizard89 »

phelix wrote:
biolizard89 wrote: Well, we need Unbound and madns anyway since we need interoperability with client software that supports DNSSEC, and there aren't any native Python libraries that support DNSSEC.
Could you elaborate on your plans with DNSSEC?
Client software that supports TLS fingerprints specified by DNS, only accepts them if they're secured by DNSSEC (AD=1). It's pretty easy to do this for Namecoin, by generating a user-specific DNSSEC key, signing all .bit records with it, and adding that key to the Unbound trust store. Python doesn't have any library for this.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1634
Joined: Thu Aug 18, 2011 6:59 am

Re: .bit Spec & NMControl: remove external NS lookups

Post by phelix »

biolizard89 wrote:
phelix wrote:
biolizard89 wrote: Well, we need Unbound and madns anyway since we need interoperability with client software that supports DNSSEC, and there aren't any native Python libraries that support DNSSEC.
Could you elaborate on your plans with DNSSEC?
Client software that supports TLS fingerprints specified by DNS, only accepts them if they're secured by DNSSEC (AD=1). It's pretty easy to do this for Namecoin, by generating a user-specific DNSSEC key, signing all .bit records with it, and adding that key to the Unbound trust store. Python doesn't have any library for this.
If I understand correctly this is your plan for TLS support. Does it work with popular browser out of the box?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 2001
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: .bit Spec & NMControl: remove external NS lookups

Post by biolizard89 »

phelix wrote:
biolizard89 wrote:
phelix wrote:
biolizard89 wrote: Well, we need Unbound and madns anyway since we need interoperability with client software that supports DNSSEC, and there aren't any native Python libraries that support DNSSEC.
Could you elaborate on your plans with DNSSEC?
Client software that supports TLS fingerprints specified by DNS, only accepts them if they're secured by DNSSEC (AD=1). It's pretty easy to do this for Namecoin, by generating a user-specific DNSSEC key, signing all .bit records with it, and adding that key to the Unbound trust store. Python doesn't have any library for this.
If I understand correctly this is your plan for TLS support. Does it work with popular browser out of the box?
It will, once browsers support the TLSA DNS record. So far no major browsers support it (Chromium used to support it, but then removed support for reasons that I think are faulty). At the moment I'm using a Mozilla API that gives us what we need, but it requires installing a browser extension. I'm pretty sure it will work with any Mozilla-based software, including Firefox/Thunderbird/Seamonkey/TorBrowser, but I've only tested in Firefox.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

Post Reply