[GNU/consensus] Special-Use Domains Names (follow-up)

[hellekin]

Greetings,

there are a few days left to consider which of two problem statements
will be used to continue the discussion on Special-Use Domain Names.

If you lack context, please read the last section.

## Current Actions

Suzanne Woolf, chair of the DNSOP IETF WG recently proposed the WG to
choose between two problem statements in order to revise or replace
RFC6761.  Interested members can read them and reply to the mailing list
thread: "[DNSOP] moving forward on special use names".

The deadline for reviewing the drafts is set to **September 25**.  You
should send your response directly to the DNSOP list.

The drafts are:
- <https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/>
-
<https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/>

John Levine proposed to distinguish "Internet Names" according to their
specificity: (quoting)

* Names resolved globally with the DNS protocol, i.e.
  ordinary DNS names

* Names resolved globally with an agreed non-DNS protocol, e.g.
  .onion via Tor

* Names resolved locally with an agreed non-DNS protocol, e.g,
  .local via mDNS

* Names resolved locally with unknown protocols, e.g. .corp and
  .home, the toxic waste names

In GNU consensus we've been working with the second category, namely
.onion, .i2p, .zkey, .bit, and the third category, namely .gnu and
.exit.  When reviewing the drafts, please look out for the preferred
outcome (being able to reserve these names on **technical** grounds, via
IETF processes.)

## Special-Use Domain Names of Peer-to-Peer Systems

TL;DR Christian Grothoff presented the issue at IETF93.
      https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-5.pdf

In 2013, a group of people from various P2P free software projects
gathered to produce an RFC aiming at reserving 6 specific Top-Level
Domains using the provisions of RFC6761.  The first draft of this
document was published on November, 14, 2013.  After more than a year
and 4 draft revisions, it became obvious that we would not achieve our
original goal of recognition of the involved P2P systems (GNUnet, I2P,
Tor and Namecoin) in one block.

See:
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names

Jake Appelbaum took on himself to spin off and create a draft only for
.onion in collaboration with Alec Muffet.  Although this broke our
strategy of unity, it took advantage of a time constraint with the
Browser Forum, a consortium of Web browser and SSL certification vendors
who had put a hard deadline on the acceptance of issuing only known
domain names in commercial certificates (to prevent some forms of
abuse).  Despite some flaws (e.g., users are expected to know that
.onion is not a DNS name) it was successful in achieving IETF consensus
and is now part of the Standards Track as RFC7686, making your Tor
services valid candidates for commercial SSL certificates.

IOW, you can ask Gandi to deliver one SSL certificate for your
personal.example.com that is also available through Tor via
https://omfg1ms0lucky404.onion/, but you cannot have this certificate
include personal.example.corp that you use inside your organization
(because .corp is not a registered TLD at IANA, but .onion is, even if
it does not resolve via the DNS.)

ONION was the last Special-Use Domain Name (SUDN) to go through the
fuzzy procedure described in RFC6761.  Other SUDNs, including .bit,
.exit, .gnu, .i2p, and .zkey are waiting for the current process to meet
its resolution.  As always with IETF processes, anyone can participate,
that is, if you have the time to read two dozen RFC documents, a dozen
more SSAC documents, read the DNSOP list and take the time to reply.  I
still believe this is worth it, and someone should do it (preferably
more than one person :), so we get recognition for these P2P systems.
So I invite those of us who are acquainted with the IETF processes, or
who want to, to get involved in supporting this effort.

Thank you for your attention,

==
hk