Subject: [saag] Hello from the Ethereum Foundation

From: Virgil Griffith <[email-masked]>
Date: Tue, 28 Mar 2017 00:06:18 +0800

Hello everyone.

I was invited to this list by Walid Al-Saqaf.  I represent the Ethereum
Foundation and am joining this list because the Foundation is starting to
build-out our public platform. For an example of this build-out, we
recently launched the new Ethereum Name Service:

https://hackernoon.com/hosting-a-dns-domain-on-the-blockchain-58a41dc50028#.b5tetdpiw
https://github.com/ethereum/ens

As-is, the Ethereum Name Service allows any "smart-contract" or "dapp" on
Ethereum to be accessed via a human-readable name.  Normally this requires
access to the Ethereum system, but we've opened this up to the
world-wide-web by with the DNS proxy "ens.domains".  But we wish to do
better.  Particularly, we are interested in getting the TLD .eth as a
reserved name for the Ethereum platform and get .eth added to the list of
reserved names akin to these:

* https://tools.ietf.org/html/rfc6761
* https://tools.ietf.org/html/rfc7686

Our (very long term) aspiration is to demonstrate by example how a
blockchain can be used as a fully transparent, decentralized
domain-registry.  We hope that if other TLDs see that this can be done
securely, that they might be inspired to emulate us resulting in more
secure, transparent DNS for all internet users.

The Ethereum Foundation has two benefits to the IETF:

(1) There's been plenty of talk on the interface between the web and
blockchain systems, e.g.,
https://www.w3.org/2016/04/blockchain-workshop/report

As Ethereum is the most flexible blockchain platform in the world, we're a
good candidate for experiments in this direction.

(2) There's been talk of wanting to doing IoT with URIs, again particularly
referencing blockchain,

https://www.technologyreview.com/s/603298/a-secure-model-of-iot-with-blockchain/
,

and Ethereum is a good fit for this as well.

I am writing here to get feedback just for how things work around here and
any suggestions for achieving our goals.  Outside of our interest in the
.eth TLD, if you have ideas for other ways Ethereum might help the IETF,
we're obviously interested in doing that, and we can discuss the
possibility of devoting some man-hours to doing that.

Thanks much,
-Virgil

---

From: Ben Laurie <[email-masked]>
Date: Mon, 27 Mar 2017 18:04:47 +0100

On 27 March 2017 at 17:06, Virgil Griffith <[email-masked]> wrote:
> build-out our public platform. For an example of this build-out, we recently
> launched the new Ethereum Name Service:
>
> world-wide-web by with the DNS proxy "ens.domains".

DNS is used for a lot more than just the WWW.

>  But we wish to do

Are you intending .eth to not be resolvable using standard tools?

> we're obviously interested in doing that, and we can discuss the possibility
> of devoting some man-hours to doing that.
>
> Thanks much,
> -Virgil
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Virgil Griffith <[email-masked]>
Date: Tue, 28 Mar 2017 01:20:56 +0800

Hi Ben, pleasure to see you again.

> DNS is used for a lot more than just the WWW.

Indeed.  The WWW use-case is merely what ens.domains service supports at
the moment.

> Are you intending .eth to not be resolvable using standard tools?

We wish .eth to be resolvable using the standard tools.  For this we will
presumably apply for a .eth gTLD from ICANN when they open up for new gTLD
applications around 2020.  However, between now and 2020, we have been
counseled to pursue the .eth name reservation through IETF.  If this is the
wrong approach please say so.

-Virgil

On Tue, Mar 28, 2017 at 1:04 AM, Ben Laurie <[email-masked]> wrote:

> possibility

---

From: "John Levine" <[email-masked]>
Date: 27 Mar 2017 19:06:03 -0000

>wrong approach please say so.

Barring unlikely process changes, ICANN does not allow anyone to apply
for IETF reserved domain names, so you need to pick one or the other.

The recent ICANN process had a 300 page application guidebook full of
rules about everything from business continuity to DNSSEC signing
rules and how your registry deals with the registrars that sell the
names.  The application fee was $180,000.  The rules for the next
round will be different, but I doubt they'll be very different.

The IETF process is, to put it mildly, in great flux.  It's addressed
in the dnsop working group which happens to be meeting in person right
now at the IETF Chicago meeting where I'm typing this.

My main suggestion would be to learn a lot more about both the IETF
name reservation process and the ICANN application process before you
ask for either.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Mar 2017 15:09:48 -0400

> for IETF reserved domain names, so you need to pick one or the other.

