path: root/bf/4fd1c332722ba0d403cc988bc9110c3ac888ec

Return-Path: <ric@spagni.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9623C9FB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 16:18:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vn0-f47.google.com (mail-vn0-f47.google.com
	[209.85.216.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9530C162
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 16:18:34 +0000 (UTC)
Received: by vnav203 with SMTP id v203so8568000vna.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 09:18:33 -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:from:date:message-id:subject:to
	:content-type;
	bh=oKQHOWY+r15EojlEvXER9k6FL40IUuDFxBymA3C/jiE=;
	b=SsJ1cve+/fqlDE2CTBiEpG2VY7+jgKeFhpcGmPVoro2gmlhWc59d7TxpQ3t6YRBKs/
	M87XVet4XwdsSAhVpYPa+6368iLsN7T82RhxY/zA6DzcvMsbTX/jfwDSzgvEaLTo4bWC
	sUT/u2VbN6oPOinmfSOXudNLVYomaN4MieFrC0dIwEnp1NN/s6vWcbOgNg/T+uCZF5bi
	o/LW7aGcyMfZlDWHRO9gVDYFPea3ShCWpD26lI7NtNOiyDzr9Y3mJbcQ8RqqN7EX+irl
	39fxTwNjaI9er7Tm2huLZNBqklvZIflbakozEozVlOCvWs1knVB54KdhOYBmZwVaLAPo
	tkug==
X-Gm-Message-State: ALoCoQkjZxmIN2C6ORjR1hmXgxIu4W4U+Nal6VkOBHjjWj+QbbUpYzE3sYFdPnx1T3jgYfxBen1S
X-Received: by 10.52.72.84 with SMTP id b20mr11290129vdv.6.1437063513478; Thu,
	16 Jul 2015 09:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.92.197 with HTTP; Thu, 16 Jul 2015 09:18:13 -0700 (PDT)
From: Riccardo Spagni <ric@spagni.net>
Message-ID: <CADhj2oSbRuSqZCEWdfaOFebnYAcYB5S7dkatyaeFtuqHdyCU_Q@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=0023544478f33dad48051b006cf1
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	LOTS_OF_MONEY,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
X-Mailman-Approved-At: Mon, 03 Aug 2015 21:05:42 +0000
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>
Date: Thu, 16 Jul 2015 16:18:37 -0000
X-Original-Date: Thu, 16 Jul 2015 18:18:13 +0200
X-List-Received-Date: Thu, 16 Jul 2015 16:18:37 -0000

--0023544478f33dad48051b006cf1
Content-Type: text/plain; charset=UTF-8

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

You're misstating (or not understanding) the attack surface.

State-level attackers won't compromise 50+ DNSCrypt servers, they can get
the information on lookups a lot more trivially. Censorship resistance and
protection from state-level attackers comes from the decentralised side of
OpenAlias (ie. Namecoin resolution, preferably done using a local copy of
the NMC blockchain). Since Netki supports Namecoin resolution too there is
no need to worry about protecting end users from that.

There is, however, a need to protect users from man-in-the-middle attacks
where the data is not modified en-route, but it is sniffed. Who you pay in
a financial transaction is, and should be, privileged information between
yourself and that person. By encouraging open DNS lookups you're
effectively hanging that information out for all to see.

It is true that there are only 4 DNSCrypt servers we are comfortable
recommending. It is also true that there were, at one stage, only 4
Electrum servers. There were also only 4 Bitcoin nodes. As something grows
and becomes more useful and usable the number of voluntary participants
becomes much greater, and we will provide the necessary tools to enable
these volunteers.

So in a world where tens of thousands of Bitcoiners are using an aliasing
standard (which, in and of itself, is a convenience service anyway), and
hundreds of individuals and companies are hosting DNSCrypt resolvers, is it
even a valid argument to harp on the number of "proxies"? Thus it is not
worth talking about today. It is definitely worth discussing in future if
the number of DNSCrypt resolvers doesn't increase, but that is a different
discussion for a different time.


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

Everyone should be highly privacy conscious when it comes to financial
transactions, and it would be unconscionable of both you and I not to
defend end-user privacy.

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

It's important to remember that the "paranoid" won't use an aliasing
service, or at best will use a local Namecoin blockchain for that purpose.
This is a convenience service to provide general and broad appeal for the
non-technical, and those are the very people that need to be protected from
nosey neighbours / workmates / ISPs. Privacy is not only (or even at all)
about protecting people buying drugs on a darknet market, it is about
defending personal liberties.

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

Embedding the TLSA record in a KV pair just means that pinning takes one
less step.


> The CA validation, in our case, is an ADDITIONAL signature based
> validation to the DNSSEC chain, not a replacement for it.
>

Without DANE it's a weakness. It's trusting an additional CA (over and
above the domain owner), when we know that this is - and has been - an
issue in the past. Were it not an issue DANE (or certificate pinning in
general) would not have to exist.


> We looked at doing this in a single lookup as you did.  With one or two
> currencies this can be potentially more efficient.  As the number of
> supported currencies and addresses under a single name grows, however, this
> solution becomes potentially more problematic.  Please follow the use cases
> below:
>

(snipped quote for brevity)

Many currencies and colored coin addresses are supported under the same
> name, lets say 100.  When you count different currencies and colored coin
> types, it could easily be hundreds, or over a thousand.
>

Coinmarketcap lists 643 currencies and assets, of which only 131 have had
more than $500 in trade volume in the last 24 hours (and only 8 have done
over $100 000 in volume). ShapeShift only lists 44 of those. I seriously
doubt that a convenience service such as aliasing will find great use
amongst every fly-by-night scamcoin that crops up, but that is an aside.

While you may end doing "less lookups" under Open Alias, as it scales, you
> end up causing a significant amount of extra, unnecessary traffic.
>

"Scale" is a misnomer. Someone trying to collect every single active
cryptocurrency and house them all under a single sub-domain is an outlier,
not a problem to be faced at scale. I do not think we will see a large
scale movement to "collect" all the various cryptocurrency tokens, no
matter how worthless they are, and then subsequently setup aliases for them.


> In addition to the obvious impact of being orders of magnitude more
> wasteful than necessary, it also creates privacy "leakage" by returning
> someone 100 different addresses when they only asked for one.
>

I'm not sure how this is any greater leakage than 100 individual requests
for the openly accessible data, especially since it would be encrypted if
made via DNSCrypt?


> Finally, because a single packet UDP transaction for a DNS lookup can
> create possibly hundreds of packets in response, the service can
> essentially become an amplifier for DDoS attacks.  (If I spoof the source
> address of my target with a query to a lookup that issues hundreds of
> packets in response to one packet, and I can have a real impact :( )
>

Naughty naughty, you're doing that thing again where you're using a
smattering of expertise to appear knowledgeable about a subject.

So let's hypothetically say that an individual was crazy enough to have all
643 of the Coinmarketcap currencies/assets aliased on a single sub-domain.
The OpenAlias example of a Monero address (with a recipient name) is 157
bytes long, due to there being two public keys serialised in the address,
plus the ~12 bytes of overhead per RR (the DNS wire format uses label
compression, so the FQDN wouldn't be repeated for each returned record).
Let's call it 170 bytes. That makes the returned data just over 100kb.

Now let's first address a couple of things, assuming that someone would be
nuts enough to do this:

1. This is way larger than the UDP packet maximum, and this would never
come back as a "regular" ol' DNS request (512 bytes max). This may seem
bad, until you consider that DNSSEC responses are almost assured to exceed
512 bytes (eg. an NXDOMAIN with NSEC3). The size of the response is big,
but that's hardly something to write home about.

2. If the DNS server supports RFC2671 (EDNS) then it would try and send it
via UDP, and as long as the client says it can receive such a huge response
over UDP it'll come over the wire.

3. However, because RFC2671 can result in a DNS amplification attack, it's
been obsoleted by RFC6891 (EDNS0), which is pretty much ubiquitous for all
resolvers that support DNSSEC (because of the very large DNSSEC responses,
and the fact that DNSSEC resolvers want to avoid participation in an
amplification attack). EDNS0 mitigates amplification attacks.

4. In the event that an EDNS0 response fails (eg. the client says it can't
accept anything over, say, 4kb, which is quite common) then there's an
automatic and silent switch to DNS-over-TCP (RFC5966). DNS-over-TCP uses
TFO (TCP Fast Open) to do an extremely fast handshake and passing a cookie
to the client in the SYN-ACK, which can then be used for subsequent
requests, but data is still carried in the SYN. TFO mitigates amplification
attacks.

You can't both be overly concerned about amplification attacks *and* use
DNSSEC, which necessitates large records. And, at any rate, the issue with
amplification attacks *isn't* the size of the records (there are tons of
records just under 4kb, like an ANY request against isc.org, that are far
better suited to amplification attacks), it is the number of recursive open
resolvers. There is improvement in this space, though, and many open
recursive resolvers have been fixed in recent years.

It is important to note, that ICANN has "required" for some years that
> registrars and registries support DNSSEC on the domains they register.  I
> personally believe we shouldn't delay use of DNSSEC until their registries
> had come up to current required Internet standards.  (Here are ICANN's
> registrar requirements showing the DNSSEC requirement, btw:
> https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#operation
> )
>

Doesn't really matter what they require as long as there are zones that
remain unsigned. Plus it's not like new .za / .sg / .to registrations
magically get DNSSEC, they're also out of luck.


> That said, what do others in the industry think?  We are basing our
> current standard on our believed best practices, and defaulted to "first,
> lose no money", given the irreversibility of bitcoin.
>

Oh, ok. "First, lose no money, but it's ok if your ISP / neighbour /
colleague reports you to the cops because you sent a donation somewhere you
shouldn't."


> I think "DNSSEC is hard" is a bit of a boogey man that's not really true.
> We are working on developing registrar by registrar instructions of how to
> do this, and we have typically found that if you are setting up DNS by
> yourself, adding DNSSEC doesn't take a lot of additional time, maybe an
> hour or so depending on your registrar.
>

Adding the DS record to a domain is trivial, but to use DNSSEC with Gandi
or GoDaddy (if you don't have their PremiumDNS product) you have to host
your own DNS server. Sorry, but that is a non-trivial task. Even worse: you
need to secure your private KSK and not keep it on the server, and if
Bitcoiners are anything to go by this won't happen.

Oh, and incidentally, ENOM/Namecheap doesn't have DNSSEC support yet.

You're literally layering complexity on top of a convenience service, and
to what end?

This known concern, however, is why when we launched our product (based on
> our standard record formats) that we wanted to launch it with a variety of
> options for people.
>

That's completely, 100% centralised. You're creating decentralisation
theatre by providing "options" that no ordinary person will use.

That's some interesting data, and runs counter to the research of the IETF
> DNS working group.  If you are willing to share your data, I can put you in
> touch with the appropriate folks there to share your research.  I'd also
> love to see it!
>

I doubt that very much. See:
http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=30

As can be seen, only ~14% of all DNS queries request DNSSEC validation.
That's very far from ubiquitous, and completely matches what Thomas and I
found in Berlin. Unsurprisingly, this stat is particularly bad given that
it also shows that ~15% of all queries are being handled by Google's Public
DNS, without which the stat would be much lower.

I'd argue that we aren't locking "huge portions" of the Internet.  You are
> correct that about 15% of TLD's are not yet signed, even though they were
> required to be by ICANN.
>

Fine, so we're just cutting Africa out, then?
http://www.internetsociety.org/deploy360/wp-content/uploads/2015/06/cctlddnssec-2015-06-19.pdf

Even beyond that, ICANN's page listing DNSSEC-capable registrars (last
updated December 2014) only lists only a handful:
https://www.icann.org/resources/pages/deployment-2012-02-25-en

As I said above, I believe the requirement to not lose money and the fact
> that other options are available for those running on TLD's that are out of
> compliance, is worth the trade off that some existing names won't work
> until their TLD's come into compliance with current Internet standards.
>

A soft fail doesn't magically let the money go. It warns users of the risk
and asks them to verify the address by site. This could even be built out
so that higher value transactions (say, anything over $1000) hard fails in
the absence of DNSSEC, and anything particularly high value (say, anything
over $50 000) refuses to use an alias at all and requires an actual
cryptocurrency address.

I'm a little confused by these closing statements.  Our system has, from
> the beginning been open in terms of the fact that anyone could both serve
> names or do lookups without ever touching our servers, talking to us, or us
> even knowing that they did it or that they even exist.  Our system has
> NEVER been one where folks were required to use us for any portion of the
> service, and from our first beta product launch our open source tools did
> all lookups against DNS records and the blockchain, never any proprietary
> servers or interfaces on our side.
>

Now you're just trolling.

https://github.com/bitpay/copay/pull/2431/files

Which has this lovely line in it:
https://github.com/wdawg33/copay/blob/be6c3e80ab7601d245b186f7802d7050992eb1f0/config.js#L98

So you provide an open standard that uses DNS...but then you wanted to
force CoPay users to use your centralised API?

I'd love to know where you got information that we were in some way a
> closed and centralized system so that we can have an opportunity to clarify
> that misconception.
>

In December 2014 your website had no "developer" section (curl -s
https://web.archive.org/web/20141221141023/https://netki.com/ | grep
"Developers")

The first time that section got scraped was the end of April:
https://web.archive.org/web/20150428231016/https://www.netki.com/partials/developers.html

Even in its current form your website makes no mention of alternatives or
options for those wishing to secure an alias. End users are undoubtedly
left with the distinct impression that they can only get one by paying you.

Riccardo

PS. your mail won't go to the list if you CC the list address, you may want
to resend it

>

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<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-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"font-=
size:13px"><div class=3D"gmail_quote"><div>I appreciate the thought :) =C2=
=A0I think where we differ is on where we believe the trade offs should be =
on perceived privacy versus censorship resistance and centralization. =C2=
=A0</div><div><br></div><div><br></div><div>By having a limited number of p=
roxies people need to go through to easily implement, be it the 4 you recom=
mend, or 53, you actually have a very limited number of actors for an autho=
rity or hacker to go to in order to be able to install/force logging, or ce=
nsorship.=C2=A0 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 ope=
rate as designed.=C2=A0 This, to me, appears to be the opposite of the goal=
s 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 order to gain global vi=
sibility into all queries, I believe, breaks any perceived privacy gains fr=
om using DNSCrypt.=C2=A0 A very small number of hacks or subpoenas and ever=
yone&#39;s records are fair game in one place.</div></div></div></div></blo=
ckquote><div><br></div><div>You&#39;re misstating (or not understanding) th=
e attack surface.</div><div><br></div><div>State-level attackers won&#39;t =
compromise 50+ DNSCrypt servers, they can get the information on lookups a =
lot more trivially. Censorship resistance and protection from state-level a=
ttackers comes from the decentralised side of OpenAlias (ie. Namecoin resol=
ution, preferably done using a local copy of the NMC blockchain). Since Net=
ki supports Namecoin resolution too there is no need to worry about protect=
ing end users from that.</div><div><br></div><div>There is, however, a need=
 to protect users from man-in-the-middle attacks where the data is not modi=
fied en-route, but it is sniffed. Who you pay in a financial transaction is=
, and should be, privileged information between yourself and that person. B=
y encouraging open DNS lookups you&#39;re effectively hanging that informat=
ion out for all to see.</div><div><br></div><div>It is true that there are =
only 4 DNSCrypt servers we are comfortable recommending. It is also true th=
at there were, at one stage, only 4 Electrum servers. There were also only =
4 Bitcoin nodes. As something grows and becomes more useful and usable the =
number of voluntary participants becomes much greater, and we will provide =
the necessary tools to enable these volunteers.</div><div><br></div><div>So=
 in a world where tens of thousands of Bitcoiners are using an aliasing sta=
ndard (which, in and of itself, is a convenience service anyway), and hundr=
eds of individuals and companies are hosting DNSCrypt resolvers, is it even=
 a valid argument to harp on the number of &quot;proxies&quot;? Thus it is =
not worth talking about today. It is definitely worth discussing in future =
if the number of DNSCrypt resolvers doesn&#39;t increase, but that is a dif=
ferent discussion for a different time.</div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"font-size:13px=
"><div class=3D"gmail_quote"><div>For the highly privacy conscious they can=
, today do their DNS lookups over a non logging VPN connection without forc=
ing everyone else through a handful of centralized servers.=C2=A0 Or they c=
an use DNSCrypt optionally themselves.=C2=A0 All of our tools have always b=
een open source and folks can modify them for their own desired uses, or su=
bmit pull requests with their own ideas.</div></div></div></div></blockquot=
e><div><br></div><div>Everyone should be highly privacy conscious when it c=
omes to financial transactions, and it would be unconscionable of both you =
and I not to defend end-user privacy.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"font-size:13px"><div c=
lass=3D"gmail_quote"><div>We&#39;d love 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 number of proxies) outweigh any perceived=
 privacy benefits it provides, we are always open to what others in the com=
munity believe and have made modifications to how things work before as a r=
esult of feedback from industry participants.</div></div></div></div></bloc=
kquote><div><br></div><div>It&#39;s important to remember that the &quot;pa=
ranoid&quot; won&#39;t use an aliasing service, or at best will use a local=
 Namecoin blockchain for that purpose. This is a convenience service to pro=
vide general and broad appeal for the non-technical, and those are the very=
 people that need to be protected from nosey neighbours / workmates / ISPs.=
 Privacy is not only (or even at all) about protecting people buying drugs =
on a darknet market, it is about defending personal liberties.</div><div><b=
r></div><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-style=
:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=
=3D"font-size:13px"><div class=3D"gmail_quote"><div>I think DANE is a great=
 idea.=C2=A0 We were just discussing that with Andreas S., and are currentl=
y looking at whether we want to add this as optional versus mandatory, base=
d 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. =
=C2=A0</div><div><br></div><div>Of course, the security conscious could set=
up DANE on the URL we use AS IS.=C2=A0 There is no need to create a special=
 kv pair for this as is done in OpenAlias.=C2=A0 As you know, DNSSEC and HT=
TPS support this today out of the box.</div></div></div></div></blockquote>=
<div><br></div><div>Embedding the TLSA record in a KV pair just means that =
pinning takes one less step.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr"><div class=3D"gmail_extra" style=3D"font-size:13px"><div class=3D=
"gmail_quote"><div>The CA validation, in our case, is an ADDITIONAL signatu=
re based validation to the DNSSEC chain, not a replacement for it.</div></d=
iv></div></div></blockquote><div><br></div><div>Without DANE it&#39;s a wea=
kness. It&#39;s trusting an additional CA (over and above the domain owner)=
, when we know that this is - and has been - an issue in the past. Were it =
not an issue DANE (or certificate pinning in general) would not have to exi=
st.</div><div>=C2=A0</div><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-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"g=
mail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"><span class=
=3D""><span><div></div></span></span><div>We looked at doing this in a sing=
le lookup as you did.=C2=A0 With one or two currencies this can be potentia=
lly more efficient.=C2=A0 As the number of supported currencies and address=
es under a single name grows, however, this solution becomes potentially mo=
re problematic.=C2=A0 Please follow the use cases below:</div></div></div><=
/div></blockquote><div><br></div><div>(snipped quote for brevity)</div><div=
><br></div><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-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" sty=
le=3D"font-size:13px"><div class=3D"gmail_quote"><div><div>Many currencies =
and colored coin addresses are supported under the same name, lets say 100.=
=C2=A0 When you count different currencies and colored coin types, it could=
 easily be hundreds, or over a thousand.</div></div></div></div></div></blo=
ckquote><div><br></div><div>Coinmarketcap lists 643 currencies and assets, =
of which only 131 have had more than $500 in trade volume in the last 24 ho=
urs (and only 8 have done over $100 000 in volume). ShapeShift only lists 4=
4 of those. I seriously doubt that a convenience service such as aliasing w=
ill find great use amongst every fly-by-night scamcoin that crops up, but t=
hat is an aside.</div><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote">=
<div>While you may end doing &quot;less lookups&quot; under Open Alias, as =
it scales, you end up causing a significant amount of extra, unnecessary tr=
affic. =C2=A0</div></div></div></div></blockquote><div><br></div><div>&quot=
;Scale&quot; is a misnomer. Someone trying to collect every single active c=
ryptocurrency and house them all under a single sub-domain is an outlier, n=
ot a problem to be faced at scale. I do not think we will see a large scale=
 movement to &quot;collect&quot; all the various cryptocurrency tokens, no =
matter how worthless they are, and then subsequently setup aliases for them=
.</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" style=3D"font-size:13px"><div class=3D"gmail_quote"><div>In addit=
ion to the obvious impact of being orders of magnitude more wasteful than n=
ecessary, it also creates privacy &quot;leakage&quot; by returning someone =
100 different addresses when they only asked for one. =C2=A0</div></div></d=
iv></div></blockquote><div><br></div><div>I&#39;m not sure how this is any =
greater leakage than 100 individual requests for the openly accessible data=
, especially since it would be encrypted if made via DNSCrypt?</div><div>=
=C2=A0</div><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"><div class=3D"gmail_extra" st=
yle=3D"font-size:13px"><div class=3D"gmail_quote"><div>Finally, because a s=
ingle packet UDP transaction for a DNS lookup can create possibly hundreds =
of packets in response, the service can essentially become an amplifier for=
 DDoS attacks. =C2=A0(If I spoof the source address of my target with a que=
ry to a lookup that issues hundreds of packets in response to one packet, a=
nd I can have a real impact :( )</div></div></div></div></blockquote><div><=
br></div><div><div>Naughty naughty, you&#39;re doing that thing again where=
 you&#39;re using a smattering of expertise to appear knowledgeable about a=
 subject.</div><div><br></div><div>So let&#39;s hypothetically say that an =
individual was crazy enough to have all 643 of the Coinmarketcap currencies=
/assets aliased on a single sub-domain. The OpenAlias example of a Monero a=
ddress (with a recipient name) is 157 bytes long, due to there being two pu=
blic keys serialised in the address, plus the ~12 bytes of overhead per RR =
(the DNS wire format uses label compression, so the FQDN wouldn&#39;t be re=
peated for each returned record). Let&#39;s call it 170 bytes. That makes t=
he returned data just over 100kb.<br></div><div><br></div><div>Now let&#39;=
s first address a couple of things, assuming that someone would be nuts eno=
ugh to do this:</div><div><br></div><div>1. This is way larger than the UDP=
 packet maximum, and this would never come back as a &quot;regular&quot; ol=
&#39; DNS request (512 bytes max). This may seem bad, until you consider th=
at DNSSEC responses are almost assured to exceed 512 bytes (eg. an NXDOMAIN=
 with NSEC3). The size of the response is big, but that&#39;s hardly someth=
ing to write home about.</div><div><br></div><div>2. If the DNS server supp=
orts RFC2671 (EDNS) then it would try and send it via UDP, and as long as t=
he client says it can receive such a huge response over UDP it&#39;ll come =
over the wire.</div><div><br></div><div>3. However, because RFC2671 can res=
ult in a DNS amplification attack, it&#39;s been obsoleted by RFC6891 (EDNS=
0), which is pretty much ubiquitous for all resolvers that support DNSSEC (=
because of the very large DNSSEC responses, and the fact that DNSSEC resolv=
ers want to avoid participation in an amplification attack). EDNS0 mitigate=
s amplification attacks.</div><div><br></div><div>4. In the event that an E=
DNS0 response fails (eg. the client says it can&#39;t accept anything over,=
 say, 4kb, which is quite common) then there&#39;s an automatic and silent =
switch to DNS-over-TCP (RFC5966). DNS-over-TCP uses TFO (TCP Fast Open) to =
do an extremely fast handshake and passing a cookie to the client in the SY=
N-ACK, which can then be used for subsequent requests, but data is still ca=
rried in the SYN. TFO mitigates amplification attacks.</div><div><br></div>=
<div>You can&#39;t both be overly concerned about amplification attacks *an=
d* use DNSSEC, which necessitates large records. And, at any rate, the issu=
e with amplification attacks *isn&#39;t* the size of the records (there are=
 tons of records just under 4kb, like an ANY request against <a href=3D"htt=
p://isc.org">isc.org</a>, that are far better suited to amplification attac=
ks), it is the number of recursive open resolvers. There is improvement in =
this space, though, and many open recursive resolvers have been fixed in re=
cent years.</div></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"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 dir=3D"ltr"><di=
v class=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"=
><div>It is important to note, that ICANN has &quot;required&quot; for some=
 years that registrars and registries support DNSSEC on the domains they re=
gister.=C2=A0 I personally believe we shouldn&#39;t delay use of DNSSEC unt=
il their registries had come up to current required Internet standards. =C2=
=A0(Here are ICANN&#39;s registrar requirements showing the DNSSEC requirem=
ent, btw:=C2=A0<a href=3D"https://www.icann.org/resources/pages/approved-wi=
th-specs-2013-09-17-en#operation" target=3D"_blank">https://www.icann.org/r=
esources/pages/approved-with-specs-2013-09-17-en#operation</a>)</div></div>=
</div></div></blockquote><div><br></div><div>Doesn&#39;t really matter what=
 they require as long as there are zones that remain unsigned. Plus it&#39;=
s not like new .za / .sg / .to registrations magically get DNSSEC, they&#39=
;re also out of luck.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-colo=
r:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"lt=
r"><div class=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_=
quote"><div>That said, what do others in the industry think?=C2=A0 We are b=
asing our current standard on our believed best practices, and defaulted to=
 &quot;first, lose no money&quot;, given the irreversibility of bitcoin.=C2=
=A0</div></div></div></div></blockquote><div><br></div><div>Oh, ok. &quot;F=
irst, lose no money, but it&#39;s ok if your ISP / neighbour / colleague re=
ports you to the cops because you sent a donation somewhere you shouldn&#39=
;t.&quot;</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"><div>=
I think &quot;DNSSEC is hard&quot; is a bit of a boogey man that&#39;s not =
really true.=C2=A0 We are working on developing registrar by registrar inst=
ructions of how to do this, and we have typically found that if you are set=
ting up DNS by yourself, adding DNSSEC doesn&#39;t take a lot of additional=
 time, maybe an hour or so depending on your registrar.=C2=A0</div></div></=
div></div></blockquote><div><br></div><div>Adding the DS record to a domain=
 is trivial, but to use DNSSEC with Gandi or GoDaddy (if you don&#39;t have=
 their PremiumDNS product) you have to host your own DNS server. Sorry, but=
 that is a non-trivial task. Even worse: you need to secure your private KS=
K and not keep it on the server, and if Bitcoiners are anything to go by th=
is won&#39;t happen.</div><div><br></div><div>Oh, and incidentally, ENOM/Na=
mecheap doesn&#39;t have DNSSEC support yet.</div><div><br></div><div>You&#=
39;re literally layering complexity on top of a convenience service, and to=
 what end?</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"><div>T=
his known concern, however, is why when we launched our product (based on o=
ur standard record formats) that we wanted to launch it with a variety of o=
ptions for people. =C2=A0</div></div></div></div></blockquote><div><br></di=
v><div>That&#39;s completely, 100% centralised. You&#39;re creating decentr=
alisation theatre by providing &quot;options&quot; that no ordinary person =
will use.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"><div>T=
hat&#39;s some interesting data, and runs counter to the research of the IE=
TF DNS working group.=C2=A0 If you are willing to share your data, I can pu=
t you in touch with the appropriate folks there to share your research.=C2=
=A0 I&#39;d also love to see it!</div></div></div></div></blockquote><div><=
br></div><div>I doubt that very much. See: <a href=3D"http://stats.labs.apn=
ic.net/dnssec/XA?c=3DXA&amp;x=3D1&amp;g=3D1&amp;r=3D1&amp;w=3D30">http://st=
ats.labs.apnic.net/dnssec/XA?c=3DXA&amp;x=3D1&amp;g=3D1&amp;r=3D1&amp;w=3D3=
0</a></div><div><br></div><div>As can be seen, only ~14% of all DNS queries=
 request DNSSEC validation. That&#39;s very far from ubiquitous, and comple=
tely matches what Thomas and I found in Berlin. Unsurprisingly, this stat i=
s particularly bad given that it also shows that ~15% of all queries are be=
ing handled by Google&#39;s Public DNS, without which the stat would be muc=
h lower.</div><div><br></div><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"><div dir=3D"ltr"><div class=
=3D"gmail_extra" style=3D"font-size:13px"><div class=3D"gmail_quote"><div>I=
&#39;d argue that we aren&#39;t locking &quot;huge portions&quot; of the In=
ternet.=C2=A0 You are correct that about 15% of TLD&#39;s are not yet signe=
d, even though they were required to be by ICANN.</div></div></div></div></=
blockquote><div><br></div><div>Fine, so we&#39;re just cutting Africa out, =
then? <a href=3D"http://www.internetsociety.org/deploy360/wp-content/upload=
s/2015/06/cctlddnssec-2015-06-19.pdf">http://www.internetsociety.org/deploy=
360/wp-content/uploads/2015/06/cctlddnssec-2015-06-19.pdf</a></div><div><br=
></div><div>Even beyond that, ICANN&#39;s page listing DNSSEC-capable regis=
trars (last updated December 2014) only lists only a handful:=C2=A0<a href=
=3D"https://www.icann.org/resources/pages/deployment-2012-02-25-en">https:/=
/www.icann.org/resources/pages/deployment-2012-02-25-en</a></div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"=
font-size:13px"><div class=3D"gmail_quote"><div>As I said above, I believe =
the requirement to not lose money and the fact that other options are avail=
able for those running on TLD&#39;s that are out of compliance, is worth th=
e trade off that some existing names won&#39;t work until their TLD&#39;s c=
ome into compliance with current Internet standards.</div></div></div></div=
></blockquote><div><br></div><div>A soft fail doesn&#39;t magically let the=
 money go. It warns users of the risk and asks them to verify the address b=
y site. This could even be built out so that higher value transactions (say=
, anything over $1000) hard fails in the absence of DNSSEC, and anything pa=
rticularly high value (say, anything over $50 000) refuses to use an alias =
at all and requires an actual cryptocurrency address.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"font-s=
ize:13px"><div class=3D"gmail_quote"><div>I&#39;m a little confused by thes=
e closing statements.=C2=A0 Our system has, from the beginning been open in=
 terms of the fact that anyone could both serve names or do lookups without=
 ever touching our servers, talking to us, or us even knowing that they did=
 it or that they even exist.=C2=A0 Our system has NEVER been one where folk=
s were required to use us for any portion of the service, and from our firs=
t beta product launch our open source tools did all lookups against DNS rec=
ords and the blockchain, never any proprietary servers or interfaces on our=
 side. =C2=A0</div></div></div></div></blockquote><div><br></div><div>Now y=
ou&#39;re just trolling.</div><div><br></div><div><a href=3D"https://github=
.com/bitpay/copay/pull/2431/files">https://github.com/bitpay/copay/pull/243=
1/files</a><br></div><div><br></div><div>Which has this lovely line in it: =
<a href=3D"https://github.com/wdawg33/copay/blob/be6c3e80ab7601d245b186f780=
2d7050992eb1f0/config.js#L98">https://github.com/wdawg33/copay/blob/be6c3e8=
0ab7601d245b186f7802d7050992eb1f0/config.js#L98</a><br></div><div><br></div=
><div>So you provide an open standard that uses DNS...but then you wanted t=
o force CoPay users to use your centralised API?</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra" style=3D"font-size:1=
3px"><div class=3D"gmail_quote"><div>I&#39;d love to know where you got inf=
ormation that we were in some way a closed and centralized system so that w=
e can have an opportunity to clarify that misconception. =C2=A0<br></div></=
div></div></div></blockquote><div><br></div><div>In December 2014 your webs=
ite had no &quot;developer&quot; section (curl -s <a href=3D"https://web.ar=
chive.org/web/20141221141023/https://netki.com/">https://web.archive.org/we=
b/20141221141023/https://netki.com/</a> | grep &quot;Developers&quot;)</div=
><div><br></div><div>The first time that section got scraped was the end of=
 April:=C2=A0<a href=3D"https://web.archive.org/web/20150428231016/https://=
www.netki.com/partials/developers.html">https://web.archive.org/web/2015042=
8231016/https://www.netki.com/partials/developers.html</a></div><div><br></=
div><div>Even in its current form your website makes no mention of alternat=
ives or options for those wishing to secure an alias. End users are undoubt=
edly left with the distinct impression that they can only get one by paying=
 you.</div><div><br></div><div>Riccardo</div><div><br></div><div>PS. your m=
ail won&#39;t go to the list if you CC the list address, you may want to re=
send it</div><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-=
style:solid;padding-left:1ex">
</blockquote></div></div></div>

--0023544478f33dad48051b006cf1--