
OkTurtles + DNSNMC: Surveillance-free communication on your favorite websites - ropable
http://okturtles.com/
======
colmmacc
Disclaimer: I've been involved in several DNS implementations, for a long
time, and so probably have a bias.

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.

------
swombat
Website lacks a summary of what this does exactly and how, other than "add
turtle buttons that do magic encryption voodoo" \- or did I miss it somehow?

~~~
MacsHeadroom
Did you miss the prominently linked to white (ie technical) paper?

~~~
swombat
I'm not a cryptographer, I'm a potential user. If I was up for reading white
papers on this, I wouldn't be interested in having buttons shaped like
turtles.

What I'm asking for is a summary of what this thing actually does from a semi-
literate layman's perspective...

~~~
jere
Oh, don't worry. I don't believe the white paper is at that level. It has
typos, smilies, movie references, it's clearly a work in progress, it's very
short, and it's written at a high level. Clever logo by the way.
[http://okturtles.com/other/dnsnmc_okturtles_overview.pdf](http://okturtles.com/other/dnsnmc_okturtles_overview.pdf)

------
rakoo
I'd have loved if instead of reinventing the wheel, they added support for GPG
keys in web-based inputs, and distributed GPG keys in DNSNMC. GPG is already
widely deployed (among the crypto-sensible people, of course), it would be sad
if we had to restart from scratch.

But this is still a step in the right direction.

~~~
itistoday2
(author here): GPG support for the web can be easily done with @okTurtles, and
was part of the plan from the start. It's very easy to do that compared to the
rest of the goals of @okTurtles.

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.

------
zobzu
\-----BEGIN PGP MESSAGE----- Version: GnuPG v2.0.22 (GNU/Linux)

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-----

~~~
AlexanderDhoore
So how do we read it?

Edit: I know public key crypto... I meant: where's the key?

~~~
coherentpony
You need his public key to decrypt it.

~~~
bushido
I think you mean private key. If it were public key it would not be secure at
all :)

~~~
coherentpony
No. You need his public key. His private key should be known only by him. That
said, he also needed the recipients public key to encrypt it.

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.

~~~
jnbiche
>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.

~~~
coherentpony
> Incorrect. To encrypt a message, you only need the intended recipient's
> public key. You don't need your own private key.

I don't think this is right. The diagram here appears to depict otherwise:
[https://en.wikipedia.org/wiki/File:Public_key_shared_secret....](https://en.wikipedia.org/wiki/File:Public_key_shared_secret.svg)

~~~
jnbiche
No. This diagram is depicting the creation of a shared secret for symmetric
communication. PGP is asymmetric.

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.

------
salient
I'd be interested to see another comparison with DNSCurve on your page
([http://okturtles.com/#DNSNMC](http://okturtles.com/#DNSNMC)):

[http://dnscurve.org/](http://dnscurve.org/)

[http://www.youtube.com/watch?v=K8EGA834Nok](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.

~~~
lukifer
It's tragic that Aaron won't be around to see (and aid) the coming wave of
distributed direct democracy.

------
97-109-107
I'm really happy to see this here; I've tried to build a tool based on the
very similar concept - initially just as a chrome plugin (I do see the irony),
but ran out of time, enthusiasm.
[http://kaniowski.info/umshade/](http://kaniowski.info/umshade/) Good luck,
really want to see this getting popular

------
nexttimer
I like seeing people offering solutions against mass surveillance.

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.

~~~
itistoday2
_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).

------
orenbarzilai
imho bitcoins technology is amazing and and the near future we will see a lot
of new products, such as this one, that are built on bitcoin technology but
aren't related to bitcoins.

~~~
chippy
You know, at the moment for me it feels as if this is exciting as if its on
the cusp of something great but I'm not sure what it is or how to put it into
words. Could you explain why it's amazing?

~~~
SectioAurea
I too have this feeling, and made a post about possibilities for traditional
state functions in the blockchain:
[http://www.wallstreetcrypto.com/2013/12/distributed-
anonymou...](http://www.wallstreetcrypto.com/2013/12/distributed-anonymous-
government-fourth.html)

It's a very fuzzy concept for now, but I'm sure someone will come along and
articulate it better.

------
infocollector
If its something that will work inside gmail/facebook frontends (web ui),
isn't it inherently at the mercy of google and facebook?

~~~
itistoday2
See section "6.3 Note on JavaScript Cryptography" in the paper:
[http://okturtles.com/other/dnsnmc_okturtles_overview.pdf](http://okturtles.com/other/dnsnmc_okturtles_overview.pdf)

------
Nux
I'd LOVE for something like this to take off.

------
sillysaurus2
From the whitepaper
[http://okturtles.com/other/dnsnmc_okturtles_overview.pdf](http://okturtles.com/other/dnsnmc_okturtles_overview.pdf)

"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.

~~~
itistoday2
_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._

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](http://dot-
bit.org/forum/viewtopic.php?f=5&t=1423)

Thanks again for your fantastic feedback! (What a wonderful Xmas present! :)

[1]
[https://github.com/feross/webtorrent](https://github.com/feross/webtorrent)

~~~
ama729
Isn't the same problem than with CA then?

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?

~~~
itistoday2
_Isn 't the same problem than with CA then?_

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"

------
mknits
So, it seems it's a PGP-based technique? Good.

------
itistoday2
Please note that the site and PDF describe two different, but related
projects. DNSNMC, IMO, is actually the more significant of the two, while
okTurtles is just one example of the type of app it makes possible. First
draft of a complete DNSNMC specification and implementation is being worked on
right now and will be pushed to
[https://github.com/okTurtles](https://github.com/okTurtles) soon.

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.