I don't know where that is found in the ICANN process documents.  I
think that _happened_ to be true in the last gTLD round, but only by
enumeration for several versions of the AGB (then it was updated with
a reference).  

> The rules for the next

"The next round" is a problematic pointer, since ICANN is in fact
trying to figure out _whether_ before it figures out _when_.

But in any case, I don't believe any of this is a good idea.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 27 Mar 2017 22:56:23 +0200 (CEST)

----- Original Message -----
> From: "Andrew Sullivan" <[email-masked]>
> To: [email-masked]
> Sent: Monday, 27 March, 2017 21:09:48
> Subject: Re: [saag] Hello from the Ethereum Foundation

[...]
> But in any case, I don't believe any of this is a good idea.

I am with Andrew on this.  I believe that you would have a very
convincing arguments why you need TLD for your use-case, and why
Ethereum is so special (all I saw in your email were just opinions).

It seems to me that the reasons for requesting .eth are just pure
cosmetics, as eth.<any_other_tld> would serve you as good as .eth
for experimenting with block-chain zones.

Cheers,
--
 Ondřej Surý -- Technical Fellow
 --------------------------------------------
 CZ.NIC, z.s.p.o.    --     Laboratoře CZ.NIC
 Milesovska 5, 130 00 Praha 3, Czech Republic
 mailto:[email-masked]    https://nic.cz/
 --------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Mar 2017 17:05:08 -0400

> cosmetics, as eth.<any_other_tld> would serve you as good as .eth for
    > experimenting with block-chain zones.

I think, because anyone who has the block-chain data verified, can
authoritatively serve/resolve queries against this zone without reference to
any other authority.

As such, it would be more similar to onion. and homenet., except that the
names could *also* be publically resolvable via port-53.

eth.<any-other-tld>, would be subject to policy whims of <any-other-tld>,
and National Security Letters against <any-other-tld>, which would affect
users who see the data via port-53.

I also think that this zone would have some strange DNSSEC status, because I
don't think we can easily secure it with DNSSEC, and yet it should perhaps
be considered secure.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Mar 2017 17:28:43 -0400

> names could *also* be publically resolvable via port-53.

Since homenet. hasn't reached IETF consensus yet, it seems a
problematic example here, so I'll set it aside.

The "except" above is waving away the important difference here.  The
reservation of onion. is the reservation of an in-band protocol control
switch: if you get a name beneath onion., you're _never_ supposed to
look it up in DNS.  You're supposed to use a different protocol.

The proposed eth. case appears not to do that -- instead it is
specifying a use _in_ the DNS, which means that it's just like any
other delegation in the DNS and ought to be correctly delegated from
the parent zone according to that zone's delegation policies.  That's
not a special-use name.  It's just a name in the DNS.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Mar 2017 18:19:35 -0400

> not a special-use name.  It's just a name in the DNS.

I agree with you.  The *except* matters a lot... and I wasn't trying to gloss
it over.  But, it is *also* a protocol switch that says you can resolve this
DNS name, without using port-53.

I think it's a pretty hairy situation, and I agree that neither ICANN nor
IETF route is appropriate as yet.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "John Levine" <[email-masked]>
Date: 27 Mar 2017 23:09:21 -0000

>not a special-use name.  It's just a name in the DNS.

FYI, Namecoin wants the same thing, and is currently set up so
you can resolve it via OpenNIC.

It is my impression that its main use is for botnet software to
locate control and command hosts.

R's,
John

---

From: Virgil Griffith <[email-masked]>
Date: Tue, 28 Mar 2017 15:01:38 +0800

Thanks for the feedback everyone.  Just as a high-level view, the Ethereum
Foundation's goal is lead by example operating a decentralized, transparent
DNS registry.  Our hope is that after showing a proof-of-concept with .eth,
that future TLDs will follow suit putting their registries on whatever
blockchain-based system they prefer (they are of course welcome to use
Ethereum).

Lets take comments one at a time.

> On Tue, Mar 28, 2017 at 5:05 AM, Michael Richardson <[email-masked]
>
> wrote:

> users who see the data via port-53.

Yes this is exactly our reasoning.  It's also unclear to us how to handle
DNSSEC.

> On Tue, Mar 28, 2017 at 5:28 AM, Andrew Sullivan <[email-masked]>
> wrote:

Okay.  So it sounds like we're better served by ICANN.  Okay, can do.

> On Tue, Mar 28, 2017 at 7:09 AM, John Levine <[email-masked]> wrote:

Thanks!  We'll explore OpenNIC in parallel.  That sounds like a good
stepping stone.

=============

