<div dir="ltr"><div class="gmail_extra">2013/11/6 Paul Wouters <span dir="ltr"><<a href="mailto:paul@cypherpunks.ca" target="_blank">paul@cypherpunks.ca</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">I've answered Moxie (and others) on this before:<br>
<br>
<a href="https://nohats.ca/wordpress/blog/2012/04/09/you-cant-p2p-the-dns-and-have-it-too/" target="_blank">https://nohats.ca/wordpress/<u></u>blog/2012/04/09/you-cant-p2p-<u></u>the-dns-and-have-it-too/</a><br>
<br>
ExecSum: you cannot avoid trust, making it hierarchical gives the least<br>
trust to parties. You monitor those you have to trust more, more<br>
closely.<div class="im"></div></div></blockquote><div><br></div><div>A simply dumb article. "America" refers to a place in the Netherlands and also that huge continent. There's a certain decentralization in the fact that my nation picked that name for a place and the USA can't do anything but ask us to change the name. They didn't because nobody is actually that confused.</div>
<div><br></div><div>How? Context.</div><div><br></div><div>So what's the solution that removes the need for single source of Truth? One to Many relationships in the domain name system. Then some "context" mechanisms build into your local DNS daemon and browser to deal with the ambiguity. I'd imagine a simple "vote up or down" would suffice to give the right domain name to the right people. Provided you, at least practically, solved the identity problem. Possibly though a Web Of Trust.</div>
<div><br></div><div>I can also imagine central source being plugged in as a "According to ICANN:". Kind of like "sponsored results" in Google.</div><div><br></div><div>The idea that a method for agreeing upon a name with a larger group of people requires structure is valid. Language itself proves that. In fact language is a beautiful analogy.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In other words, address agreements are not “peer to peer”. There is a centralized, or rather a hierarchical method for assigning, reassigning and distributing location name updates. And the only reason it works, is because there is censorship and central control.</blockquote>
<div><br></div><div>Yeah, they are. Words' meanings are P2P too. The thing is you often allow a peer to make choices, a government for example, or simply comply with the most common agreement (a surprisingly common protocol). Censorship is a completely unnatural idea. The natural alternative is filtering, and it is done at the peer level. That's a form of self censorship and it remains a problem, imagine a community not propagating .xxx domain names. Anyway.</div>
<div><br></div><div>You do not need central control. You need an agreeable and compatible protocol. You do not need censorship, you need ranking.</div><div><br></div><div>Simply ranking ICANN 100% trusted and everyone else 0% is not only simplistic but also foolish. You seem to want to find out why.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The Domain Name System is a lookup mechanism similar to the Geo Location Name System (AKA “atlas”)</blockquote>
<div>Which atlas? You'll note there's quite some differences, and there have been. But DNS is mostly consistent (every day!).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The DNS serves to match an easy to remember mnemonic (“<a href="http://nohats.ca">nohats.ca</a>”)</blockquote><div>Unless the easy one was taken. Also: say that to all the non-ascii users! Took quite a while before <a href="http://naver.com">naver.com</a> could even become 나볼.한. In fact there isn't even a .한! Go figure!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> to an impossible to remember IPV4 or IPv6 address.</blockquote>
<div>That's a bit of a big statement ain't it? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
It ensures that no two entities can claim the same mnemonic.</blockquote><div>Unless some nation (cough china cough) would decide they'd rather have their own authority. I'd call this the biggest flaw in DNS history.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> And it is also really really big. If we look just at the COM, NET and ORG we’re talking in the order of magnitude of 100 million entries.</blockquote>
<div>There go all the easy to remember names. See also "parked domains". You love those don't you? Just imagine a ranking system wiping this form of spam to irrelevance!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If you do not live in Canada, your atlas likely does not contain the exact location of 100 Queen Street West, Toronto, Canada. If it did, your house would be filled with just your atlas.</blockquote><div>It's called a computer. It can contain such information in less volume than your fingernail. Welcome to real life.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So let’s say you have the perfect decentralized P2P DNS table. It can uniquely represent every “domain name”,</blockquote>
<div>Internal contradiction or empty statement. The most preferred page can be said the unique representation, but you map away a lot of information.</div><div><br></div><div>Reading your page I just can't figure how you think this problem is so hard! It's really <i>really </i>simple! </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Let’s assume Verisign had to give the NSA copies of the private key of the root zone, and the NSA can sign anything from the root down. </blockquote>
<div>This is so obviously the case. Wow. I mean just wow. The rest of the article ignores knowing that things like TLS and, well, everything else is also MITM'ed. If you're lucky something will complain to you, and if it does it can mean a whole ton of things. Besides, you're probably not lucky.</div>
<div><br></div><div>And let's not talk about the buckets of unused OS level exploits the NSA has. I mean what are we talking about here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden"><div class="im">"We had this map of the EFF's SSL Observatory data on what countries are currently capable of intercepting secure<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
communication under the CA system. Under [DNSSEC/DANE], it would look like this."<br>
<a href="https://www.youtube.com/watch?v=Z7Wl2FW2TcA#t=33m43s" target="_blank">https://www.youtube.com/watch?<u></u>v=Z7Wl2FW2TcA#t=33m43s</a><br>
<br>
(He shows a completely red map, indicating all countries)<br>
</blockquote>
<br></div>
That's a nonsense argument. Abuse of such powers, unlike the plethora of<br>
CA certs, would need to be world visible, that is untargetted. It would<br>
be very very visible. It is a huge win over CAcerts that can target<br>
individuals with specifically crafted signed certs.<br></div></blockquote><div><br></div><div>MITM. I am the master of what you perceive to be a reality. Argument invalid.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">With dnssec, if the Government of Canada causes my <a href="http://nohats.ca" target="_blank">nohats.ca</a> to be<br>
modified (appear red on your above map), then my domain's public<br>
information changes. I would notice that. This is not an invisible<br>
MITM like some CA cert injection.<br></div></blockquote><div><br></div><div>Well, yeah, and the server's SSL connection would also give you this information. HTTPS makes DNSSEC redundant is not exactly an awesome counter argument. Especially because DNSSEC does not make HTTPS redundant.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":5k" style="overflow:hidden">Which ever organisation you pick for the initial "name and crypto key<br>
lookup" has that power. What you must do is track and monitor, so ensure<br>
that power is not abused.<br></div></blockquote><div><br></div><div>Design flaw: I'm an end user. I don't even know what crypto is. (Monitor... Wasn't that the thing I'm looking at?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">It's very easy to say "trust no one". But if you want to talk to people,<br>
you need to place trust in some. All replacements I have seen of<br>
DNS(SEC) just move the problem elsewhere.<br></div></blockquote><div><br></div><div>The most robust of them all. Good old selfish-incentives. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">
You want to have a hierarchical trust pyramid. </div></blockquote><div>No. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">You can monitor, and even safeguard by picking some parts on the pyramic you trust more than the top (root).</div></blockquote><div>Which application lets me do this on my tablet again? What about my desktop pc? What about my fucking wifi-enabled printer? Will these trust profiles sync automatically? Or does it just not matter if my e-faxes are mailed to a different domain by my printer? Oh I shouldn't use my printer.</div>
<div><br></div><div>Thanks for nothing.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":5k" style="overflow:hidden">
This both scales and keeps the trust needed to be<br>
given to a minimum. </div></blockquote><div>Except that those I trust I give my life to. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div id=":5k" style="overflow:hidden">The higher in the hierarchy a trust organisation is, the less targetted violation of trust they can do. Moving down, trust is only handed down to entities that can only betray themselves, not others.<br>
</div></blockquote><div><br></div><div>Sounds false. I am really bothered by discussing something based on wrong axioms. You probably don't deserve my given amount of hate. Sorry about this. But really, you expect too much from users, intermediates and software especially. SSL has had trouble. DNSSEC will have trouble too. It's not magical.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":5k" style="overflow:hidden">Any kind of "harvest and vouch" or "public ledger" solution is going to<br>
be riddled with false positives, due to the delay between<br>
publisher/owner of the data and the trustee/ledger updating itself.<br>
Plus you don't even _know_ which parties it is that you are given<br>
trust to when accessing "N of M" entities to determine truth.</div></blockquote></div><br>Yeah I don't really know what you meant by that.</div><div class="gmail_extra"><br></div><div class="gmail_extra">DNSSEC is nice in that if you trust the root (or something closer by in the chain) and the records are signed than you have a place to get an SSL public key. That way you have two checkpoints, the server and the SSL chain and the DNSSEC chain.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">In practice I feel there'll be no great advantages because the signing giants will be the same giants. Mostly American (wonder where they got their initial funding!).</div>
</div>