[SPEC] Domain name specification

[gsan]

d/mydomain/whatyouwant would be used as mysubdomain2.mydomain.bit and used as a part of mysubdomain3.mydomain.bit

That was my idea at first as well and I don't have anything solid to object to about it, other than the extra need for a specification about the domain name entry. Since both solutions are the same in effect, I think "s/" namespace solution is simpler. It's logically separate, easier to parse, etc.

We currently know that everything starting with a "d" is a domain. Also, there is no mechanism to prevent other people from registering "d/yourname/theirname" and although this is not a problem, it reduces the actual usefulness of the spec. We'd be better off reserving the name spec for other purposes, such as alternative TLDs. (I got the "s/" idea from vinced, maybe he has a more authoritative opinion about this issue, since I'm almost impartial.)

Do we really need both sub + merge ? Only merge wouldn't be sufficient ?

You can't create hierarchies with "merge". It is there only to extend storage space. I put it there, but I still don't like it.

EDIT: After re-reading your post, looks to me like we can use "merge" to do more than just increase storage.

Creating domain names like "d/mydomain2/blabla" is a waste of a domain. Instead, the "merge":"d/mydomain2/blabla" could simply look at "d/mydomain2" and take that config of the subdomain "blabla". But, in that case, blabla.mydomain2.bit would exists too and we may not want that.

The reason we have this proposal is to allow delegation of sub-domains to different people, like DNS, so the waste of domain is actually the purpose. How big a concern is this?

Plus, what you say should be possible with "translate" and "alias" directives, no?

The second choice will create a problem with sub-sub domains because it could be interpreted as merged.whatyouwant.mydomain2.bit. This last sentence lead me the a question : the spec is not designed for sub-sub domains ?

It's exactly designed for that.

EDIT: Here is something idiotic that you can do with "sub", which could serve as an explanation about how sub-sub-domains could work:

s/sillysub:

Code: Select all

{ "map": { ""   : "10.0.0.2", "y": { "sub": "d/sillydom" } } }

d/sillydom:

Code: Select all

{ "map": { ""   : "10.0.0.1", "x": { "sub": "s/sillysub" } } }

In the above example, sillydom.bit resolves to "10.0.0.1" and "x.sillydom.bit" to "10.0.0.2". In return, "y.x.sillydom.bit" resolves to "10.0.0.1" and "x.y.x.sillydom.bit" to "10.0.0.2" and so on ad infinitum.

Hmm, this also raises questions about implementation difficulties of course. (Recursion would need to be done on the fly.)

[vinced]

Personally I don't think that it's a good idea to store that much information in the block chain. In fact, I think that no record except a NS record and possibly a DHT record (see below) should be stored in the chain.

NS delegation is already there. I'm not sure that a DHT really reduces storage requirements significantly. A 4096 bit RSA key is 500 bytes. Do we really expect the blockchain average zone size to be longer than 1K? If not, then we are only saving a factor of 2.

I'm not oppposed to this, and in fact it is out of our control what goes in the blockchain. An experiment or a proposal showing that you can do more with a DHT would be needed to convince people to adopt an additional system.

[gst]

NS delegation is already there. I'm not sure that a DHT really reduces storage requirements significantly. A 4096 bit RSA key is 500 bytes. Do we really expect the blockchain average zone size to be longer than 1K? If not, then we are only saving a factor of 2.

