[Proposal] Namecoin/DNSSEC integration

[ryanc]

Hi,

I've discussed this with some people on IRC, and they suggested I post my thoughts here.

I like being able to delegate my .bit domain to traditional DNS servers - this allows a lot of flexibility to change things without spamming the block chain. Sadly, this sacrifices integrity protection.

I think we should add the ability to add hashes of DNSSEC KSKs (key signing keys, which sign zone signing keys, which sign responses) to namecoin domains. DNSSEC handles this with DS records, but those seem to be a little more complicated than they strictly need to be.

DS records contain four fields (see http://www.ietf.org/rfc/rfc3658.txt for details):

* "key tag" - a 16 non-cryptographic hash of the key data
* "algorithm" - the algorithm number in the DNSKEY record
* "hash type" - 1 for sha1 or 2 for sha256
* "hash" - hash(domain | DNSKEY RRDATA)

For simplicity's sake, I'm proposing that we just translate this more-or-less directly into namecoin. I've set up dnssec.bit as an example with the following data:

Code: Select all

{
    "ds": [
        [31381,8,1,"pA1WbHXqk1VlZcdbIwzzXAeceTI="],
        [31381,8,2,"toHBU1NKO9wx0NbcHLtWv9XWYGsSvOOUndexitQ6j8E="]
    ],
    "ns":["prgmr.ryanc.org"]
}

This is translated from my dsset file which contains the following:

Code: Select all

dnssec.bit.             IN DS 31381 8 1 A40D566C75EA93556565C75B230CF35C079C7932
dnssec.bit.             IN DS 31381 8 2 B681C153534A3BDC31D0D6DC1CBB56BFD5D6606B12BCE3949DD7B18A D43A8FC1

I propose we use base64 encoding instead of hex in order to make the representation a bit more compact.

[moa]

Ok, this is novel and a surprising twist.

Using the namecoin blockchain as a decentralised register for the keys that secure DNSSEC.

It has many facets to it, it is collaborative, yet somewhat subversive. We can do what you do only better and things you cannot do but need us for ... I like it, no I think I love it.

[ryanc]

It has many facets to it, it is collaborative, yet somewhat subversive. We can do what you do only better and things you cannot do but need us for ... I like it, no I think I love it.

Could you please elaborate?

In turn, here's a few potential benefits/use cases, given the capability to securely delegate to an off-chain data source:

* You don't need to reveal the existence of all of your hostnames.
* You can use things like Geo DNS to direct people to the closest mirror of a site.
* You can dynamically generate signed responses on-the-fly.
* Things like IP-over-DNS and RBLs become possible to do securely under Namecoin domains.
* Existing DNS management tools can be leveraged.
* Emerging DNS standards such as DANE can be used seamlessly without explicit support in Namecoin.
* No bloating the block chain if you have a large zone or frequently make changes.
* No loss of security that I can think of, and you no longer need to worry about your TLD's DNS servers issuing bogus keys for you.

I'm sure people will come up with other reasons.

[khal]

After discussing the idea a bit on IRC with ryan-c, I think this idea could be easily supported in NamecoinToBind.

People using a local/trusted NamecoinToBind can then be sure to know if domains delegated to NS are compromised or not (by using a dnssec plugin in Firefox for example).
DNSSEC is then improved by namecoin :p

[ryanc]

I've written a patch for NamecoinToBind which seems to be working, will submit a pull request on github soon.

[moa]

It has many facets to it, it is collaborative, yet somewhat subversive. We can do what you do only better and things you cannot do but need us for ... I like it, no I think I love it.

Could you please elaborate?

Don't have to khal has done it for me ...

DNSSEC is then improved by namecoin :p

I would actually go further and say that with your idea and similar extensions of the same general concept "DNSSEC can be fixed by namecoin."

I consider DNSSEC broken on arrival. Decentralising the keys storage/look-up using namecoin goes a long way towards fixing it.

[sugarpuff]

DNSSEC, IMO, is a dead end, and simply a waste of developer's time that could be better spent elsewhere. Problem 1 is its unnecessary complexity, and problem 2 is that there's simply no reason for its existence thanks to Namecoin and projects like DNSNMC.

Fixing DNSSEC with Namecoin is great. There's just no reason for it.

DNSSEC is compared with DNSNMC in this paper:

http://okturtles.com/other/dnsnmc_oktur ... erview.pdf

[biolizard89]

DNSSEC, IMO, is a dead end, and simply a waste of developer's time that could be better spent elsewhere. Problem 1 is its unnecessary complexity, and problem 2 is that there's simply no reason for its existence thanks to Namecoin and projects like DNSNMC.

Fixing DNSSEC with Namecoin is great. There's just no reason for it.

DNSSEC is compared with DNSNMC in this paper:

http://okturtles.com/other/dnsnmc_oktur ... erview.pdf

So I'm not clear on how DNSNMC makes this work unnecessary. Doesn't DNSNMC force you to trust the operator of the DNSNMC server? This work is for locally verifiable DNSSEC data, it's completely unrelated.

[ryanc]

DNSNMC/okturtles appears to only be addressing what DANE does, not DNSSEC in general. I read the paper, it doesn't look like DNSNMC/okturtles can authenticate SRV/MX/TXT record data. Also, you can sign the .bit zone yourself and have authenticated data with no central point of trust.

[ryanc]

My test server is up at namecoin.ryanc.org. DO NOT USE IT FOR ANYTHING CRITICAL! It's rate limited and I reserve the right to take it down and/or reconfigure it without notice or regard to anyone using it.

Instructions to follow sometime tomorrow.

Also note that my changes to NamecoinToBind have been merged into the official github repos.