namecoin / meta

General-Purpose Namecoin Repository
4 stars 3 forks source link

IMO: Validate DNS entries and encourage auth/fingerprint data inclusion #19

Open HutchSails opened 9 years ago

HutchSails commented 9 years ago

Per @JeremyRand - I moved this post from another issue to this new one:

I think that a modification to the client GUI that added a tab for DNS names (versus generic names) would make for a much more uniform domain name data set.

There were quite a few aberations in the sample I polled, including missing dots in the IP addresses, etc.

I looked at the last five thousand blocks, and found only 14 entries with fingerprints. So - the suggestion to incorporate a builder for certificates is good, and may encourage more people to put authentication bits into the blockchain. It's the authentication aspect of this project that is attractive (for me).

The CA snafu redirects me to blockchain authentication. I'm more interested in the auth aspect of namecoin than the coins themselves. To poll the data, I used:

namecoind name_filter "^d/" 5000 | grep fingerprint > log.txt

It timed out for larger sample sizes. I started namecoin with -timeout=200000 but the command timed out in only 30 secs. I'm not very familiar with namecoin, so any suggestions?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/16767221-imo-validate-dns-entries-and-encourage-auth-fingerprint-data-inclusion?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6562918&utm_medium=issues&utm_source=github).
JeremyRand commented 9 years ago

I too think that the best feature of Namecoin's d/ namespace is authentication. (Hence why I've spent a lot of effort over the past 2 years on that feature.)

Namecoin-Qt does actually have a textbox for entering a TLS fingerprint, but the UI isn't that good IMO. There's ongoing work to redesign that UI for better usability; @indolering , @phelixbtc , and I are working in that area. Suggestions on how we can improve are very much appreciated.

Validating the DNS fields as they're entered is definitely something that I support. I'm not sure I follow what you mean by "builder for certificates" -- do you mean that the user supplies a .pem file of the cert and the UI fills in the details?

As an aside, we're planning on deprecating the "fingerprint" field in favor of a newer spec which has better interoperability with existing infrastructure (e.g. the DANE spec). The new field will probably be called "tls". There are no implementations of that new spec yet (but I'm working on one).

Thanks for the feedback!

HutchSails commented 9 years ago

@JeremyRand : Great! Looking forward to what you come up with. Hopefully, you'll maintain the decentralized notion of a block-chain based authentication provider, and not tie it in too closely with DANE (see Moxie Marlinspike's comment about DANE).

IIRC Chrome is bundling auth bits (static pinning) via the Chrome installer for something like the top 300 web sites. If a blockchain (it wouldn't have to be the official namecoin chain) - were seeded with about that many domains, then we'd have something similar, but decentralized, for the most widely used sites.

Your freespeechme plugin could be configured to compare blockchain and direct-tls fingerprints, to notarize any discrepencies, which could be quickly weeded out. I don't know how the major sites would respond to an alternative domain lookup system, nor do I appreciate any of the legal angles that might be associated with the scheme. But - it's certainly something to think about...

JeremyRand commented 9 years ago

@HutchSails :

Great! Looking forward to what you come up with. Hopefully, you'll maintain the decentralized notion of a block-chain based authentication provider, and not tie it in too closely with DANE (see Moxie Marlinspike's comment about DANE).

I assume you're referring to Moxie's comments about DNSSEC's trust properties in the talk where he announced Convergence? If so, then it's not a problem -- we're not introducing third party trust, we're just structuring the API in a way that DANE implementations will be able to use Namecoin with less trouble.

I'm not really sure how a blockchain for storing TLS fingerprints for non-.bit sites would work exactly... could you explain a bit how you envision verifying that the blockchain's contents match the external world? If you're just envisioning perspective notaries, then there are projects like Perspectives and Convergence which try to accomplish that without needing a blockchain. (Their implementations kind of suck, but I won't get into that....) What benefits would a blockchain provide over the Perspectives/Convergence model?

indolering commented 9 years ago

FWIW, I think we should perform validation on the CLI client as well. There are plenty of names that are simply invalid.

Marlinspike's analysis of DANE is a bit off-topic, but it basically doesn't apply to Namecoin because Namecoin doesn't rely on third party trust/isn't controlled by a government. And while key pinning and triangulation (ala Convergence and Perspectives) are good ideas, they could be applied at the DNS level too. That would extend their protections beyond the browser to any application that performs a lookup.

JeremyRand commented 9 years ago

@indolering are you suggesting making namecoind warn name owners about values that don't match published specs? I don't think that's a great idea, because namecoind needs to be scriptable. I do intend to implement a "name lint" feature into NMControl, which end users of namecoind could call before writing their data to the blockchain.

indolering commented 9 years ago

@JeremyRand what about just adding it to namecoin-cli? We could also add a switch to suppress warnings.

JeremyRand commented 9 years ago

@indolering What is the advantage of calling namecoin-cli with warnings enabled compared to calling NMControl's name lint? For command line things, I'd prefer that namecoin-cli be solely for the name/value system and leave namespace specs to NMControl. Generally, namecoin-cli should be scriptable, and making it do unexpected things when a name fails the lint test will break some people's scripts. I do support loudly recommending the use of name lint before writing data to the blockchain (and it makes sense to integrate that into the GUI since that's a lot less likely to be scripted).

domob1812 commented 9 years ago

I'm with @JeremyRand here. I think that Namecoin Core should only be about the name/value system and should not care about the actual values. This is precisely what NMControl is for. Otherwise, we could just get rid of NMControl in the first place and add also IP resolution and everything else to namecoin-cli.

indolering commented 9 years ago

I don't really understand the backlash, warnings are a pretty standard feature for the command line applications. But I'm certainly not going to implement this stuff myself and it's a pretty minor feature so .... ¯(ツ)