RSA key sizes are rather large. If you use ECC instead (http://en.wikipedia.org/wiki/Elliptic_c ... yptography) you can get the same security with a key size between 256 and 384 bit (ECC with 256 bit is roughly equivalent to RSA with 3072 bit, and ECC with 384 bit is equivalent to RSA with 7680 bit).

I'm not oppposed to this, and in fact it is out of our control what goes in the blockchain. An experiment or a proposal showing that you can do more with a DHT would be needed to convince people to adopt an additional system.

Actually I've planned to write something similar to .bit (see http://news.ycombinator.com/item?id=1955498) before I stumbled upon .bit, so if I find some time I'll try to write a simple prototype extension for the DHT code. If such a DHT prooves to be useful I think that this could also be integrated concurrently with other mechanisms (first introducing a new record type for the DHT, and then possibly deprecating other record types at some later point in time).

[gsan]

There is one more issue I'd like to discuss about the current proposal.

It currently doesn't talk about sub-sub domains, but these cases got more attention while we were pondering about domain hierarchies on IRC. There is the option to adopt the "subsub.sub" scheme from DNS. However, I was hoping to change the structure to make the hierarchical aspect more sound and take advantage of JSON encoding, but it will not be compatible with the current one and make it slightly harder to write by hand.

So instead of this:

Code: Select all

{
  "map":
  {
    "": {
      "email": "hostmaster@example.bit",
      "ip": "192.168.10.10"
    },
    "www.alice": { "ip": "192.168.10.11" },
    "ftp.alice": { "alias": "www.alice" }
  }
}

I propose this:

Code: Select all

{
  "email": "hostmaster@example.bit",
  "ip": "192.168.10.10",
  "map": {
    "alice": {
      "map": {
        "www": { "ip": "192.168.10.11" },
        "ftp": { "alias": "www" }
      }
    }
  }
}

This renders the hierarchies clearer (e.g. cutting/moving/copying/importing/exporting) but there are also some drawbacks. So what do you think?

[itsnotlupus]

There's not a lot of activity in this thread, but I don't see a newer one to discuss the new namecoin value spec, so here goes my little laundry list of suggestions for the specification:

Cryptocurrency addresses

For example, bitcoin and namecoin addresses. Unseemly, impossible to memorize, and unavoidable if you wish to make a transaction. This is not entirely unlike having to type (or more likely, paste) an IPv6 address in your browser when you want to see a site.

So, in the same spirit as the current proposal mapping Tor and I2P sites, we need a way to map namecoin names to bitcoin and namecoin addresses. Top level field keys like "btc" and "nmc" would be both short enough and descriptive enough.

Note that it doesn't help in situations where a merchant needs to hand out a different address for each customer to pay them. It does however help greatly in situations where knowing the origin of a transaction isn't necessary (tip jars, as well as almost every signature on this forum and bitcoin's.)

SSL certificate verification

Another aspect is support for SSL-enabled sites. There isn't much chance that the SSL root certificate issuers are going to be willing to hand out valid certificates for the *.bit TLD. Yet without SSL, your data is not just trivial to sniff, but also to modify in transit. That's not okay.

It doesn't seem desirable to define our own root authority somewhere and have it sign certificates for namecoin users, as that introduces a centralized component. Instead, we should define a field in the spec to hold a self-signed certificate's fingerprint. (Credit for this idea goes to someone in IRC smarter than me, possibly doublec.)

That would require browsers to be tweaked to use a different certificate validation path for SSL-enabled .bit sites, but the underlying mechanism is sound: Only the owner of the .bit domain can put a valid certificate fingerprint in the domain's value, hence users can trust that a .bit site presenting an SSL certificate matching that fingerprint is in fact controlled by the current owner, and not the subject of an MITM attack.

DNS information leaks

Finally, one aspect I find compelling about the namecoin DB is that, as long as a domain doesn't require external queries to resolve to something useful, there is not DNS traffic leak allowing an external observer to figure out what you're doing.

Unfortunately, that stops being true if a namecoin value uses the "ns" or "dns" keys, as well as for some uses of the "alias" and "translate" keys, and probably other keys.

It may not always be feasible to keep namecoin values entirely self-contained, apparently primarily due to size constraints, but it's worth trying. The "import" mechanism seems like a good step in that direction. Additionally, we should make it easy to tell if a namecoin value is liable to leak information to the internet upon resolution. At the simplest level, we should document explicitly which keys are guaranteed to be safe, and which could leak.

[vinced]

@itsnotlupus - these are all good applications. I think SSL/SSH key storage and crypto addressing will help initial adoption of namecoin if implemented, because they don't require mass adoption to be useful.

@gsan, @khal - I think the domain name specification is in good shape for now. It can be improved over time as needed.

!v

[itsnotlupus]

I've updated the Domain_names wiki page a bit to incorporate the concept of SSL certificate verification.

See the "TLS Support" section, and the new "fingerprints" type.

[sugarpuff]

SSL certificate verification

Another aspect is support for SSL-enabled sites. There isn't much chance that the SSL root certificate issuers are going to be willing to hand out valid certificates for the *.bit TLD. Yet without SSL, your data is not just trivial to sniff, but also to modify in transit. That's not okay.

It doesn't seem desirable to define our own root authority somewhere and have it sign certificates for namecoin users, as that introduces a centralized component. Instead, we should define a field in the spec to hold a self-signed certificate's fingerprint. (Credit for this idea goes to someone in IRC smarter than me, possibly doublec.)

That would require browsers to be tweaked to use a different certificate validation path for SSL-enabled .bit sites, but the underlying mechanism is sound: Only the owner of the .bit domain can put a valid certificate fingerprint in the domain's value, hence users can trust that a .bit site presenting an SSL certificate matching that fingerprint is in fact controlled by the current owner, and not the subject of an MITM attack.

I think supporting the traditional PKI/Certificate Authority system is a terrible idea. The idea of root certificates and all that is outdated, especially in the face of Namecoin.

If we're going to supersede DNS, we need to offer many significant advantages over the traditional system. There is no reason whatsoever for us to bring Namecoin down to the level of today's broken DNS/PKI system. It is a great opportunity to throw all of that where it belongs: in the trash.

Today, every internet-savvy government on earth can, and does MITM any website simply through the use of a compromised CA. This happens all the time:

https://www.eff.org/deeplinks/2011/10/h ... ttps-today

People die because of this.

Web browsers trust over 600 CA's. Governments can hack the weakest link, or more simply, demand the private key, thereby giving themselves unfettered access to all encrypted SSL/TLS traffic.

Worse, SSL does not support perfect forward secrecy (PFS), which is essential for any website that claims it's offering users a secure connection. We now know that the NSA and other spy agencies are storing all SSL traffic. Once they obtain the key to that traffic, all of it becomes unencrypted, making the encryption effectively worthless.

PFS prevents this from happening, and should be mandatory in all future communication protocols.

Namecoin provides a unique, first-time-ever opportunity to make truly secure communication on the internet possible.

Namecoin completely eliminates any need for any type of "Certificate Authority".

It would be a major tragedy if Namecoin intentionally handicapped itself to the point of providing the same level of security that DNS and x509 provide.

[sugarpuff]

FYI, a system using Namecoin that eliminates x509 Certificate Authorities is coming.

[biolizard89]

FYI, a system using Namecoin that eliminates x509 Certificate Authorities is coming.

Are you aware of Convergence for Namecoin? It implements the .bit TLS specification and doesn't use CA's.