path: root/55/552850e6aa1abb91a74daa82cf895ddd02b6d5

Return-Path: <justin@netki.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5FDD6BA1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 00:55:11 +0000 (UTC)
Received: by oigd21 with SMTP id d21so19395894oig.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
References: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
Date: Thu, 16 Jul 2015 17:55:10 -0700
Message-ID: <CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
From: Justin Newton <justin@netki.com>
To: Riccardo Spagni <ric@spagni.net>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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]

--001a11c29f1ad41343051b07a334
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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.<d=
iv><br></div><div><br></div><div><span class=3D"im" style=3D"font-size:13px=
"><div>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<br><=
/div><div><br></div><div>Longer answers inline below.</div><div><br></div><=
br></span><div class=3D"gmail_extra" style=3D"font-size:13px"><br><div clas=
s=3D"gmail_quote"><span class=3D"im">On Tue, Jul 14, 2015 at 12:07 PM, Ricc=
ardo Spagni=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:ric@spagni.net" ta=
rget=3D"_blank">ric@spagni.net</a>&gt;</span>=C2=A0wrote:<br></span><span c=
lass=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2=
04);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">In terms of comparisons to OpenAlias, I think there are a lot of<br>si=
milarities, but a few differences.=C2=A0 First the similarities:<br><br><br=
>1&gt; We both use DNSSEC.<br><br>2&gt; We both have the option of storing =
the address directly in the DNS record.<br><br><br>Differences:<br><br>1&gt=
; 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 of<br=
>hosting, so decided not to use it.=C2=A0 We have other ways of achieving<b=
r>privacy, using HD Wallets and Payment Requests.<br></blockquote><div><br>=
</div><div>And this is the part where you guys look really, really incompet=
ent (and I don&#39;t mean that in a terribly demeaning way, it&#39;s just t=
hat you&#39;re in a space where you want to be a domain expert, not make a =
series of embarrassing and public faux pas).</div><div><br></div><div><br><=
/div></div></div></div></blockquote></span><span class=3D"im"><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</div><div><br></div><div><br></div><div>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 &quot;proxies&quot; is a bad idea and counter to bitcoin&#39=
;s ideals.</div><div><br></div><div><br></div><div>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&#39;s records are fair game in one place.</div><d=
iv><br></div><div><br></div><div>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.</div><div><br></div><div>We&#39;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.</div></span><div><br></div><div><br></div><div><br></div><div><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex">2&gt; We have the option of storing a URL rather than just a wallet<=
span class=3D"im"><br>address in the TXT record.=C2=A0 This allows a second=
 level lookup against<br>the URL to get back a unique HD Wallet address or =
Payment Request each<br>time, further protecting user privacy and security.=
=C2=A0 Using Wallet<br>Names with Payment Requests allows for the user expe=
rience of typing<br>in an easy to remember name and getting back the &quot;=
green lock&quot; and who<br>the validated recipient is.=C2=A0 This also pro=
vides an auto audit of the<br>end to end DNS SEC process, in the case the p=
ath were somehow<br>compromised, the signature on the payment request can p=
rovide an<br>additional check.<br></span></blockquote><span class=3D"im"><d=
iv><br></div><div>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.</div></=
span></div></div></div></blockquote><div><br></div><span class=3D"im"><div>=
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</div><div><br></div><div>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><div><br><=
/div><div>The CA validation, in our case, is an ADDITIONAL signature based =
validation to the DNSSEC chain, not a replacement for it. =C2=A0</div></spa=
n><div><br></div><div><br></div><div>=C2=A0[CONTINUED]</div></div></div></d=
iv><div><br></div></div>

--001a11c29f1ad41343051b07a334--