path: root/c0/328683263646f89d43252b4eae21cd97fa2657

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 A25DEB8B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 00:58:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com
	[209.85.214.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1194A143
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 17 Jul 2015 00:58:08 +0000 (UTC)
Received: by obnw1 with SMTP id w1so57502930obn.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 16 Jul 2015 17:58:07 -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=dzdRsEGVT18w5XRtGx0zddTga57D6PYeQ+FTyX9jp8E=;
	b=I/3anlF0de/UvBBFFK2f1P+Wnvo9nqFA5yjOCqyue1Y1mAKAxF9zuSCYAPPR+zuyZ6
	YuxtgDOZsonoCTCc28wMYPohkHLcwXoQrfOzbPKgYMxFv/X9lH9wVA7v28oQQlq0hq/K
	mAIUcFn084rARj7cr2ooBO5Y4mZxp+AafF0NShdwx9fV/0MvccaIV8h3BH/4sYFU/MCC
	0J7L/RBq79nS1aIM5P0LcR2eYRYKc1iL3joXPu6nc3RNtP2eAbDMxpUX4/t3guxrJHUk
	+aLrGD0FWF9+gh0DSTK6gM/gTJMTYl+pt2Xs0y5F6SfaP+yaiLWyPoPH7CPkfpx+4RRZ
	9CUQ==
X-Gm-Message-State: ALoCoQkZrBI//ByjsKZ0/G1qAxKveU5FUasQIdOUn3n7hW1BohKr128okYMyK68JsPsNF6tIlRFf
MIME-Version: 1.0
X-Received: by 10.60.177.195 with SMTP id cs3mr11165448oec.37.1437094687427;
	Thu, 16 Jul 2015 17:58:07 -0700 (PDT)
Received: by 10.202.221.66 with HTTP; Thu, 16 Jul 2015 17:58:07 -0700 (PDT)
In-Reply-To: <CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
References: <CADhj2oT_rgaf6LFgwMawwJKaA8384v5jQ=e-7T8GNY4gGZ2udQ@mail.gmail.com>
	<CABqynxKf=xBOG_38LYqtps2jXWeOR3g4PVFm6AKbJKLndG3Tig@mail.gmail.com>
Message-ID: <CABqynx+pcmu0UTtcQ=R_C6TPmmrOn5h-FP180ODoanMaTYD--A@mail.gmail.com>
From: Justin Newton <justin@netki.com>
To: Riccardo Spagni <ric@spagni.net>
Content-Type: multipart/related; boundary=089e010d8f485aa5dc051b07ae0a
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
X-Mailman-Approved-At: Mon, 03 Aug 2015 21:05:42 +0000
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>
Date: Fri, 17 Jul 2015 00:58:10 -0000
X-Original-Date: Thu, 16 Jul 2015 17:58:07 -0700
X-List-Received-Date: Fri, 17 Jul 2015 00:58:10 -0000

--089e010d8f485aa5dc051b07ae0a
Content-Type: multipart/alternative; boundary=089e010d8f485aa5d9051b07ae09

--089e010d8f485aa5d9051b07ae09
Content-Type: text/plain; charset=UTF-8

[continued]



> 3> We use a 2 tier lookup format.  The first lookup returns a list of
>> currencies or payment types supported by the Wallet Name.  The second
>> lookup goes to a record specific to that currency type to get the
>> address to go to.  We believe this to be a more scalable solution in a
>> world where someone can have both multiple digital currency types, but
>> then also multiple types of colored coins, and wants a simple way to
>> share a single name for all of those different addresses.  This allows
>> the wallet to do the work behind the scene of choosing the currency it
>> wants to send, and automatically getting back the right address to
>> send to, without the user having to do anything different.
>>
>
> We do the same thing, except in a single call. Here's an example of a
> record that has both XMR and BTC addresses:
> https://api.openalias.org/donate.getmonero.org?view=full (here are the
> DNS records for that:
> http://mxtoolbox.com/SuperTool.aspx?action=txt%3adonate.getmonero.org&run=toolpage
> )
>


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:

Use case 1:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

The only currency supported is bitcoin, and there are no colored coin
formats supported.

OpenAlias case:

1 packet lookup to "bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 1a:

The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets

In this use case we might create more traffic, but it could also be reduced
by doing smart lookups.


Use case 2:  Wallet Name = "bob.foo.bar" or OpenAlias = "bob.foo.bar"

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.


OpenAlias case:

1 packet lookup to "bob.foo.bar"
100 packet responses with various addresses

= 101 packets


Wallet Name case:

1 packet lookup to "_wallet.bob.foo.bar"
1 packet response with supported address types
1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 4 packets

Wallet Name Case 2a:

The wallet doing the lookup knows it wants bitcoin, so it skips the
supported addresses lookup

1 packet lookup to "_btc._wallet.bob.foo.bar"
1 packet response with bitcoin address

= 2 packets


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

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.

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 :( )




>
>
>> 4> We mandate DNSSEC while you make it optional.  We did this because
>> we believe giving the user the option of NOT using DNSSEC is like
>> letting them order a car with no brakes.  We weren't sure how we would
>> explain to them why their money was gone when they really didn't
>> understand the risks they were taking up front. We had a lot of
>> discussion about it before coming to the decision we did, and I can
>> see why you went the other way, although I do believe we made the
>> right choice.
>>
>
> With OpenAlias a DNSSEC fail is a soft fail, and the user has to confirm
> the address. The reasons are threefold:
>
> 1. At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones
> include some biggies like .sg, .za, and .to
>

I think this is a good point, and one we weighed.  When we were making our
original decisions.  Given the importance of ensuring that the lookups
return the correct value, and the known vulnerabilities in DNS without
DNSSEC, coupled with the fact that ICANN has mandated all zones and
registries move to DNSSEC, our belief was and is that it was worth the
trade off that there were cases where existing domains would not work.


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
)

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.



> 2. Even if the zone *is* signed, DNSSEC deployment is hard. Unmanaged
> DNSSEC deployment is out of scope for probably 99.9% of users, even the
> usually-technically-ok Bitcoin crowd. Managed DNSSEC is available, but is
> quite pricey. UltraDNS, Dyn, and GoDaddy (ikr?) are the three big
> providers, and of those three only GoDaddy has a consumer-affordable
> product.
>


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.

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.

In addition to these options there are also other hosting providers, and
certain registrars that will allow you to setup DNSSEC on their DNS
platforms.


1> One could choose the "0 click" installation process of just getting a
free Wallet Name underneath their provider's name space.  This option has
been free to end users in all cases so far, and I expect it always will be
in the future (although that is up to the partner, so some may choose to
charge).

2> If they wanted some provider independence, but someone to manage things
for them, they can register a name through us and manage everything via our
web interface.  This can cost them as little as $1.95/yr through us.

3> Finally, for the "do it yourselfer" who wants full control themselves,
they can simply follow the formats on our developer page and do the whole
thing themselves.  If they do this by registering their own ".bit" this
will cost them less than $0.25.  If they have an existing domain name, even
less.






