OkTurtles + DNSNMC: Surveillance-free communication on your favorite websites
okturtles.com
okturtles.com
Namecoin and namecoin-derived systems are cool, but they tend to overlook a lot of real-world functionality provided by DNS. As used today DNS is 1) A distributed key-value storage system 2) Incredibly scalable and fault-tolerant and 3) a de-facto internet routing layer for CDNs and GSLB endpoints. Namecoin systems typically provide (1) but overlook (2) and (3), which makes it hard to consider them as viable replacements.
I think it's interesting to look at what existing entities do when faced with DNS MITM and takedowns. The various torrent searchers and anti-censorship entities just diversified the TLDs they depend upon. So when their ".com" or ".net" domain gets taken down or man-in-the-middled, they tell their users to shift to .is , .ch, .se or some other TLD with a different regulatory framework, thus avoiding a single point of failure.
If a new mechanism depends on the inconvenience of a browser extension anyway, why not automate the process people already use? For example "colmmacc.multi" could be intercepted by an extension and translated into 5 DNS requests against say SHA-2("colmmacc").[com|ch|ly|se|is] and the extension could use a simple majority quorum of the answers to defend against a tampered response. Of course it means you have to register and host your domain 5 times, but that's pretty cheap these days.
Other nice properties: works with all existing DNS security mechanisms (including DNSSEC or DNScurve), provides security against registrar or registry level tampering or compromises. Hash of the domain makes it hard for registries to block domains (they have no idea what the name is until it is popular) and also resets the clock on squatters.
What I'm asking for is a summary of what this thing actually does from a semi-literate layman's perspective...
Well, how do you propose the details be presented "straight away"? They require a good bit of explanation, and a bunch of text "straight away" would make your eyes glaze over.
Scroll down a bit and the information is introduced in manageable chunks. Then there's the paper that salient linked to. You just have to scroll a little bit, and if that's too much for you... well, again, feel free to offer suggestions. :)
http://okturtles.com/other/dnsnmc_okturtles_overview.pdf
Edit: re: "lazy kit web site", the site was made from scratch by Will Stanley (and I wrote some of the JS for it). I think he did a great job.
This is what I think you're saying:
1) Namecoin successfully squares Zooko's Triangle.
2) Namecoin is hard to use, so something new, let's call it DNSNMC, will be needed to make it easy.
3) A DNSNMC server will decode data from the namecoin chain, and you can trust that it is telling the truth because you already trust that DNSNMC server.
A trusted proxy/offload for namecoin lookups isn't a crazy idea, but it doesn't add much to the system.
I'd suggest rewriting this paper and removing all the political justification for why one might want such a system. Everyone gets that, but not everyone wants a system like this for the same reasons anyway.
And since it's of interest to you anyway, I'd very much like to read some analysis from you on Dan Kaminsky's criticisms of Aaron's proposal. Does Namecoin square Zooko's Triangle?
For reference, dvanduzer is most likely referring to this blog post and the exchange that took place in the comments: http://dankaminsky.com/2011/01/13/spelunk-tri/
First, let me answer your question, "Does Namecoin square Zooko's Triangle?"
Yes, I believe it does. Whether or not Namecoin works depends on whether or not Bitcoin works. They are the same exact technology (they're just used for different purposes).
From what I could tell of Dan Kaminsky's comments, I believe his arguments boil down to the well known 51% attack. Two things of note here:
1. See Dan's 2013 post on businessinsider where he appears to be retracting his words: "I Tried Hacking Bitcoin And I Failed" http://www.businessinsider.com/dan-kaminsky-highlights-flaws...
2. The 51% attack is still a real threat. The Bitcoin community is on it:
Proof of blockchain fair sharing is a draft Bitcoin protocol change
proposal by Iain Stewart, with the goal of allowing the network to
continue to settle on a sensible consensus blockchain even when
subject to a considerably- greater-than-50% attack.
The protocol is under construction. The following description is a
"teaser", establishing its basic flavour and sketching how it exploits
an asymmetry in the goals of the honest (<50%) and malicious (>50%)
miners to avoid the usual reductio ad absurdum argument against any
protocol surviving a >50% attack.
Re: "I'd suggest rewriting this paper and removing all the political justification for why one might want such a system. Everyone gets that, but not everyone wants a system like this for the same reasons anyway."
Given the well popularized "debate" on this topic, I think it's quite clear that everyone does not get that.
it doesn't add much to the system.
It adds:
- The ability for JS apps to talk to and retrieve info from the blockchain without a browser extension (this wasn't possible before. It's a significant thing IMO).
- A new meta-domain (.nmc) and corresponding RESTful API for manipulating the blockchain
- DNSNMC may also support DNSCrypt (so that adds secure queries too).
- A gateway for browsers and other software to verify SSL certs without having to run a local namecoind client. (Which means you don't need to pay for them anymore!)
Probably other useful stuff I'm forgetting at the moment. Perhaps others might chime in. Oh, see also related topic: "Transitioning the web to Namecoin by addressing squatters" https://dot-bit.org/forum/viewtopic.php?f=5&t=1439
Actually, let me qualify that comment, I should say that it effectively does. As Dan notes, BitTorrent, for example, is considered to be a decentralized protocol, but it does have some centralized components "for a reason".
IMO, in practice, this is inconsequential, because those centralized components aren't critical pieces, and they are fully "hot swappable". Any one of those bootstrap servers can go down, and they can be easily replaced. They don't really hold any valuable information themselves, they're just entry points into a distributed network.
Regardless, this gets down to the crux of the "squared triangle" issue. Getting introduced to the network isn't the only place where centralization helps, and it's probably not even an important one, as you say. A human that wants to get on the BitTorrent network just finds a client binary. There isn't a need at any point to type bit torrent dot com into a browser.
Arguably, the human-oriented / memorable leg of the triangle can't be solved globally. Here's some really good thinking on the subject: http://stpeter.im/journal/1035.html
1) Dan's comments on Bitcoin in that BI article are a bit subtler than that. The very last section suggests (to me) that despite what value the BTC protocol has, it doesn't "square the triangle."
2) Dan is mainly talking about Sybil attacks in his 2011 post. The difference between a 51% attack and a Sybil attack is somewhat blurry, but here's my understanding:
A Sybil attack can't be prevented if an attacker controls >33% of the nodes. This is a mathematical truth of distributed systems (cf. Byzantine Generals), but Bitcoin's proof-of-work is often cited as the first practical system to demonstrate a workaround.
The >50% problem becomes the new lower bound for attackers, because with proof-of-work, you can't just fake 33% of the nodes. They have to be participating in the number crunching.
However, recent research blew this entirely out of the water, at least as far as Bitcoin goes[0]. They propose a change to the protocol that makes it a >25% percent problem, but currently it is a >0% problem. That is kind of a big deal. There are some good ideas in the "proof of stake" discussions, but none of the answers appear to lend support to the "triangle is squared" hypothesis.
Now then: I think you misunderstood my remark about the political aspects. I'm not saying anyone agrees on who/what/when/why/how of privacy issues. If the goal is to describe a system that is resilient to eavesdropping, you shouldn't distract from that system in the same paper with so much argument about why you want a system resilient to eavesdropping. Spill your ink to convince people if your system meets the requirements you lay out. Finally:
- "meta-domain" is a very strange term to use. It makes you sound ignorant of the realities of DNS, whether you are or not.
- My statement was that a proxy to namecoin doesn't add much to the system. The first and fourth of your bullet points might be paraphrased as "but it adds a proxy to namecoin!"
- What would be the purpose of adding DNSCrypt to DNSNMC? What do you mean by "secure queries" there? Anonymous queries? Validated responses? It's okay if you haven't finished specifying DNSNMC yet, but I wasn't asking for guesses about what you might do in the future.
Meanwhile, don't let counter arguments discourage you, but remember that the problem space is large. Failure to solve a gigantic problem may still be success when solving a normal sized problem.
> The very last section suggests (to me) that despite what value the BTC protocol has, it doesn't "square the triangle."
How so?
> However, recent research blew this entirely out of the water, at least as far as Bitcoin goes[0]. They propose a change to the protocol that makes it a >25% percent problem, but currently it is a >0% problem. That is kind of a big deal. There are some good ideas in the "proof of stake" discussions, but none of the answers appear to lend support to the "triangle is squared" hypothesis.
I was looking for that paper a while ago! Somehow my google-fu failed me and I got distracted by something else, and so, forgot about it for a while.
Thanks to you, I've had a chance to download the paper and read it.
Indeed, at first glance it might seem like they're pointing out a big hole in BTC, but I don't think this is the case, and neither do a lot of other folks over on the BTCtalk forum. [1]
There is one big flaw in their paper that the authors acknowledge (quite poorly IMO) in their followup blog post to the reactions that they received [2], and that is point #9, that they for some reason buried toward the bottom of the blog post:
Our paper does not address what happens when multiple pools employ the
selfish strategy. But if all pools were selfish, the blockchain would
not make forward progress for large periods of time, while selfish
groups hoard their blocks. Then, perhaps, depending on the profit-
taking strategy of the selfish miners and their relative sizes, it
would take erratic large steps forward. Such erratic behavior would
not bode well for the users who want to transact in the currency.
I say that it demands an answer because the probability that exactly one pool would implement this strategy is, I think, close to zero.
For some strange reason, the authors (in their blog post) decided to jump to the other extreme and analyze the case where "all pools were selfish"! Well, that's a rather silly thing to do, because you don't go from 0% to 100% in one leap like that, so their analysis there, and related commentary, can simply be dismissed.
The interesting question remains: what happens when some pools start to implement this strategy?
I do not know for sure, but I suspect that the result will be a wash, so to speak, and most likely will end poorly for the cheaters (when they are caught). Their entire paper is based on the absurd claim that a single selfish pool will grow, like some sort of cancer, until it reaches 51% proportions (and then it's game over). While this is a possibility, at the moment it seems like an exceedingly remote one. In fact, the more cheating pools there are that use this strategy, the less likely their vision of a BTC doomsday becomes. Which group of bandits should one join, and is it worth the risk?
Speaking of risk, Stephen Gornick quickly pointed out a simple technique for detecting these cheaters: " Wouldn't it be easy to tell if a block seems to be coming from a selfish pool (as each new block will appear to be laggng since it has no recently arrived transactions)? So if this lag can be detected then cannot an incentive to honest pools be offered?" [3]
> If the goal is to describe a system that is resilient to eavesdropping, you shouldn't distract from that system in the same paper with so much argument about why you want a system resilient to eavesdropping.
On this issue, I think we simply differ in opinion. I did not consider that section to be a distraction. Rather, I considered it to be an essential part of the paper, without which it would have been lacking. I think it would have been a disservice to the two projects (and to the paper itself) had I left the motivation section out. Only a tiny fraction of the intended audience of the paper is like you (already convinced of the need for an ubiquitous surveillance proof system of communication).
> "meta-domain" is a very strange term to use. It makes you sound ignorant of the realities of DNS, whether you are or not.
What term would you prefer then? It's a somewhat novel concept (so far as I know).
> My statement was that a proxy to namecoin doesn't add much to the system. The first and fourth of your bullet points might be paraphrased as "but it adds a proxy to namecoin!"
I agree on your last point, that the first and fourth bullets can be (somewhat inaccurately) summarized in that way, but I strongly disagree with the notion that it "doesn't add much to the system." It makes Namecoin usable. That's huge.
> What would be the purpose of adding DNSCrypt to DNSNMC? What do you mean by "secure queries" there? Anonymous queries? Validated responses? It's okay if you haven't finished specifying DNSNMC yet, but I wasn't asking for guesses about what you might do in the future.
Sorry, by "secure queries" I meant "encrypted queries". It protects against another form of surveillance.
Thank you very much for your wonderful, very astute comments!
[1] https://bitcointalk.org/index.php?topic=324413.0
[2] http://hackingdistributed.com/2013/11/14/response-to-feedbac...
[3] https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
>The interesting question remains: what happens when some pools start to implement this strategy?
>I do not know for sure, but I suspect that the result will be a wash, so to speak, and most likely will end poorly for the cheaters (when they are caught). Their entire paper is based on the absurd claim that a single selfish pool will grow, like some sort of cancer, until it reaches 51% proportions (and then it's game over). While this is a possibility, at the moment it seems like an exceedingly remote one. In fact, the more cheating pools there are that use this strategy, the less likely their vision of a BTC doomsday becomes. Which group of bandits should one join, and is it worth the risk?
The revenue dynamics of selfish mining (SM) are such that two SM pools working independently are better off joining forces. The excess revenue for SM is super-linear in pool size. So, with X% of the mining power working selfishly, you make (X(1+eps))%, with Y% mining selfishly, I make (Y(1+iota))%, but if we combine forces, we make (X+Y)*(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces. And since there is nothing at the protocol level to break up large mining pools, there is an incentive for SM pools to get large and grow until the 50% point.
We deliberately deferred a game-theoretic analysis of selfish mining to a future paper, because such analyses tend to be highly dependent on modeling assumptions. E.g. would an attacker view reaching the >50% point as a complete failure event when all coin value drops down to 0, or as a complete success event? The answers on how to model this apocalypse depend on too many assumptions about the attacker, his motivation, and what others can detect about his power. A thorough job of modeling the game-theoretic dynamics of Bitcoin (with selfish mining) would indeed make an exciting follow-on paper.
> if we combine forces, we make (X+Y)•(1+delta)%, where delta>eps+iota. So we not only get our normal winnings, but we win an additional reward for joining forces.
I'm not convinced that that matters. Let's say you're right and that your math is flawless (it's late, so I haven't verified it).
If there is just one cancerous pool growing, then doesn't that make the job of policing the network even easier? Have a look at Stephen's post on btctalk: https://bitcointalk.org/index.php?topic=324413.msg3478147#ms...
Using his method (or something similar) it would be rather obvious that something was fishy about the blocks this group was publishing. If it could be developed into a proof, then the entire selfish pool would be permabanned from the network, publicly tarred and feathered, etc. and there would be no problem.
Am I missing something? (If I am, don't jump too hard on me please, I'm about to head to sleep! :p)
So Stephen's point is that there may be operational procedures that might allow one to detect selfish mining. This is great, as this is what we want is for Bitcoin to deploy in-protocol incentives to break up selfish miners. But there are two issues: (1) I'm not sure that his suggested tactic of judging by the latest timestamp would actually work well for established pools. I suspect that some pools are less eager to update their xaction sets, and therefore might lose to selfish miners, and (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.
Hope this is useful.
[1] http://hackingdistributed.com/2013/11/17/selfish-mining-simu...
I don't see a reason as to why they would object, care to offer one? Plus, since you point out a threat that I think needs to be addressed (thanks btw!), this can be mandated in an updated protocol if the Bitcoin (or Namecoin) devs feel similarly.
> (2) even if these operational measures worked perfectly, they would succeed in lowering gamma. But even with gamma at 0, selfish mining is still a win for groups of size 33% and above.
Here I think you misunderstand. The implications of my comment were not simply that gamma is reduced to zero, but that the whole problem is thrown out the window because the entire pool would be banned from the network (blacklisted). Their selfish blocks would no longer be accepted by the network, and the implications could be even stronger than that (transactions, connections, etc. could also be rejected).
No one on the IRC channel explained how this problem would be handled once it is detected. They refused to engage in such discussion, except to say that they wouldn't use Stephen's solution because it could introduce other problems. The current response has been an almost resounding, "We're going to stick our head in the sand and ignore it." (And then downvote you on HN for bringing it up and attempting to discuss it. :p)
Edit: Here is the full, unedited transcript of what went down on #bitcoin-dev (in RTF doc format): http://jmp.sh/v/sTXe0VvyTW7pM3WgOGkT
Sorry, this subject matter has been discussed and debated at great length in a dozen places. No one has the time to hand-hold each and every person who learns about it and freaks out, especially if they come off as demanding and abrasive rather than inquisitive and helpful.
Saying that it is considered a non-issue would be a misrepresentation. It exists as part of a large collection of things which are potentially concerning but which are not currently problematic. Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done. So far as I've seen none of the proposed "fixes" are compromise free and many carry new, subtle, and difficult to analyze risks which may have far greater practical implications than the problem they claim to solve.
From a more practical perspective, action has been taken to improve network connectivity so that achieving alpha much greater than zero should be impossible in practice, and do the extent thats successful then there is only an issue with >33% consolidations— which are already problematic for other reasons (e.g. they can reverse six confirms with a 20% success rate).
Your specific concerns seemed to be mostly related to mining pools engaging in this activity without the consent of their hashers, this particular threat is eliminated completely by hashers that use GBT and submit blocks themselves— as you were pointed to.
In any case, in the future when you find yourself sending demands to volunteer developers asking them when they will solve your pet concern you should first ask yourself when _you_ plan on solving it.
It's a security issue related to bitcoin, which in turn is related to Namecoin, which in turn affects DNSNMC. Seems fairly on topic to me, but others are welcome to disagree (just explain why if you do).
No one has the time to hand-hold each and every person who learns about it and freaks out, especially if they come off as demanding and abrasive rather than inquisitive and helpful.
Sorry, I did not realize that I was coming off as demanding and abrasive. I can see how "demanding" might have been seen now, and I apologize for that. Abrasive though? I don't see that, I was just asking questions and for help understanding the BTC dev's thoughts on this.
Note that I also asked whether there was a document (perhaps on the bitcoin wiki) that had all the explanations on it already. The response was less than helpful.
Your proposed urgent deployment of "fixes" carries enormous risk and so it absolutely will not be done.
I think this was simply due to misunderstanding. It was never my intention that any one "fix" be adopted immediately. I was just looking for reassurance that something is being done about this, even if it's just the reassurance that the devs acknowledge the problem and are investigating methods of addressing it.
Your specific concerns seemed to be mostly related to mining pools engaging in this activity without the consent of their hashers, this particular threat is eliminated completely by hashers that use GBT and submit blocks themselves— as you were pointed to.
And as was pointed shortly out by gmaxwell, that doesn't matter for those who choose not to. If it's a certainty (or highly probable) that the network will adopt GBT, and that somehow implies that the problem is fixed, then that could have simply been explained. Instead, I was kicked from the channel and then my posts here were downvoted out of spite.
In any case, in the future when you find yourself sending demands to volunteer developers asking them when they will solve your pet concern you should first ask yourself when _you_ plan on solving it.
I'm sorry you perceived it as me "sending demands to volunteer developers". For any part of that that is true, I apologize. Like I said at the start of this reply, all I wanted to hear was that something is being done to address this problem, and if not, why not.
As for me solving it, I had pointed out a solution that I thought was helpful (Stephen's), but folks chose not to discuss that in any calm sort of way. I don't know why. Perhaps you may want to re-evaluate the way you (and others) reacted toward someone approaching the community with a concern and asking questions. I am not some type of thing for you to feel threatened by. My intentions were benevolent. I come in peace. ;)
Ah, but even if detection worked perfectly (and did have a false positive rate of 0), who precisely do you blacklist? The Bitcoin wallet? It's trivial to generate more. The IP address? Which precise IP address? Even if you could locate the IP address of the submitting node accurately, a pool has many, and it's possible to get more.
I must focus on other things now, but I want to thank you for bringing this problem to the attention of the bitcoin community, even if they have chosen to ignore it and pretend that it's a non-issue.
I look forward to reading your followup paper (if and when you publish it). I hope you'll have a good solution in it.
(My brain is tempted to consider some using sort of stronger identity system than IP addresses [like Namecoin], but I really don't like that. That could potentially cause far more severe problems, especially if done incorrectly. And it seems like a hack.)
But this is still a step in the right direction.
One thing about that though, is that GPG-based communication suffers from all the problems described in the OTR docs (and the overview paper on the site, see sections on plausible deniability and PFS). But if you want it, again, it's very simple to transparently support GPG on the web (once the rest of the foundation is implemented), and I can definitely see how people would find that useful for forums, reddit, HN, etc.
hQEMA/H221DfyGXJAQf+IDMe33H8hz1MgYfqxGta/FauUinOWtXqT+xskkGtt+es wRE1stgcJeKlzFDMHMS99Cvfw1qUis+CMVUnrBJw3yn1tdNo3FV+V0BgMIJwTPGS nkHxeXsxHXcsgcyRhB1PEO2arPaiek9xqxwUehnsDHI8T6oAJaUhteNHo72ybM4S Q1vSY8/Ni6t7Uk5zjpsHPq+Jhi7+QA9L1xaJuNBcm1lQxE2hWyrdXRB7N+HMnvJR LMgZndBjoKeui032cbIV8z/N7n2YT8Vtx0syVkDT0KppcW4EcQyAp6hbRPrgnUMu jDLLwT1xSgPwtH8NPo0iuusGmONa+stGGmjwHnhiLNJxAZWGQM36uE+FA9bXUVDl ikp29kE8qmCijPIHSDUny6SiNUjrEJeQEBq4TJpU7GDEsOQKx2tjchOZyWQFpKWK mBPnU6H9uAAByM+t+ejG5lxxlp/R9eKBs+YSf7QT7H2sLR/KIwyuXNJg+oHBtzKY weo= =bZbG -----END PGP MESSAGE-----
Edit: I know public key crypto... I meant: where's the key?
Private keys are private. Public keys are public.
Edit: I realise this is unclear. He needs his private key and the public key of the recipient to encrypt the message. Then only the recipient can decrypt the message. To do this, the recipient needs his private key and the encryptor's public key. Hope that helps.
Incorrect. To encrypt a message, you only need the intended recipient's public key. You don't need your own private key.
Likewise, for the recipient to decrypt, they only need their private key. No need for the encryptor's public key.
You can send messages to other PGP users without ever creating your own keypair. It's only to receive encrypted messages that you need a keypair.
Now, if you want to sign a message that you're sending, you need a keypair.
I don't think this is right. The diagram here appears to depict otherwise: https://en.wikipedia.org/wiki/File:Public_key_shared_secret....
I tell you what. Do you have a PGP keypair? Post your public key here (the one you would host on a public keyserver) and I'll show you a short script that can encrypt information that only you can read using your private key. It will use no other keypair besides your own public key.
> You need his public key to "decrypt" it.
My correction assumed that you had made a typo when you said "decrypt".
Also you only need the recipients public key to encrypt the message. [0]
If the poster wanted all of us to be able to read it, they would have encrypted it with their private key. Then we'd just need their public key, which is published on keyservers, to decrypt it.
Why would anyone do this? Because it is a way to verify that the message came from a specific person or group. If you can decrypt a message with a given public key, you know "Only the people who have access to the corresponding private key could have published this message." You don't necessarily know who, in specific published it, but you can do things like determining that a batch of messages all came from the same group.
Now, if the person had encrypted it with a specific person's public key, then only that specific person would be able to decrypt it, because messages encrypted with a public key can only be decrypted with the corresponding private key. Being able to post private messages in public fora without needing to meet the recipient beforehand is one of the main features of public-key cryptography.
That's really interesting, I had no idea that public key encryption could be used this way.
The common use case is to _sign_ with a private key and _verify_ with the public key. If you need the contents of the message to be secret, you can use other methods. The signature proves something about the authorship of the original message.
For example, if someone wished to make a prediction about the future, they might write down the prediction, sign it with a private key, but then only publish the signature. Later, when the prediction turns out to be true (or false), they publish the original text. The public key can then verify that the precise text of the original prediction created the previously published signature.
edit: in this case, zobzu might have created a one-use private key, encrypted a prediction about DNSNMC with the corresponding public key, and will later publish that private key. Or it might be the output of /dev/urandom
Your comment would be instantly readable to whoever the intended recipient(s) are, with no manual intervention on their part. (see also reply 'rakoo': https://news.ycombinator.com/item?id=6963081)
http://www.youtube.com/watch?v=K8EGA834Nok
It seems Aaron Swartz has inspired so many great projects. It makes me sad that he's no longer with us from such a young age. It seems he had a lot of potential to change things for the better.
What I want to suggest is that you drop the requests you send to 3rd party services like Google. If somebody makes money off of collecting as much data about us as they can, it's Google, Facebook, etc. So, letting them track your users is a contradiction.
What are you referring to? There's no Google tracking code on the site. The only analytics is Mint (which is local to the server).
It's a very fuzzy concept for now, but I'm sure someone will come along and articulate it better.
"The magic doesn’t stop there. DNSNMC isn’t just DNS + NMC, it’s also an HTTP server. DNSNMC provides its clients with secure access to the Namecoin blockchain itself through a RESTful API."
They're planning on shipping this browser extension with a hardcoded list of DNSNMC server IP addresses. Isn't that a central point of failure? (E.g. If an adversary mounts a DDoS against all servers in that list.) Adversaries wouldn't need to render the service unreachable, just slow it down to painfully-slow speeds for average users. Regular DNS is resilient to this because of its hierarchical design, but the paper seems to be proposing a flat list of DNSNMC servers that will be shipped with the extension by default. Since almost all users will stick with the defaults, subverting those servers would disrupt DNSNMC for most users.
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry. Is it password-based? Like, when a user first creates a blockchain entry, do they set a password they must remember? If so, then what happens when they inevitably forget their password or someone steals it via a key logger? It needs to be changeable in case the old password is compromised, but that causes a whole bunch of problem scenarios, like an attacker steals a password then changes it, then modifies the user's blockchain entry. How does a user recover his stolen blockchain identity?
Overall the whitepaper is a comprehensive survey of the current public key infrastructure landscape and embodies some interesting ideas for the future. While there are some very dubious ideas (like tackling all problems with JavaScript crypto) I'm cautiously optimistic about the overall direction this whitepaper is proposing, because something similar to this is a necessity: a distributed DNS system that doesn't rely on certificate authorities, and lets users distribute their public keys in a public way that can't be easily MITM'd. There are unsolved problems, like how users can recover a stolen identity, but this whitepaper takes care to be extremely clear that it's a work in progress, and that it's being made available to get early feedback on the design / to solicit ideas from the community. They don't pretend that they've thought of everything, which is nice.
They're working on an important problem (a future in which CAs are unnecessary + giving everyone a way to distribute encryption keys tied to your public identity) so this kind of research is sorely needed, and I look forward to seeing what their next step is.
This is a good point. Two things: (1) you stopped a bit short in your quote. Here's a bit more from the paper on that:
"To avoid falling into the same trap that web browsers enjoy today with Certificate Authorities, okTurtles will encourage the user to use their own DNSNMC server, whether it’s one that they have setup themselves, or one that belongs to someone they trust. Defaults are provided to encourage adoption and to make the software function immediately upon install."
(2) That paper is the first public introduction of DNSNMC, and I expect (and really appreciate) everyone who reviews (and has reviewed) it, and pointed out issues like this.
That said, this problem could be solved by something like a DHT [1]. Or, it might be a non-issue and not really need something that complicated. Just a live-updating list of trustworthy IP/fingerprint pairs (with bootstrap servers, protected by something like cloudflare), might be all that is necessary for the defaults (which again, the extension would encourage switching off of).
Also, it's unclear to me how users or website owners use DNSNMC's REST API to update their blockchain identity entry.
Yes, that API is being worked on right now, so your comments are definitely helpful, and you're also very much welcome to provide any and all other feedback. Here's another great place to do it: http://dot-bit.org/forum/viewtopic.php?f=5&t=1423
Thanks again for your fantastic feedback! (What a wonderful Xmas present! :)
Most people wont have their own server or have someone they trust have one.
Isn't something like Confluence more interesting on this point of view?
Well, it starts out similar to that problem, and the quote I gave above acknowledges and addresses that. It's not the same problem, though. Running your own CA today, and having it accepted by everyone else, is not simple (almost impossible), even for advanced users.
Most people wont have their own server or have someone they trust have one.
You sure about that? I see a one-click business opportunity for someone here. :)
Isn't something like Confluence more interesting on this point of view?
You mean Convergence? Have a look at section 4 in the paper which discusses the issues with that: "Existing attempts to fix this problem"
A rudimentary DNSNMC is very simple to implement in something like Nodejs. The version that will be pushed to github will be written in CoffeeScript and NodeJS. At some point my hope is to provide a version that installs easily on Linux via package managers and integrates nicely with PowerDNS.