Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5FDD6BA1 for ; Fri, 17 Jul 2015 00:55:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 77EBD143 for ; Fri, 17 Jul 2015 00:55:11 +0000 (UTC) Received: by oigd21 with SMTP id d21so19395894oig.1 for ; Thu, 16 Jul 2015 17:55:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jEEMNEdVorV78IgEvbe7sGCFJxBziVTip5wgjwZghjw=; b=jrNFk1ebfjMhdYWQVVNdA6e/31HRzYfjQQFz2ikiNpu1AlMcMgItTcJLwQ7/A28dBM v8GYLQ3/avIt/j6sp0JfkItL8ZekmKX6oSmIPQaBB+7lmQqLrRgxiTDqEWY4QooAmigs o4LSJUTlJGpl9d0fY/RdooiRWTmXu9mIxooqNJ18S+89tqJ5Kee0X4d6UwizjF+tpFyh sb87AOzAPI5C7Dysu1uY4JYsdd/dAck6w+wBQAW4Z9e35FlDwpl/Y69aKVVZJKoIwZ20 s+SXWEUPnLNxn+oJRqBqfxkpLTQQ6JMQ2tT/zNVjGohwSXeasvzugJTO/kucuana9AYK csFQ== X-Gm-Message-State: ALoCoQnE1B7FO0ZsAb23zFIGFNVazWRxsIYkOQBudHT4k+sS4a7CLlCWZPTmPAqM766injW2xyeX MIME-Version: 1.0 X-Received: by 10.182.24.40 with SMTP id r8mr11720513obf.15.1437094510852; Thu, 16 Jul 2015 17:55:10 -0700 (PDT) Received: by 10.202.221.66 with HTTP; Thu, 16 Jul 2015 17:55:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jul 2015 17:55:10 -0700 Message-ID: From: Justin Newton To: Riccardo Spagni Content-Type: multipart/alternative; boundary=001a11c29f1ad41343051b07a334 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 00:55:12 -0000 --001a11c29f1ad41343051b07a334 Content-Type: text/plain; charset=UTF-8 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 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] --001a11c29f1ad41343051b07a334 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am breaking this into a couple of pieces as my first res= ponse 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.=C2=A0 We want to work with the community, as we have been = from the beginning, to come up with the best standard possible. =C2=A0
<= /div>

Longer answers inline below.

<= br>

On Tue, Jul 14, 2015 at 12:07 PM, Ricc= ardo Spagni=C2=A0<ric@spagni.net>=C2=A0wrote:


In terms of comparisons to OpenAlias, I think there are a lot of
si= milarities, but a few differences.=C2=A0 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.=C2=A0 I understand why you chose to, but we were<= br>concerned about broad interoperability and easy broad distribution ofhosting, so decided not to use it.=C2=A0 We have other ways of achievingprivacy, using HD Wallets and Payment Requests.

=
And this is the part where you guys look really, really incompet= ent (and I don't mean that in a terribly demeaning way, it's just t= hat you're in a space where you want to be a domain expert, not make a = series of embarrassing and public faux pas).


<= /div>
I apprec= iate the thought :) =C2=A0I think where we differ is on where we believe th= e trade offs should be on perceived privacy versus censorship resistance an= d centralization. =C2=A0


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 o= f actors for an authority or hacker to go to in order to be able to install= /force logging, or censorship.=C2=A0 This very centralization forces us bac= k to a model where we need to trust a very small number of actors in order = for the system to operate as designed.=C2=A0 This, to me, appears to be the= opposite of the goals of the bitcoin ecosystem.=C2=A0 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 or= der to gain global visibility into all queries, I believe, breaks any perce= ived privacy gains from using DNSCrypt.=C2=A0 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 forci= ng everyone else through a handful of centralized servers.=C2=A0 Or they ca= n use DNSCrypt optionally themselves.=C2=A0 All of our tools have always be= en open source and folks can modify them for their own desired uses, or sub= mit pull requests with their own ideas.

We'd l= ove to hear others thoughts on this.=C2=A0 While I believe that for now the= centralization trade offs required to use DNSCrypt today (via a limited nu= mber of proxies) outweigh any perceived privacy benefits it provides, we ar= e always open to what others in the community believe and have made modific= ations to how things work before as a result of feedback from industry part= icipants.



=C2=A0
=C2=A0
2> We have the option of storing a URL rather than just a wallet<= span class=3D"im">
address in the TXT record.=C2=A0 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.= =C2=A0 Using Wallet
Names with Payment Requests allows for the user expe= rience of typing
in an easy to remember name and getting back the "= green lock" and who
the validated recipient is.=C2=A0 This also pro= vides an auto audit of the
end to end DNS SEC process, in the case the p= ath were somehow
compromised, the signature on the payment request can p= rovide 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 re= quires the trusting of multiple CAs, which is an inherent weakness.

= I think DANE is a great idea.=C2=A0 We were just discussing that with Andre= as 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 se= rvices like Cloudflare, Akamai, etc for their DNS, which many providers in = the space today are. =C2=A0

Of course, the securit= y conscious could setup DANE on the URL we use AS IS.=C2=A0 There is no nee= d to create a special kv pair for this as is done in OpenAlias.=C2=A0 As yo= u know, DNSSEC and HTTPS support this today out of the box.

<= /div>
The CA validation, in our case, is an ADDITIONAL signature based = validation to the DNSSEC chain, not a replacement for it. =C2=A0


=C2=A0[CONTINUED]

--001a11c29f1ad41343051b07a334--