I think for now our best bet to implement what exactly we want within
OpenNIC, and then we'll all have a better idea of where to slot this for
larger adoption.

Thank you everyone!

-V

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 28 Mar 2017 12:27:45 +0200 (CEST)

----- Original Message -----
> From: "Virgil Griffith" <[email-masked]>
> To: "saag" <[email-masked]>
> Sent: Tuesday, 28 March, 2017 02:01:38

> Foundation's goal is lead by example operating a decentralized, transparent DNS
> registry. Our hope is that after showing a proof-of-concept with .eth, that
> future TLDs will follow suit putting their registries on whatever

The problem is that you don't need TLD for demoing blockchain based registry.
You can have a DNS registry at any level of the DNS tree.  The technical
implementation of the domain registry (or it's business model) is irrelevant
to the special use domains applications.  In the .onion case, the goal was
to *remove* .onion from the global DNS space.  Henceforth my opinion is
that you don't have any supporting arguments for IETF SU domain reservation.

>> users who see the data via port-53.

+

> Okay. So it sounds like we're better served by ICANN. Okay, can do.

Those two together doesn't make any sense.  By applying for newGTLD,
you would be subject to ICANN rules, which is exactly the thing you
aim to avoid according to your three-letter-agency fear.

> It's also unclear to us how to handle DNSSEC.

This is irrelevant to SU domains, but ICANN has/had a very strict
rules on DNSSEC for newGTLDs, aka you must offer DNSSEC on newGTLD.

But I leave it absolutely up for you whether you want to spend
180 grand on newGTLD application.  ICANN won't certainly mind
accepting your non-refundable fee and then rejecting your application :).

O.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 28 Mar 2017 09:41:32 -0500

>>> users who see the data via port-53.
 That may well be. On the other hand, if the goal is to demonstrate a
proof of concept, eth.arpa would probably work just fine, and only be
subject to IETF rules.

-- Christian Huitema

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Mar 2017 14:47:25 +0000

> >>> <any-other-tld>, and National Security Letters against
> >>> <any-other-tld>, which would affect users who see the data via port-53.

NSL's (at least the US/American kind) don't care about the name in the domain.  They only care about if the controlling organization is subject to US rules.  So that would leave out arpa

I find the concept of a blockchain-based DNS worrying about NSL's a bit amusing.

As this is just PoC, pick any darn domain and see.

---

From: Ross Schulman <[email-masked]>
Date: Tue, 28 Mar 2017 17:03:38 +0200

Perhaps this conversation would be better served if Virgil could 
chime in with what Ethereum wants to accomplish in the short and 
long term, which would give us at IETF and ICANNthe ability to 
suggest best courses of action. I think generally speaking we 
should not be reflexively hostile to means of integrating DNS and 
blockchain if we can see a way to make the two work together.

-- 
Ross Schulman
Co-Director, New America's Cybersecurity Initiative
Senior Policy Counsel, New America's Open Technology Institute
[email-masked]
202-986-0427

PGP: 4D20 3824 9463 34C5 37EF  FB0C 5A05 EB1F 5BBE 56EE

---

From: Virgil Griffith <[email-masked]>
Date: Wed, 29 Mar 2017 13:37:01 +0800

Thank you Ross.

In the short term, the Ethereum Foundation is interested in:
* Making "smart-contracts" on blockchain-based systems more accessible.
This basically just means giving them all URLs.  We currently partially
have this with ens.domains, but we are unsatisfied with this because (1)
it's such a hack (2) for such an infrastructure service, we'd prefer not to
rely on the operator of the TLD .domains.

In the long term, we argue that, relative to a trusted third party, public
blockchain systems are more transparent as well as less prone to abuse by
said third party.
* For operators desiring those properties, we wish to demonstrate, by
example, how to do so.  For example, we would be immensely pleased if a
future gTLD, entirely unrelated to the Ethereum Foundation, inspired by our
success, decided to use a blockchain system for its registry.
* Beyond DNS, there's also talk of using blockchain-based systems for
storing BGP routes, but this is much less developed---so lets just stick to
DNS.

These are our goals in the short and long term.
-Virgil

On Tue, Mar 28, 2017 at 11:03 PM, Ross Schulman <[email-masked]>
wrote:

> Perhaps this conversation would be better served if Virgil could chime in
> with what Ethereum wants to accomplish in the short and long term, which
> would give us at IETF and ICANNthe ability to suggest best courses of
> action. I think generally speaking we should not be reflexively hostile to
> means of integrating DNS and blockchain if we can see a way to make the two
> work together.
>
>