>
> 3. ThomasV and I have done a stack of testing behind residential and
> commercial routers where DNSSEC simply fails (eg. the router runs a really
> outdated DNS server that doesn't provide RRSIGs in its response, or the ISP
> doesn't care about DNSSEC). Unsurprisingly, this can be fixed by...you
> guessed it...doing the lookup via DNSCrypt.
>

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!



>
> Until we are closer to the bulk of all TLDs being signed, and DNSSEC
> becomes at least a little more ubiquitous, we can't lock out huge portions
> of the Internet, because then we're not really providing a useful and
> usable solution. All we can is make it more difficult to pay an unverified
> domain.
>
> Of course, if your aim is to force people to use you as a domain
> registrar, then it makes total sense why you'd lock people out;)
>

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.

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.

And, as we covered above, we don't force anyone to use our registrar, nor
any of our services in order for Wallet Names to work for them.  We never
have.  It's just not who we are.





>
> Additionally, we just released another open source API server to help
>> with the "other half" of the lookup problem.  Its in its infancy, and
>> we are certainly taking feedback on it at this time.  It is called
>> Addressimo <https://github.com/netkicorp/addressimo> and will serve
>> unique HD Wallet addresses or Payment Requests for every lookup, thus
>> allowing a user to have a private, secure way to share a Wallet Name
>> that can be used to send them any digital currency.
>>
>
> Oh snap...https://github.com/openalias/openalias-api
>

These are actually vastly different pieces of software, at least from the
description, and a first read of the code.  My understanding is the
software you linked to here basically takes the DNS work out of lookups for
people, as we released: https://github.com/netkicorp/wns-api-server  Its
our Wallet Name Lookup server.

Addressimo, as I described above, provides a different purpose.  Its a way
for service providers, mobile wallet providers or end users to have an
online server that can serve unique wallet addresses ala HD Wallets (BIP32)
or signed Payment Requests (BIP0070).  This allows for an easy way to
increase security and privacy by serving a unique address for every
request, and/or sign the address (and other optional data) with an X509
private key to prove ownership of the address in a way independent of and
supplemental to the DNSSEC chain (also can be DANE for yet another layer of
security).  It also supports offline signing of the Payment Requests so the
server doesn't have to have access to a private key, or need to be trusted.





>
>
> In any case, I'd much rather we had one effort going forward than
>> multiples, so let's talk!
>>
>
> I agree, and you guys are in an ideal position to change to supporting the
> OpenAlias standard (and enhancing it) without skipping a beat. We would
> definitely appreciate and take your input and efforts, and that would make
> OpenAlias v2 (oa2:) a standard built out in conjunction with Netki.
>
> Not only do you get Electrum support without lifting a finger, but it will
> go a long way to repairing your relationship with the open-source community
> at large, several proponents of which have taken great umbrage at what you
> were previously pushing as a closed-source, centralised system.
>
>
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.

In terms of the format itself being open, we have already made several
extensions and modifications to it as a result of conversations with
industry participants in order to ensure that what we are building meets
the needs of the community at large.  We will gladly continue to do so, it
is how we ensure we are building something everyone needs!

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 terms of finding a common standard, as I said, I am thrilled to have the
conversations, but there are some places, highlighted above, that would
cause me to hesitate to "just implement" the Open Alias standard.  I can
also see places where bringing the formats together to one standard could
have strong benefits, for example:

I think formatting the record as a key value pair with versioning has
merit, and would love to move it in to what we are doing (and likely will).

On the other side, I think the two level lookup provides a lot of value at
scale over trying to send back a bunch of text records when only a small
portion of the data is used.

I'd love to hear thoughts from others in the community on mandating DNSSEC
and thoughts on DNSCrypt.  I have a strong opinion on both of those but
would love to engage in thoughtful dialogue around what path best suits the
need of the community.


Looking forward to the discussion!

On Thu, Jul 16, 2015 at 5:55 PM, Justin Newton <justin@netki.com> wrote:

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


-- 

Justin W. Newton
Founder/CEO
NetKi, Inc.

justin@netki.com
+1.818.261.4248

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

<div dir=3D"ltr">[continued]<div><br></div><div><br></div><div><span style=
=3D"font-size:13px"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><div><br></div><span class=3D"im"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wid=
th:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-l=
eft:1ex">3&gt; We use a 2 tier lookup format.=C2=A0 The first lookup return=
s a list of<br>currencies or payment types supported by the Wallet Name.=C2=
=A0 The second<br>lookup goes to a record specific to that currency type to=
 get the<br>address to go to.=C2=A0 We believe this to be a more scalable s=
olution in a<br>world where someone can have both multiple digital currency=
 types, but<br>then also multiple types of colored coins, and wants a simpl=
e way to<br>share a single name for all of those different addresses.=C2=A0=
 This allows<br>the wallet to do the work behind the scene of choosing the =
currency it<br>wants to send, and automatically getting back the right addr=
ess to<br>send to, without the user having to do anything different.<br></b=
lockquote><div><br></div><div>We do the same thing, except in a single call=
. Here&#39;s an example of a record that has both XMR and BTC addresses:=C2=
=A0<a href=3D"https://api.openalias.org/donate.getmonero.org?view=3Dfull" t=
arget=3D"_blank">https://api.openalias.org/donate.getmonero.org?view=3Dfull=
</a>=C2=A0(here are the DNS records for that:=C2=A0<a href=3D"http://mxtool=
box.com/SuperTool.aspx?action=3Dtxt%3adonate.getmonero.org&amp;run=3Dtoolpa=
ge" target=3D"_blank">http://mxtoolbox.com/SuperTool.aspx?action=3Dtxt%3ado=
nate.getmonero.org&amp;run=3Dtoolpage</a>)</div></span></div></div></div></=
blockquote><div><br></div></span><div style=3D"font-size:13px"><div class=
=3D"adm"></div></div><span style=3D"font-size:13px"><div><br></div><div><di=
v><div class=3D"im"><div>We looked at doing this in a single lookup as you =
did.=C2=A0 With one or two currencies this can be potentially more efficien=
t.=C2=A0 As the number of supported currencies and addresses under a single=
 name grows, however, this solution becomes potentially more problematic.=
=C2=A0 Please follow the use cases below:</div><div><br></div><div>Use case=
 1: =C2=A0Wallet Name =3D &quot;bob.foo.bar&quot; or OpenAlias =3D &quot;bo=
b.foo.bar&quot;</div><div><br></div><div>The only currency supported is bit=
coin, and there are no colored coin formats supported.</div><div><br></div>=
<div>OpenAlias case:=C2=A0</div><div><br></div><div>1 packet lookup to &quo=
t;bob.foo.bar&quot;</div><div>1 packet response with bitcoin address</div><=
div><br></div><div>=3D 2 packets</div><div><br></div><div><br></div><div>Wa=
llet Name case:</div><div><br></div><div>1 packet lookup to &quot;_wallet.b=
ob.foo.bar&quot;</div><div>1 packet response with supported address types</=
div><div>1 packet lookup to &quot;_btc._wallet.bob.foo.bar&quot;</div><div>=
1 packet response with bitcoin address</div><div><br></div><div>=3D 4 packe=
ts</div><div><br></div><div>Wallet Name Case 1a:</div><div><br></div><div>T=
he wallet doing the lookup knows it wants bitcoin, so it skips the supporte=
d addresses lookup</div><div><br></div><div>1 packet lookup to &quot;_btc._=
wallet.bob.foo.bar&quot;</div><div>1 packet response with bitcoin address</=
div><div><br></div><div>=3D 2 packets</div><div><br></div><div>In this use =
case we might create more traffic, but it could also be reduced by doing sm=
art lookups.</div><div><br></div><div><br></div><div><div>Use case 2: =C2=
=A0Wallet Name =3D &quot;bob.foo.bar&quot; or OpenAlias =3D &quot;bob.foo.b=
ar&quot;</div><div><br></div><div>Many currencies and colored coin addresse=
s are supported under the same name, lets say 100.=C2=A0 When you count dif=
ferent currencies and colored coin types, it could easily be hundreds, or o=
ver a thousand.</div><div><br></div><div><br></div><div>OpenAlias case:=C2=
=A0</div><div><br></div><div>1 packet lookup to &quot;bob.foo.bar&quot;</di=
v><div>100 packet responses with various addresses</div><div><br></div><div=
>=3D 101 packets</div><div><br></div><div><br></div><div>Wallet Name case:<=
/div><div><br></div><div>1 packet lookup to &quot;_wallet.bob.foo.bar&quot;=
</div><div>1 packet response with supported address types</div><div>1 packe=
t lookup to &quot;_btc._wallet.bob.foo.bar&quot;</div><div>1 packet respons=
e with bitcoin address</div><div><br></div><div>=3D 4 packets</div><div><br=
></div><div><div>Wallet Name Case 2a:</div><div><br></div><div>The wallet d=
oing the lookup knows it wants bitcoin, so it skips the supported addresses=
 lookup</div><div><br></div><div>1 packet lookup to &quot;_btc._wallet.bob.=
foo.bar&quot;</div><div>1 packet response with bitcoin address</div><div><b=
r></div><div>=3D 2 packets</div></div></div><div><br></div><div><br></div><=
div>While you may end doing &quot;less lookups&quot; under Open Alias, as i=
t scales, you end up causing a significant amount of extra, unnecessary tra=
ffic. =C2=A0</div><div><br></div><div>In addition to the obvious impact of =
being orders of magnitude more wasteful than necessary, it also creates pri=
vacy &quot;leakage&quot; by returning someone 100 different addresses when =
they only asked for one. =C2=A0</div><div><br></div><div>Finally, because a=
 single packet UDP transaction for a DNS lookup can create possibly hundred=
s of packets in response, the service can essentially become an amplifier f=
or DDoS attacks. =C2=A0(If I spoof the source address of my target with a q=
uery to a lookup that issues hundreds of packets in response to one packet,=
 and I can have a real impact :( )</div></div></div></div><div><br></div><d=
iv><br></div><div>=C2=A0</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"><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote cl=
ass=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:1e=
x">4&gt; We mandate DNSSEC while you make it optional.=C2=A0 We did this be=
cause<span class=3D"im"><br>we believe giving the user the option of NOT us=
ing DNSSEC is like<br>letting them order a car with no brakes.=C2=A0 We wer=
en&#39;t sure how we would<br>explain to them why their money was gone when=
 they really didn&#39;t<br>understand the risks they were taking up front. =
We had a lot of<br>discussion about it before coming to the decision we did=
, and I can<br>see why you went the other way, although I do believe we mad=
e the<br>right choice.<br></span></blockquote><span class=3D"im"><div><br><=
/div><div>With OpenAlias a DNSSEC fail is a soft fail, and the user has to =
confirm the address. The reasons are threefold:</div><div><br></div><div>1.=
 At the moment only 83.5% of the TLDs are signed [2]. The unsigned ones inc=
lude some biggies like .sg, .za, and .to</div></span></div></div></div></bl=
ockquote><div><br></div></span><span class=3D"im" style=3D"font-size:13px">=
<div>I think this is a good point, and one we weighed.=C2=A0 When we were m=
aking our original decisions.=C2=A0 Given the importance of ensuring that t=
he lookups return the correct value, and the known vulnerabilities in DNS w=
ithout DNSSEC, coupled with the fact that ICANN has mandated all zones and =
registries move to DNSSEC, our belief was and is that it was worth the trad=
e off that there were cases where existing domains would not work.=C2=A0</d=
iv><div><br></div><div><br></div><div>It is important to note, that ICANN h=
as &quot;required&quot; for some years that registrars and registries suppo=
rt DNSSEC on the domains they register.=C2=A0 I personally believe we shoul=
dn&#39;t delay use of DNSSEC until their registries had come up to current =
required Internet standards. =C2=A0(Here are ICANN&#39;s registrar requirem=
ents showing the DNSSEC requirement, btw:=C2=A0<a href=3D"https://www.icann=
.org/resources/pages/approved-with-specs-2013-09-17-en#operation" target=3D=
"_blank">https://www.icann.org/resources/pages/approved-with-specs-2013-09-=
17-en#operation</a>)</div><div><br></div><div>That said, what do others in =
the industry think?=C2=A0 We are basing our current standard on our believe=
d best practices, and defaulted to &quot;first, lose no money&quot;, given =
the irreversibility of bitcoin.=C2=A0</div></span><span style=3D"font-size:=
13px"><div><br></div><div>=C2=A0</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"><div class=3D"gmail_quote">2. Even if the zone *is*=
 signed, DNSSEC deployment is hard. Unmanaged DNSSEC deployment is out of s=
cope for probably 99.9% of users, even the usually-technically-ok Bitcoin c=
rowd. Managed DNSSEC is available, but is quite pricey. UltraDNS, Dyn, and =
GoDaddy (ikr?) are the three big providers, and of those three only GoDaddy=
 has a consumer-affordable product.</div></div></div></blockquote><div><br>=
</div><div><br></div></span><span class=3D"im" style=3D"font-size:13px"><di=
v>I think &quot;DNSSEC is hard&quot; is a bit of a boogey man that&#39;s no=
t really true.=C2=A0 We are working on developing registrar by registrar in=
structions of how to do this, and we have typically found that if you are s=
etting up DNS by yourself, adding DNSSEC doesn&#39;t take a lot of addition=
al time, maybe an hour or so depending on your registrar.=C2=A0</div><div><=
br></div><div>This known concern, however, is why when we launched our prod=
uct (based on our standard record formats) that we wanted to launch it with=
 a variety of options for people. =C2=A0</div><div><br></div><div>In additi=
on to these options there are also other hosting providers, and certain reg=
istrars that will allow you to setup DNSSEC on their DNS platforms.</div><d=
iv><br></div><div><br></div><div>1&gt; One could choose the &quot;0 click&q=
uot; installation process of just getting a free Wallet Name underneath the=
ir provider&#39;s name space.=C2=A0 This option has been free to end users =
in all cases so far, and I expect it always will be in the future (although=
 that is up to the partner, so some may choose to charge).</div><div><br></=
div><div>2&gt; If they wanted some provider independence, but someone to ma=
nage things for them, they can register a name through us and manage everyt=
hing via our web interface.=C2=A0 This can cost them as little as $1.95/yr =
through us. =C2=A0</div><div><br></div><div>3&gt; Finally, for the &quot;do=
 it yourselfer&quot; who wants full control themselves, they can simply fol=
low the formats on our developer page and do the whole thing themselves.=C2=
=A0 If they do this by registering their own &quot;.bit&quot; this will cos=
t them less than $0.25.=C2=A0 If they have an existing domain name, even le=
ss.</div></span><span style=3D"font-size:13px"><div><br></div><div><br></di=
v><div><br></div><div><br></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"gmail_extra"><div class=3D"gmail_quote"><div><br></d=
iv><span class=3D"im">3. ThomasV and I have done a stack of testing behind =
residential and commercial routers where DNSSEC simply fails (eg. the route=
r runs a really outdated DNS server that doesn&#39;t provide RRSIGs in its =
response, or the ISP doesn&#39;t care about DNSSEC). Unsurprisingly, this c=
an be fixed by...you guessed it...doing the lookup via DNSCrypt.</span></di=
v></div></div></blockquote><div><br></div></span><span class=3D"im" style=
=3D"font-size:13px">That&#39;s some interesting data, and runs counter to t=
he research of the IETF DNS working group.=C2=A0 If you are willing to shar=
e your data, I can put you in touch with the appropriate folks there to sha=
re your research.=C2=A0 I&#39;d also love to see it!</span><span style=3D"f=
ont-size:13px"><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div><br></div>=
<span class=3D"im"><div>Until we are closer to the bulk of all TLDs being s=
igned, and DNSSEC becomes at least a little more ubiquitous, we can&#39;t l=
ock out huge portions of the Internet, because then we&#39;re not really pr=
oviding a useful and usable solution. All we can is make it more difficult =
to pay an unverified domain.</div><div><br></div><div>Of course, if your ai=
m is to force people to use you as a domain registrar, then it makes total =
sense why you&#39;d lock people out;)</div></span></div></div></div></block=
quote><div><br></div></span><span class=3D"im" style=3D"font-size:13px"><di=
v>I&#39;d argue that we aren&#39;t locking &quot;huge portions&quot; of the=
 Internet.=C2=A0 You are correct that about 15% of TLD&#39;s are not yet si=
gned, even though they were required to be by ICANN. =C2=A0</div><div><br><=
/div><div>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&#39;s th=
at are out of compliance, is worth the trade off that some existing names w=
on&#39;t work until their TLD&#39;s come into compliance with current Inter=
net standards.</div><div><br></div><div>And, as we covered above, we don&#3=
9;t force anyone to use our registrar, nor any of our services in order for=
 Wallet Names to work for them.=C2=A0 We never have.=C2=A0 It&#39;s just no=
t who we are.</div></span><span style=3D"font-size:13px"><div><br></div><di=
v><br></div><div><br></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"><div class=3D"gmail_quote"><div><br></div><sp=
an class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">Additionally, we just released another ope=
n source API server to help<br>with the &quot;other half&quot; of the looku=
p problem.=C2=A0 Its in its infancy, and<br>we are certainly taking feedbac=
k on it at this time.=C2=A0 It is called<br>Addressimo &lt;<a href=3D"https=
://github.com/netkicorp/addressimo" rel=3D"noreferrer" target=3D"_blank">ht=
tps://github.com/netkicorp/addressimo</a>&gt; and will serve<br>unique HD W=
allet addresses or Payment Requests for every lookup, thus<br>allowing a us=
er to have a private, secure way to share a Wallet Name<br>that can be used=
 to send them any digital currency.<br></blockquote><div><br></div><div>Oh =
snap...<a href=3D"https://github.com/openalias/openalias-api" target=3D"_bl=
ank">https://github.com/openalias/openalias-api</a></div></span></div></div=
></div></blockquote><div><br></div></span><span class=3D"im" style=3D"font-=
size:13px"><div>These are actually vastly different pieces of software, at =
least from the description, and a first read of the code.=C2=A0 My understa=
nding is the software you linked to here basically takes the DNS work out o=
f lookups for people, as we released:=C2=A0<a href=3D"https://github.com/ne=
tkicorp/wns-api-server" target=3D"_blank">https://github.com/netkicorp/wns-=
api-server</a>=C2=A0=C2=A0Its our Wallet Name Lookup server. =C2=A0</div><d=
iv><br></div><div>Addressimo, as I described above, provides a different pu=
rpose.=C2=A0 Its a way for service providers, mobile wallet providers or en=
d users to have an online server that can serve unique wallet addresses ala=
 HD Wallets (BIP32) or signed Payment Requests (BIP0070).=C2=A0 This allows=
 for an easy way to increase security and privacy by serving a unique addre=
ss for every request, and/or sign the address (and other optional data) wit=
h an X509 private key to prove ownership of the address in a way independen=
t of and supplemental to the DNSSEC chain (also can be DANE for yet another=
 layer of security).=C2=A0 It also supports offline signing of the Payment =
Requests so the server doesn&#39;t have to have access to a private key, or=
 need to be trusted.</div></span><span style=3D"font-size:13px"><div><br></=
div><div><br></div><div><br></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"><div class=3D"gmail_quote"><div><br></=
div><div><br></div><span class=3D"im"><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">In any case, I&#39;d=
 much rather we had one effort going forward than<br>multiples, so let&#39;=
s talk!<br></blockquote><div><br></div><div>I agree, and you guys are in an=
 ideal position to change to supporting the OpenAlias standard (and enhanci=
ng it) without skipping a beat. We would definitely appreciate and take you=
r input and efforts, and that would make OpenAlias v2 (oa2:) a standard bui=
lt out in conjunction with Netki.</div><div><br></div><div>Not only do you =
get Electrum support without lifting a finger, but it will go a long way to=
 repairing your relationship with the open-source community at large, sever=
al proponents of which have taken great umbrage at what you were previously=
 pushing as a closed-source, centralised system.</div><div><br></div></span=
></div></div></div></blockquote><div><br></div></span><span class=3D"im" st=
yle=3D"font-size:13px"><div>I&#39;m a little confused by these closing stat=
ements.=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 th=
ey even exist.=C2=A0 Our system has NEVER been one where folks were require=
d 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 b=
lockchain, never any proprietary servers or interfaces on our side. =C2=A0<=
/div><div><br></div><div>In terms of the format itself being open, we have =
already made several extensions and modifications to it as a result of conv=
ersations with industry participants in order to ensure that what we are bu=
ilding meets the needs of the community at large.=C2=A0 We will gladly cont=
inue to do so, it is how we ensure we are building something everyone needs=
!</div><div><br></div><div>I&#39;d love to know where you got information t=
hat we were in some way a closed and centralized system so that we can have=
 an opportunity to clarify that misconception. =C2=A0</div><div><br></div><=
div><br></div><div>In terms of finding a common standard, as I said, I am t=
hrilled to have the conversations, but there are some places, highlighted a=
bove, that would cause me to hesitate to &quot;just implement&quot; the Ope=
n Alias standard.=C2=A0 I can also see places where bringing the formats to=
gether to one standard could have strong benefits, for example:</div><div><=
br></div><div>I think formatting the record as a key value pair with versio=
ning has merit, and would love to move it in to what we are doing (and like=
ly will).</div><div><br></div><div>On the other side, I think the two level=
 lookup provides a lot of value at scale over trying to send back a bunch o=
f text records when only a small portion of the data is used.</div><div><br=
></div><div>I&#39;d love to hear thoughts from others in the community on m=
andating DNSSEC and thoughts on DNSCrypt.=C2=A0 I have a strong opinion on =
both of those but would love to engage in thoughtful dialogue around what p=
ath best suits the need of the community. =C2=A0</div><div><br></div><div><=
br></div></span><div style=3D"font-size:13px">Looking forward to the discus=
sion!</div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Thu, Jul 16, 2015 at 5:55 PM, Justin Newton <span dir=3D"ltr">&lt;=
<a href=3D"mailto:justin@netki.com" target=3D"_blank">justin@netki.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I am b=
reaking this into a couple of pieces as my first response has been in a mod=
erator queue for some time because it is too long.<div><br></div><div><br><=
/div><div><span class=3D""><span style=3D"font-size:13px"><div>TL;DR versio=
n - Wallet Name Service has always been a decentralized and distributed ser=
vice 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></span><d=
iv class=3D"gmail_extra" style=3D"font-size:13px"><br><div class=3D"gmail_q=
uote"><span class=3D""><span>On Tue, Jul 14, 2015 at 12:07 PM, Riccardo Spa=
gni=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:ric@spagni.net" target=3D"=
_blank">ric@spagni.net</a>&gt;</span>=C2=A0wrote:<br></span></span><span cl=
ass=3D""><span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ex=
tra"><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,20=
4,204);border-left-style:solid;padding-left:1ex"><br></blockquote><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">In terms of comparisons to OpenAlias, I think there are a lot of<br=
>similarities, 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 stori=
ng 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 we=
re<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 achievin=
g<br>privacy, using HD Wallets and Payment Requests.<br></blockquote><div><=
br></div><div>And this is the part where you guys look really, really incom=
petent (and I don&#39;t mean that in a terribly demeaning way, it&#39;s jus=
t that 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><b=
r></div></div></div></div></blockquote></span></span><span class=3D""><span=
><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 proxies people need to go through to easi=
ly implement, be it the 4 you recommend, or 53, you actually have a very li=
mited number of actors for an authority or hacker to go to in order to be a=
ble to install/force logging, or censorship.=C2=A0 This very centralization=
 forces us back to a model where we need to trust a very small number of ac=
tors in order for the system to operate as designed.=C2=A0 This, to me, app=
ears to be the opposite of the goals of the bitcoin ecosystem.=C2=A0 To ens=
ure this point is clear, I strongly believe recommending people focus all l=
ookups 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 t=
hat 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, br=
eaks any perceived privacy gains from using DNSCrypt.=C2=A0 A very small nu=
mber of hacks or subpoenas and everyone&#39;s records are fair game in one =
place.</div><div><br></div><div><br></div><div>For the highly privacy consc=
ious they can, today do their DNS lookups over a non logging VPN connection=
 without forcing everyone else through a handful of centralized servers.=C2=
=A0 Or they can use DNSCrypt optionally themselves.=C2=A0 All of our tools =
have always been open source and folks can modify them for their own desire=
d uses, or submit pull requests with their own ideas.</div><div><br></div><=
div>We&#39;d love to hear others thoughts on this.=C2=A0 While I believe th=
at for now the centralization trade offs required to use DNSCrypt today (vi=
a a limited number of proxies) outweigh any perceived privacy benefits it p=
rovides, we are always open to what others in the community believe and hav=
e made modifications to how things work before as a result of feedback from=
 industry participants.</div></span><div><br></div><div><br></div><div><br>=
</div><div><br></div><div>=C2=A0</div></span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-col=
or:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div></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">2&gt; We have the option of storing a URL rath=
er than just a wallet<span class=3D""><span><br>address in the TXT record.=
=C2=A0 This allows a second level lookup against<br>the URL to get back a u=
nique HD Wallet address or Payment Request each<br>time, further protecting=
 user privacy and security.=C2=A0 Using Wallet<br>Names with Payment Reques=
ts allows for the user experience of typing<br>in an easy to remember name =
and getting back the &quot;green lock&quot; and who<br>the validated recipi=
ent is.=C2=A0 This also provides an auto audit of the<br>end to end DNS SEC=
 process, in the case the path were somehow<br>compromised, the signature o=
n the payment request can provide an<br>additional check.<br></span></span>=
</blockquote><span class=3D""><span><div><br></div><div>OpenAlias supports =
this as well, except it does it better by allowing the KV pairs to also con=
tain a TLSA record before the request, which effectively makes it a DANE-se=
cured interaction. Your interaction requires the trusting of multiple CAs, =
which is an inherent weakness.</div></span></span></div></div></div></block=
quote><div><br></div><span class=3D""><span><div>I think DANE is a great id=
ea.=C2=A0 We were just discussing that with Andreas S., and are currently l=
ooking at whether we want to add this as optional versus mandatory, based o=
n how widely available DANE is for folks using services like Cloudflare, Ak=
amai, 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 setup =
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 HTTPS=
 support this today out of the box.</div><div><br></div><div>The CA validat=
ion, in our case, is an ADDITIONAL signature based validation to the DNSSEC=
 chain, not a replacement for it. =C2=A0</div></span><div><br></div><div><b=
r></div></span><div>=C2=A0[CONTINUED]</div></div></div></div><div><br></div=
></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=
=3D"ltr"><div dir=3D"ltr"><div><div style=3D"font-size:12px"><font color=3D=
"#43aaff" face=3D"Futura"><br></font></div><div><div style=3D"color:rgb(0,0=
,0);font-family:Helvetica;font-size:12px"><font face=3D"Futura" color=3D"#0=
795b1">Justin W. Newton</font></div><div style=3D"color:rgb(0,0,0);font-fam=
ily:Helvetica;font-size:12px"><font face=3D"Futura" color=3D"#0795b1">Found=
er/CEO</font></div><div style=3D"color:rgb(0,0,0);font-family:Helvetica;fon=
t-size:12px"><font face=3D"Futura" color=3D"#0795b1">NetKi, Inc.</font></di=
v><div style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><fon=
t face=3D"Futura" color=3D"#0795b1"><br></font></div><div style=3D"color:rg=
b(0,0,0);font-family:Helvetica;font-size:12px"><font face=3D"Futura" color=
=3D"#0795b1"><a href=3D"mailto:justin@netki.com" style=3D"color:rgb(17,85,2=
04)" target=3D"_blank">justin@netki.com</a></font></div><div style=3D"color=
:rgb(0,0,0);font-family:Helvetica;font-size:12px"><font face=3D"Futura" col=
or=3D"#0795b1"><a href=3D"tel:+1.818.261.4248" value=3D"+18186258220" style=
=3D"color:rgb(17,85,204)" target=3D"_blank">+1.818.261.4248</a></font></div=
><img height=3D"62" width=3D"250" src=3D"cid:E0A6097C-DC31-4735-8626-14DED8=
00B4E6@gid.net"><br></div></div><div><br></div></div></div></div></div></di=
v></div></div>
</div>

--089e010d8f485aa5d9051b07ae09--
--089e010d8f485aa5dc051b07ae0a
Content-Type: image/tiff; name="PastedGraphic-1.tiff"
Content-Disposition: inline; filename="PastedGraphic-1.tiff"
Content-Transfer-Encoding: base64
Content-ID: <E0A6097C-DC31-4735-8626-14DED800B4E6@gid.net>
X-Attachment-Id: ec6bb066f4bb7681_0.1.1

TU0AKgAAHcqAACBQOCQWDQeEQmFQuGQ2EgEIhMMB4klY3OR0uNtv1frZRAB/P5+w6SSWTSeUSmVS
uWS2XS+YTGZTOaTWbTecTmdTueT2fT+gUGhTICgYDgUumhAhYgEYpC9xuJwLxuOJ4gIjkQfPpAnI
oP5rtJj0OyWWzWe0Wm1Wu2W23W+4XG5XOgAG7AMeEMpgY7oVSgACUUltZlq58vqILxxv8gv4OAFh
AIYjQfP5qtBiPpDHcrv92utzXTRaPSaXTafUanVavWa20AIPiMVgZAI9YgEMhwRwQPNlor8zkUjE
FfrJar9eOJ/Y18uljAIqk0dQh+K5So99qBJnoAPp9PjXeHxePyeXzef0en1T4AgwHBECnE/JwBjs
hFKEAKBl93ORkBIGAZhw4rjuS5aCH6BB1lWAYjCWKqEn4fbvEWPwvn6YRdFSAB/w69cPxBEMRRHE
kSxNE6BAGAYCAIKYujmAoxDcRCShYZhhFSLIpCqK6CQI5DlCCgh/n8epxgCIwbAeAAFAWByGH+dB
ym+fRBDmKJ/G8bRoxRLsvS/MEwzFMcwLsAIBBkHAigOPZFFXJknJKBJ8HueQ2AeBB5ggC4MA3Hzj
SBA6Dn6fRwFIAYqCsLiUn6ZBhFmfZHD+MJ/nkeJ2zJTNNU3TlO09T6WtwDYRAMPhFlYAQRhQGKWh
4ZhglIJIpUUhEfwNISEACf59H+F4LG8AIPBCFCWn2T5KD0fhWlERgAH5CVQIOAgZCQPKgn+eJ1I2
bpnFYtQCgOBgCBaII2pqfpvGeVp/ngdJtJqAIDgUCIBhWHw0U3dF1XZdyU3jed63vaKTn8cRqFsf
x2HJLiUAIFggDWAADARJ6aH6bBjE8f57HkdKhAEAgDAIGAiDmnp+m2ZZTn+eZ2nBf15Xpe18PIBA
EgWAw0jsSQBiOJ4xJiCp0HGbA2hiF4RAGAqi1rQFboYfp7nCWIBiuKonpke57HozQ7isfpmGMXEO
Q9Ti7ASNRLn8sp7k2OEnn2fB5rKAIFAeDIEDARLQpofRcEwKV0GgV94AeCoSAQLZBm3Te/cBwXCJ
QAPDcRxXGYGkp9mAUgyn4axiE4lIEC8Q5xPaCIOpqfJVEKGWEnGZ6ggKIAuE2AgVB4Micn+d5zms
fBTkEFiBbKk/J8PxPFtXM+QZ8MQCjgPpNpyKBtmgWYaiGI4moZW0gpKfwMH2XYBBsHYipqfxwG4a
kqyuf5zHGblM7PtO1rIfZlloQB+f0QLdG7N4b03wmbjnAjecG4V5DlnGt/gPAlyTlHkuXcwQ5zTn
HPOgdE6R0wDHUOqdY64djsCegCAoB0GIBwrB7GcT0fAog9AfH+PQdw4lQwSgYaUAQKAWg4AMH8Rw
sCIATAuTkEI1Rmi6DIEkJQRiSveUEQ4fw+h1jLAEFQJYNWTi7FmKEfQlhFLmHuPVuaKH6tqLSPcT
QbQFLOH2PcoLdW7t5b2TWAzkIFOVeUpqO8CHIvGhxHuCpDYLudc+6ElDo3SundSTR1brXXuxJyAJ
pQCAwiKHQvEBYEicj8GYLUQY+xlCzD8TF48eoKFuACBICgGQDB5EOKcAQLQZg/J6AQuwAAxDzHSM
8D4KgWqsJJFBXBJx+gDHOKcAYSwnhZKCPsSghw1D8FsK0TRICRIhjO/cs4+xiCqDgPwaQvhIxxgD
HSAhMo+wQJnKeCcDXHx+X9IGVMgyFSFgzIgk8ioOwfkdCGSJOQCg7CqI8AgLwhhwd2PceY6h8ChD
un4kI/JTT0W+UYAoXg0iCAIFUL4diygvGUMAUwVgqBXC0SmYhKUOj4Y8EIF4BQAgNAfJwoClR4Ds
K4V4yw0Binqm2Wqicao2EgH6PsnscoBR1b7A6PBNJ3Q5UzOuP5JqoyCntPdzchoNSJg5IyEEkIRy
SnaBEDIKgEBZD+NUno+RViGBmP4dY4oW1QotHEu4PAiBUL4IQUhgGmFkAWPQeQ7A2gYAiP4BsrAL
Uqac98lg/R8DeUOFYLCiy0U9MyIYPAWDPDqHKeKoJbB9C9FAhcbIyCPk8qVOiO1Tp5V2gXVhMdVJ
52znrVkg8+JDwbkXB6RpM5HwihITEATIJ+VKJyP0bIyRR2lE+F4nNV7ck3AECAEgLTaG2ACn0EJb
QfjOGGKYIwUAqUpJZSsloAgAkhBQA0aQAgSAoBgW0fgrxTCQWMJJax3jwGntGWwfg+h7NtbehybJ
OLWwDtfPGdhMrqTwgfVUkuEbdVagxb2r1v5/XCoBWMmIBQbBOEGAQGgSg+E6H9gMe4nA4gQjdHDB
Vdyb0ZDYIwAgWgxMmLgBccY3RoBtByDgFzzD9XpsfFEl1khyC2AGFYKQSi5D0sIPkOgYggPqG5WQ
umAS3D6FuJgKI/RvjQFhdOc+DKm4OwoTDC1U7YYPwrjTC9u6tz5t9P24JMrh0BJZm8nQ+haiUCWP
0cLB6k50JqAoSosR/j9GkMgVYAQbA4BsAEDYHQPt0IGFQb41RcAwB+EIJBMb1EzH6BMe+Tgdg/yk
WgjguxagCAMAwEI/BeiwEePwYwu59ZdAC2iNBcB/0MocKAOwGWyTcwhmmpkBc45tJfoCOwuxO0pq
Pf8uY/h0jfGSP8eo8Z0kmXAAsAYHQUxOJ7JUAwRQximJzKIWYfx/juHKNMntcnYMsZdnmsE/6xXF
ckmd5I3AAgOApd8nA/hzDaGCPkWAjggRx0UTTRmjkhj4Y4P1LYsplhQCsxIAwBiegkGkMoWoYQmB
NCWTXU5MopjtGgAIKYRwXAAeZvka41BoAAG+OEdQAwTgu3UQIfQpRKOd17r8ueXi4j5FiI8IY/hy
jZF8vDZ24yYW2tlKgnI9xLBpyO8XOuFdgv2JyPgUAdwNMbHiOc01ybgVhuJlwkq01qgFBwFAQ0Lh
OhzAmP8fI9R3cUtwTni4/yGbcHINgfw9h4DZAGEQJLWCaAFomGQfI7xrAcBOCrm5NOXrnH+ONQ4T
wp2YJmuwd47h/C+F0LgAgLgchY5wmchHR+k6818aTp2xB6DvHHC+GLxPFZu6zg3CceZ3k47B2L43
ZXjdn2GTftXbO3dwNL3LDufMP8CIa6cDkihxk9c0KUM7nhhzXLJtTi2jfjzGN8LoAAHgOgTAECwF
4MyWgyGUF+FICmCosuJy9GJoQ6H08KB8BSH2iGiKpY8UH8FoFclkA6BMCEpmT2JK906U96NG9+Lm
HyFaESBy24G+GQlM+SzW+W66+aJu+e7G/i+kIdBAJk+u7aHs7e7iq+7m4A7q/C4ICyEAGuACT2BM
d2XaG0eAEABS2Wbo4qJm8SJiIA/GixVMAh8QyIAQoFQsAIdD4hDgc83g6TaHgyBwUDQcEIjH5BIZ
EAF+slqv144n8QZHLZdIH6+G+pwGViuWZfD38xWCuwC+n8EAEHhINZzI30pUoZX4xl2nKPUalUwC
AQSaku/qnW65LX87XK0nyqUGL67IACCgeGQQYES5rPSFwmCk/W80FfcZEAQeFRICC2g23epc90sa
QFDn+/8Jjcdj8haKtWK1kYi+FAdw0/3s8XPltBEQQXkO4gCDAiHdA+VUhRk/nY42fLgILCAawKPi
wlNDIHwpD4I3+8nY3t7VL7f8Dg+OCkqscZln+83i6n64WwvAGTimWgBVYiQ2exFOQieU5xx4hJZP
KZX6oiAgCAH8JQUzQEJxWM4g/2+bptH+aRomsAYWBqKDQKSpamqe+DIKqq6swe3p8lQQQWH8dxzG
qvS0rWtq3wUua6ruvLLL4vzAME9TDMQxTowpGUZq5CLKPUzDNM4z0aMa0bStO1LVta17YtmtAFAc
DC2kUz8KH4ZxcEOfZkFgPUepfFLlRY5rnxi+B/HIb5nn+AZ+nWDYNgyB42B+H4byw9iUJUlken8f
Byl2AQliKHJ+lyWhYAIFYbisAACAIAz1QWpinKhLCuxtCdIMafx0G6Yx8lcRYdw8tS2LcuDLH1Ei
7Lw0EtRW5jexcxIAMXSlY1k77J0m3scs2zsnVmqUftM1DVMs1jXNg2SPqqA4rD0/AKA6GL1H+fJ6
ncfBPjqC76H8fleWO5NVPU5zoSw8AACyeRuk+DgXBmG4HBAEgVRlOT3TrB75PmFAAHOVhvn8fZ/n
wFgbCrLFGQbR9uSzWrKsifx0m+ZIAgcCgQqsBqGssfBSj6Eh/nidZuxrT8Q1EyNSLpU0TsjVLlxa
w9XVhhOZPVSWGNDXEd13maW19INgsjYci2Mh4BhSHQxAMIIvE7GR8lYRAbH8dRwGXnaI5ZLje3DL
8ZBwdZuFgQo0jGKB9n2fR9FmVxWlUCociEJwCAWBgHNBec6PUDYAHcYwhBmEh+BQHIdh8apqGobB
TnOegRUPRMZYNR2rJHmrQH6bpmlWfprmOT4DCYNhbcscJplqfRakqJmRRBUMR5RE1UW9lrjnuTA1
AK+h/n7yaI5j3iqYXHDM1zHnfpDntgSHYkjACBAFgmBAxEadkZH6bZllOfRdk673jIfrFVtDrcZA
VV59EoGIOHCD4RhIEqQnScpynGYJjfsDwhCUK+uLPu73mOAeAEfA4wbgWH8MYH4VQrhXJcI8SolR
SDtBUDcLjkClKNQc94iDlTLOXcyPoXQnAsJMHOxZjBkR8ChDuBsf49R4slSyyN1qo1SuwRQ7JrMG
kKO1dutlbcOnKPBOOzhXUQCIPISEsJIhsByDQAOFMOwxgBAXBCDhMA/B9D3E4HICIAIsD2iA+BcC
XkZBMHcNsUgcQzBkgqVsZoxxijCHIPcfYAALAvBqD4rj/l6lSAMAIf4+gXAFHUKoJAWQrhOASAwj
hUR3jwHgPIRovxkDxAABBZqi4LsHiMrRCTNjHweFWPoXImwrADA8CwJLn3QuWGyMkUY+heifC8VF
D6oERQ0deqeG6KnZydRa7Z3A/ltTAMlJ94SOoizAiQz8yDQQAgQAuCYAwRgyCocgLYSwTx+jgGkL
KY0YkuriOOBcfA8hwidCiEICYCQFtzMeLgWArxVgFBMwIBQFwNAfJdHwlx8yHAkAAOkWYRwkg+BK
BkEYJl8mOFCKAT4qRtgfBbAw47kYMxhiEZGUUpJTK0AE9ERg6wAgHAWBI0A+BPBzAowAeo7Z/wyl
yyaGsvGVw4fDMY0EPJhzFp1BujbN3hs5mNM00A+xjiuDsAUHIUhFIyH8OcbgxB8ivEYD2n5DpxNa
jIccMw/R0CrgWFdgjtB6j1HoLUWYshYAbCCEpQyiFFEPn8SBbA8Rng+BSBcdIMAhhFCQeofysBAi
gFOMYfoIATA6QVJtyURoOUccxKOUqhmiAiBgFEAwSA0CuNAQIXokB9jFFWHGmLrKZmQZOiWmyEKc
VZNDTyH1sKtVBpTUOZcnajW0I/SoOgFWAD0epVmrb4qumRBQO8cYwhKhlC5HpWI4BtjaGwMwao1x
sgbB6EQJ8fAFgCH2OwGoDx7C6CIFkLQWAAgCvYlgXouxdjBF+AQCIP7GoMsfRqZEHbJ0ess9+9b0
RGjtpKAojxlh7ibDeA0AA+x8j0JDLdkjrrWMqtdL6HNvDG2ymJD+2FkahTKeLbo0iv4k28H2MQVQ
cB+DSF8JHDR37Xzjf4Wde4ABBgXACMIHAPAe3QZmMcYAvhdjHGwOEeA4x2DwH2EkK4UgiANAkBSE
7MhDCVEuKwewKgahUMfRhhEOsQShv7ZUkIA7MWas5Z4yw+xlCyD6PwZgthCYRplDDL9NcLGPuLjE
vWHKfYftsxm3GI4jW7t4XYZ4rlSCZCnjHPplnxmOB4OsbYrBAhpDJl534mRViuF2LIaI2R3AGHcP
YfoXQzBdCIBkDoG8qsJG1rMboohvjrAyAAAxGi9Zgk7mMx1HczYRwC9LAhGsDmRHuJkNoCQAD9H2
PiDed8KMpdjhinOfiz6Aw9cTQcKNCs6iBogyC0Vp0lpO00WAjQfj+HMNsYWH8Z1cnIWcBg/x9j0E
qDYEg6wOAfBACFhIwxnjQGwI0WwwBsjzBODGbg2RpC/AEPwCpLB8XCBAP8dQugwBwDWFgAoBQCKu
V4JMS4lxSDpBQDWNpZ9fWQ2+YTYVHyW5oszZuztRxhipDcPwaYvxJ7TtRngx1q9rS9S3tnbRXNuW
82BuDEW4odbkMePkWYkQjAGB6buaM0z4YOHoPelYFNnj8HzOHedxt6ldCiPAbgpA2BkDHy1SA6h3
jxHoHcS4nBYDisxXFx5Dx+8Q4lxSPpEABDuHKNDfgEx0BNC0FWwKsR5j0HoPYRItxgmfAoBcEZXO
X36RvfyD+wyWlVpDsbAuyVKxYHuJoN4DD6bQwlDOmku89mO0j0srfTbadPMhETQ248Ss+eUDK4I6
0fjjeqNcYwnh9C/FEGPtG2Ix9rKiBoew8BtidCuEcDuuwEAIeqrAQQmBOCsGIAQCBRgIgWn4S3wf
EeJ8VKiAgdA2BZhRCiEQEoFgGYGKhpGgU4UwUoVwaoDIE4KT0CxyjLMTmIvTma/4l7mzNTnJUYXg
T4LofobQZIUj2q1LPL3Da7pJHATgOICAf5bQfR7wfgfYe7bT4Ax74TqSDTqgxxoJYoZ4AgGAIoOY
AoHQKYRhpqJZIyMLtI0DSYqYNoAYdwWAKD/hBJCgU4W4XQYgUIaobxfwEAFLIAqT+bwr+wrkFgCY
dwbQVQMINoMoJwCICYCRuo45mIQITwUYYIfgEQFK+wo70MCC/ayT0rmgo71DATY7AwyCL7BIOABy
EzCaXTCsEpb52hl5GD3iDUGYx0Gqor4p5KJR5ZY0QgLIQAa7roExaBaRahaxbDDp4z3YyEJYl4Fi
5QX4SK5zw4ywaQbYbocYQYVIWAZAdwFAGisoxsML+sW4uIerJIEwBAeoYwLoNoM4K69igAywYoYY
YYZAW4fgBKK0PkBzMMS8CIuMCYrgAYEYGYKoAwI4MoVRBQW4S4KBhwcAZURz28SDpESRVkShV7Gs
SxmcTAxsTSZkTjE6Z8IxoarQ1ADj5ZGQfgaAXYRofYYwVoOkVsJLSS44kTkY+YRIDoBIZIGAGoGp
OAxzsIe4fQOwSQTAVQbADYFAJx5pJKVz+jww9QAYdocIYwIAGQEQfgIQJoJUL4x4RASgSwVIegFY
GyiwpEcDX8cYs8cori9gAgBIMgSCSxRJ8oxwf4e4eYdSqoRgHwBALQQIbDaqGym760SZF8fsf8Vs
qAwkgbEhIETpoEhBI4j8HsH8IMIZGQfAUwP4FAf4iobJq0Vwx8WAkIIAdYbQVIPoNIMspgrpGIRg
UIUoWYXQeoAIEofwC0l56rwkY5LABYdAawVgLALgKIGoEQFAEz+Is4cM2QcoTYawcLBgBEmYkEPs
cUP4yEqQs4AYEwGwLYAwIgMQUhyyycc8dMtC1rPkjDZUfh30t8w8uIvUubQ8gqZzqsvAvbAILAP4
aoAICIDEAY0If4ei5QfAUYPbgUFZ3ZbkxAx0xQh4B5fweQTQHwFgeoCgDADDXIrYWwYYYwZ4SoYo
ZwdYfAEgFoIxWUY0mxWTsADIewcIWAMQOANQKwBQBYBKuYqYSwTATAUgcwE4GjugiE3h70gIrs4D
GwAUqsq8rIA0raTro0tLC8E0thmEf06pXlFk7DcMTcusg07sT8vIvbahChKhKxKBKRhM+Yxs+ohw
K4eYbwUgMwMIMNFAlobocgcwdQPwT4UwXgdAFIGp7pmdCEMZnYeQdQbQF4CoAYawKoMoMAKEaowo
fAfIfQQwWAXAbwf4C80Ah9FUuE3zMkQMCgvU4U4k405CY1G8573U6IyBVsStH061RDQjqNIbE07k
HM7wo42o243I3cv4UQPQD89IdwcRWVKIwkWADql4awToLYJwEwAZRAAgkIfaYgAAPASASoUwaACI
D4IgAABoB7WJndNcZByYAodIbYXYJIIYGoCQG4IAHo/gloVgVQVIWIaACoEYJ9FMpzmFTcYrMsQQ
xsqkq0rBQ9GiIFST3IxtWDP86dHtTJWNIAuM7L4lIlUAxsHUI4qRZALAPoaQAQCQDQFhaAiobUwA
QChs6hGVe4uMWAOgBIeYWoJIJYJgJYkIS4VQVoXQV4c4eQCYfoDYEVbiTtZy2ABwdIaoU4Lq5wIQ
DQDwDhbAh5GIQQTQTwXQfYEoFwI1Qx39foqdFwx9Rs4s485KHVekSKX62NfNfZndpIrtf7qc7b48
HZ1aXDog3ofYYQU4NQfgagYIS5cdSsxJLwGIdob4XARgM4MDyYhzgjgwRgWwX4bIegE4GVcrDVmD
GMVAD4fodIXAMIOLj7kLkYZIZAZAZoWYe4AgGdo53lrIqNpYx9d1GVeNGpydqUfNqindq1q5mVzQ
rdrcG9rsTxoVJArlUg3A3Q3hChapa8rsr9i1toxwCAS4WQfoRgEYBwaICYDoDwEYPIS4T4WQcQEY
GDwFD7P1wkf7xLxYG4EoCYdQJgLIKoIwRQSdYYdgaIZYX6TldD0cQCyldg0FptR9qB3l0ctVHQ3p
hxiBV4f0+KDVJgPLdzeCn91Qqd1h70HFgdURDykthFhVhlhw49+4ZIfIVoRQHNTA3ti4s4JwQIRY
Uwe4rQAgYoAoCAGwAD982FH16t1AA4dIbIWoH4HwGICYXAVQUYTYfIYoXYT0p9dLmVddRY0FdwMw
SQeoAFGF6ZhN+dHMfV1AqOJOHd9TEJ4kG2At10u9I7PlJRB57R7h6x7Bml3oxoCAKgMAP4ewBwCQ
D2Jg3we+IgfAfwBeNRq4xYfoAQaAYQTwe4b4bAZGJ5W03+HxGQAgFQHgMgAoIALgTZq2J1SkteOI
nORb0WPy29TsglgNr1goyOQWQmQ2REv4TqLhaL7dqbDI44ARd4FoAwP4RwV4AIDIDjz9fYfwaAZQ
X4AYBoDNZ86ofgkoSAfQWIUYPLBofTaSnWAQl9zmUoAYAoBIMwSLCGI2JDPWUbpWRwkOSEP2KGSe
KVTz4119r40JZBZRZhZywQcgbAXofIWQSFZF0mUhCgqoAIAYHgIgKgAwO4Qk5IAgAuI7DWWWWmW2
XE6ofwboayqgTwRgLEwgsEGU64reZA+GTWQuQ+RJbma5D2MGatQuaWYuhos+Ah42AwwlgkhOcABJ
i4BAMIRYdKbISoJqboaYWk6GRpXmfYA4AoLwNIQQAgKoL4OzGOf2WuW+XKYE9I4gfITIQ0eQbwa4
YtTOYwl2h4+AAWZWZmZ2IrwJSmiwuODGR2rVQ+bNTmbeStT+S+kg9WiOTmimB71wToOalDB2Imre
jFV7KYDIAwPIQ4U4AQFoGcPaTuoGgGoaDQfQVB2wfgYoXITRbN/dfep7+WQBWOtGiZWWrxSOuejO
ytzOjtrVIWsebuK12BGmcJZYARZpZ447RTRgXDR2i+maIAAQFAFoHGVIRwWE8gCdnh3mwGoSIAfg
ZAXwUIfYVYTQNpgEr2jLAGHkCWyBWOqeZeZuZ+rBGezIrermOO6lTWsDqGsUumsmb2TBGcRulOlZ
CgfLdbdrd7eO6uy9pEqgI4J4MQAoOAPutRmW3egJnYfwcqbwfITYRAKYf4daqW5CIO5Ucm5hWeyW
TpHu7Fg29mrujacOzYrmj53+kIvWkd2JHvBW+o0LsDsSljsrs8QfB7Q6dwAwNMlQAe94MRWW++wR
B4fLi4fIToRQKwfoaxKMftfXAhq45PDzB4zgeQdF1OqZiQCbgRHvIQz+uA0O5wALKWE/Hoj/JbBp
aTeQvxaAeYdocC2aYHKACYEGItGA0E9K5XEVH4qoB4CmWBB/IXIjsAqXJ/KNq+VtlgAwPgRYVgAQ
EYFG05B/F5LAfYWQUYPQfYXiqzZ7aHKfRnRvR3R/SHSPSWji9YGQHAIoA4PYRQVYAFDkOJhuWeoO
/A3ofoaYZYWYfQUYSIMKFvLfSfV/WHWPWXWfWnWoroAdXQAgKILgOIAoMgN6p4x3QMrgdph+o4Q4
KO/Qb4aPW3ZvZ3Z/aHaPaWao04BwCIAoOIPwTgAYHYIUBgrfYYrYfiLAfIUQSAL4foZwYgVPHfaf
d3d/eHePeXeZyYAR9gFYAwQAR4WOVuV4l3cIl4fgXwWQR4fXQhK5s+Ynenhfhnhvh3h/iG6oqueQ
IYKeewQoUpQ+fYiHgHjgbgaoYQfOg4LJjxDfiPk/lHlPlXlfhemoAoLoNAQIAgKwMAO/F46Y6uo+
pIf2PQY/lnn/oHoPoXofWG24DHmYMIPQf4aoaYaqTiYmxnonqXqfqnqveIgIAA8BAAADAAAAAQD6
AAABAQADAAAAAQA+AAABAgADAAAABAAAHoQBAwADAAAAAQAFAAABBgADAAAAAQACAAABEQAEAAAA
AQAAAAgBEgADAAAAAQABAAABFQADAAAAAQAEAAABFgADAAAAAQA+AAABFwAEAAAAAQAAHcIBHAAD
AAAAAQABAAABPQADAAAAAQACAAABUgADAAAAAQABAAABUwADAAAABAAAHoyHcwAHAAAMSAAAHpQA
AAAAAAgACAAIAAgAAQABAAEAAQAADEhMaW5vAhAAAG1udHJSR0IgWFlaIAfOAAIACQAGADEAAGFj
c3BNU0ZUAAAAAElFQyBzUkdCAAAAAAAAAAAAAAAAAAD21gABAAAAANMtSFAgIAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWNwcnQAAAFQAAAAM2Rlc2MAAAGE
AAAAbHd0cHQAAAHwAAAAFGJrcHQAAAIEAAAAFHJYWVoAAAIYAAAAFGdYWVoAAAIsAAAAFGJYWVoA
AAJAAAAAFGRtbmQAAAJUAAAAcGRtZGQAAALEAAAAiHZ1ZWQAAANMAAAAhnZpZXcAAAPUAAAAJGx1
bWkAAAP4AAAAFG1lYXMAAAQMAAAAJHRlY2gAAAQwAAAADHJUUkMAAAQ8AAAIDGdUUkMAAAQ8AAAI
DGJUUkMAAAQ8AAAIDHRleHQAAAAAQ29weXJpZ2h0IChjKSAxOTk4IEhld2xldHQtUGFja2FyZCBD
b21wYW55AABkZXNjAAAAAAAAABJzUkdCIElFQzYxOTY2LTIuMQAAAAAAAAAAAAAAEnNSR0IgSUVD
NjE5NjYtMi4xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AABYWVogAAAAAAAA81EAAQAAAAEWzFhZWiAAAAAAAAAAAAAAAAAAAAAAWFlaIAAAAAAAAG+iAAA4
9QAAA5BYWVogAAAAAAAAYpkAALeFAAAY2lhZWiAAAAAAAAAkoAAAD4QAALbPZGVzYwAAAAAAAAAW
SUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAAAAAAAAAAAAAWSUVDIGh0dHA6Ly93d3cuaWVjLmNoAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGRlc2MAAAAAAAAALklF
QyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAALklF
QyA2MTk2Ni0yLjEgRGVmYXVsdCBSR0IgY29sb3VyIHNwYWNlIC0gc1JHQgAAAAAAAAAAAAAAAAAA
AAAAAAAAAABkZXNjAAAAAAAAACxSZWZlcmVuY2UgVmlld2luZyBDb25kaXRpb24gaW4gSUVDNjE5
NjYtMi4xAAAAAAAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2
LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdmlldwAAAAAAE6T+ABRfLgAQzxQAA+3MAAQT
CwADXJ4AAAABWFlaIAAAAAAATAlWAFAAAABXH+dtZWFzAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAACjwAAAAJzaWcgAAAAAENSVCBjdXJ2AAAAAAAABAAAAAAFAAoADwAUABkAHgAjACgALQAyADcA
OwBAAEUASgBPAFQAWQBeAGMAaABtAHIAdwB8AIEAhgCLAJAAlQCaAJ8ApACpAK4AsgC3ALwAwQDG
AMsA0ADVANsA4ADlAOsA8AD2APsBAQEHAQ0BEwEZAR8BJQErATIBOAE+AUUBTAFSAVkBYAFnAW4B
dQF8AYMBiwGSAZoBoQGpAbEBuQHBAckB0QHZAeEB6QHyAfoCAwIMAhQCHQImAi8COAJBAksCVAJd
AmcCcQJ6AoQCjgKYAqICrAK2AsECywLVAuAC6wL1AwADCwMWAyEDLQM4A0MDTwNaA2YDcgN+A4oD
lgOiA64DugPHA9MD4APsA/kEBgQTBCAELQQ7BEgEVQRjBHEEfgSMBJoEqAS2BMQE0wThBPAE/gUN
BRwFKwU6BUkFWAVnBXcFhgWWBaYFtQXFBdUF5QX2BgYGFgYnBjcGSAZZBmoGewaMBp0GrwbABtEG
4wb1BwcHGQcrBz0HTwdhB3QHhgeZB6wHvwfSB+UH+AgLCB8IMghGCFoIbgiCCJYIqgi+CNII5wj7
CRAJJQk6CU8JZAl5CY8JpAm6Cc8J5Qn7ChEKJwo9ClQKagqBCpgKrgrFCtwK8wsLCyILOQtRC2kL
gAuYC7ALyAvhC/kMEgwqDEMMXAx1DI4MpwzADNkM8w0NDSYNQA1aDXQNjg2pDcMN3g34DhMOLg5J
DmQOfw6bDrYO0g7uDwkPJQ9BD14Peg+WD7MPzw/sEAkQJhBDEGEQfhCbELkQ1xD1ERMRMRFPEW0R
jBGqEckR6BIHEiYSRRJkEoQSoxLDEuMTAxMjE0MTYxODE6QTxRPlFAYUJxRJFGoUixStFM4U8BUS
FTQVVhV4FZsVvRXgFgMWJhZJFmwWjxayFtYW+hcdF0EXZReJF64X0hf3GBsYQBhlGIoYrxjVGPoZ
IBlFGWsZkRm3Gd0aBBoqGlEadxqeGsUa7BsUGzsbYxuKG7Ib2hwCHCocUhx7HKMczBz1HR4dRx1w
HZkdwx3sHhYeQB5qHpQevh7pHxMfPh9pH5Qfvx/qIBUgQSBsIJggxCDwIRwhSCF1IaEhziH7Iici
VSKCIq8i3SMKIzgjZiOUI8Ij8CQfJE0kfCSrJNolCSU4JWgllyXHJfcmJyZXJocmtyboJxgnSSd6
J6sn3CgNKD8ocSiiKNQpBik4KWspnSnQKgIqNSpoKpsqzysCKzYraSudK9EsBSw5LG4soizXLQwt
QS12Last4S4WLkwugi63Lu4vJC9aL5Evxy/+MDUwbDCkMNsxEjFKMYIxujHyMioyYzKbMtQzDTNG
M38zuDPxNCs0ZTSeNNg1EzVNNYc1wjX9Njc2cjauNuk3JDdgN5w31zgUOFA4jDjIOQU5Qjl/Obw5
+To2OnQ6sjrvOy07azuqO+g8JzxlPKQ84z0iPWE9oT3gPiA+YD6gPuA/IT9hP6I/4kAjQGRApkDn
QSlBakGsQe5CMEJyQrVC90M6Q31DwEQDREdEikTORRJFVUWaRd5GIkZnRqtG8Ec1R3tHwEgFSEtI
kUjXSR1JY0mpSfBKN0p9SsRLDEtTS5pL4kwqTHJMuk0CTUpNk03cTiVObk63TwBPSU+TT91QJ1Bx
ULtRBlFQUZtR5lIxUnxSx1MTU19TqlP2VEJUj1TbVShVdVXCVg9WXFapVvdXRFeSV+BYL1h9WMtZ
GllpWbhaB1pWWqZa9VtFW5Vb5Vw1XIZc1l0nXXhdyV4aXmxevV8PX2Ffs2AFYFdgqmD8YU9homH1
YklinGLwY0Njl2PrZEBklGTpZT1lkmXnZj1mkmboZz1nk2fpaD9olmjsaUNpmmnxakhqn2r3a09r
p2v/bFdsr20IbWBtuW4SbmtuxG8eb3hv0XArcIZw4HE6cZVx8HJLcqZzAXNdc7h0FHRwdMx1KHWF
deF2Pnabdvh3VnezeBF4bnjMeSp5iXnnekZ6pXsEe2N7wnwhfIF84X1BfaF+AX5ifsJ/I3+Ef+WA
R4CogQqBa4HNgjCCkoL0g1eDuoQdhICE44VHhauGDoZyhteHO4efiASIaYjOiTOJmYn+imSKyosw
i5aL/IxjjMqNMY2Yjf+OZo7OjzaPnpAGkG6Q1pE/kaiSEZJ6kuOTTZO2lCCUipT0lV+VyZY0lp+X
Cpd1l+CYTJi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCerp8dn4uf+qBpoNihR6G2oiailqMG
o3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyqj6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uw
ALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm28Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70V
vY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfL
Nsu2zDXMtc01zbXONs62zzfPuNA50LrRPNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls
2fHadtr724DcBdyK3RDdlt4c3qLfKd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLo
vOlG6dDqW+rl63Dr++yG7RHtnO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ
+Kj5OPnH+lf65/t3/Af8mP0p/br+S/7c/23//w==
--089e010d8f485aa5dc051b07ae0a--