From: Justin Newton <justin@netki•com>
To: Riccardo Spagni <ric@spagni•net>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias
Date: Thu, 16 Jul 2015 17:55:10 -0700 [thread overview]
Message-ID: <CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com> (raw)
In-Reply-To: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4880 bytes --]
I am breaking this into a couple of pieces as my first response has been in
a moderator queue for some time because it is too long.
TL;DR version - Wallet Name Service has always been a decentralized and
distributed service that it no way requires you to ever touch the Netki
infrastructure. We want to work with the community, as we have been from
the beginning, to come up with the best standard possible.
Longer answers inline below.
On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spagni <ric@spagni•net> wrote:
>
>
>> In terms of comparisons to OpenAlias, I think there are a lot of
>> similarities, but a few differences. First the similarities:
>>
>>
>> 1> We both use DNSSEC.
>>
>> 2> We both have the option of storing the address directly in the DNS
>> record.
>>
>>
>> Differences:
>>
>> 1> We do not use DNSCrypt. I understand why you chose to, but we were
>> concerned about broad interoperability and easy broad distribution of
>> hosting, so decided not to use it. We have other ways of achieving
>> privacy, using HD Wallets and Payment Requests.
>>
>
> And this is the part where you guys look really, really incompetent (and I
> don't mean that in a terribly demeaning way, it's just that you're in a
> space where you want to be a domain expert, not make a series of
> embarrassing and public faux pas).
>
>
> I appreciate the thought :) I think where we differ is on where we
believe the trade offs should be on perceived privacy versus censorship
resistance and centralization.
By having a limited number of proxies people need to go through to easily
implement, be it the 4 you recommend, or 53, you actually have a very
limited number of actors for an authority or hacker to go to in order to be
able to install/force logging, or censorship. This very centralization
forces us back to a model where we need to trust a very small number of
actors in order for the system to operate as designed. This, to me,
appears to be the opposite of the goals of the bitcoin ecosystem. To
ensure this point is clear, I strongly believe recommending people focus
all lookups through 4 centralized "proxies" is a bad idea and counter to
bitcoin's ideals.
The fact that hackers or state actors need to corrupt only a small number
of servers/services in order to gain global visibility into all queries, I
believe, breaks any perceived privacy gains from using DNSCrypt. A very
small number of hacks or subpoenas and everyone's records are fair game in
one place.
For the highly privacy conscious they can, today do their DNS lookups over
a non logging VPN connection without forcing everyone else through a
handful of centralized servers. Or they can use DNSCrypt optionally
themselves. All of our tools have always been open source and folks can
modify them for their own desired uses, or submit pull requests with their
own ideas.
We'd love to hear others thoughts on this. While I believe that for now
the centralization trade offs required to use DNSCrypt today (via a limited
number of proxies) outweigh any perceived privacy benefits it provides, we
are always open to what others in the community believe and have made
modifications to how things work before as a result of feedback from
industry participants.
>
>
>> 2> We have the option of storing a URL rather than just a wallet
>> address in the TXT record. This allows a second level lookup against
>> the URL to get back a unique HD Wallet address or Payment Request each
>> time, further protecting user privacy and security. Using Wallet
>> Names with Payment Requests allows for the user experience of typing
>> in an easy to remember name and getting back the "green lock" and who
>> the validated recipient is. This also provides an auto audit of the
>> end to end DNS SEC process, in the case the path were somehow
>> compromised, the signature on the payment request can provide an
>> additional check.
>>
>
> OpenAlias supports this as well, except it does it better by allowing the
> KV pairs to also contain a TLSA record before the request, which
> effectively makes it a DANE-secured interaction. Your interaction requires
> the trusting of multiple CAs, which is an inherent weakness.
>
I think DANE is a great idea. We were just discussing that with Andreas
S., and are currently looking at whether we want to add this as optional
versus mandatory, based on how widely available DANE is for folks using
services like Cloudflare, Akamai, etc for their DNS, which many providers
in the space today are.
Of course, the security conscious could setup DANE on the URL we use AS
IS. There is no need to create a special kv pair for this as is done in
OpenAlias. As you know, DNSSEC and HTTPS support this today out of the box.
The CA validation, in our case, is an ADDITIONAL signature based validation
to the DNSSEC chain, not a replacement for it.
[CONTINUED]
[-- Attachment #2: Type: text/html, Size: 6906 bytes --]
next prev parent reply other threads:[~2015-07-17 0:55 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 19:07 Riccardo Spagni
2015-07-17 0:55 ` Justin Newton [this message]
2015-07-17 0:58 ` Justin Newton
2015-07-17 1:01 ` Justin Newton
2015-07-17 1:02 ` Justin Newton
2015-07-23 9:48 ` Thomas Voegtlin
2015-07-23 13:07 ` Thomas Voegtlin
2015-07-27 21:51 ` Justin Newton
2015-07-31 20:34 ` Thomas Voegtlin
-- strict thread matches above, loose matches on Subject: below --
2015-07-27 22:46 Riccardo Spagni
2015-07-18 11:40 Riccardo Spagni
2015-07-18 11:46 ` Mike Hearn
2015-07-17 8:00 Riccardo Spagni
2015-07-18 11:21 ` Mike Hearn
2015-07-16 16:18 Riccardo Spagni
2015-07-14 17:29 Justin Newton
2015-07-18 13:29 ` Thomas Voegtlin
2015-07-18 23:01 ` Justin Newton
2015-07-20 8:56 ` Thomas Voegtlin
2015-07-14 8:29 Riccardo Spagni
2015-07-13 22:31 Mike Hearn
2015-07-14 6:42 ` Thomas Voegtlin
2015-07-14 11:19 ` Milly Bitcoin
2015-07-14 13:13 ` Thomas Voegtlin
2015-07-14 11:45 ` Mike Hearn
2015-07-19 11:18 ` Thomas Voegtlin
2015-07-20 13:46 ` Mike Hearn
2015-07-20 14:32 ` Thomas Voegtlin
2015-07-20 14:42 ` Mike Hearn
2015-07-20 14:52 ` Thomas Voegtlin
2015-07-20 15:14 ` Mike Hearn
2015-07-20 15:34 ` Thomas Voegtlin
2015-07-20 16:09 ` Mike Hearn
[not found] <55A3B52C.9020003@electrum.org>
2015-07-13 13:06 ` Thomas Voegtlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com' \
--to=justin@netki$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=ric@spagni$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox