Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Brian Dickson <[e-mail]>]

On Wed, Aug 3, 2022 at 11:40 PM Martin Schanzenbach <[e-mail]>
wrote:

> Excerpts from Brian Dickson's message of 2022-08-03 18:09:32 -0700:
> > Top-reply (not apologizing for doing so, either):
> >
> > If I read the actual draft correctly, it is _not_ intended to be a DNS
> > drop-in replacement.
> > Instead, it is meant to be an _alternative_ to DNS.
> >
>
> It is intended to resolve RFC8499 "domain names".
> It could be used as an alternative to DNS to resolve DNS domain names.
> If you want, we can make that clearer in the draft.
> Actually, I have been pondering over that the last few days.
>

There is quite a lot in your draft that is missing, e.g. compared to the
[GNS] reference in the draft.
That [GNS] explicitly includes references to "pseudo-TLD" entities ".gnu"
and ".zkey".
I'd suggest omitting those makes the draft sufficiently incomplete as to be
impossible to evaluate in the current context.


>
> > So, why even use DNS-compatible label strings? That is an obviously
> > conflict-causing choice, which is entirely avoidable.
> >
>
> Any (most?) domain names are DNS-compatible label strings.
> How come that is no problem elsewhere?
>

This thread is concerning your draft, and your draft alone. "elsewhere" is
entirely irrelevant.


>
> > Most of the references in this thread to IETF documents or ICANN
> documents,
> > are within the context of DNS-compatible naming schemes, that themselves
> > lead to such conflicts.
> >
> > The obvious choice, to me, would be for GNS to use a DNS-incompatible
> > suffix, that is short and memorable in some way.
>
> Please. The obvious choice is RFC6761.
>

GNS is your project, your design, completely controlled by you.
The decision to make GNS allow users to create GNS names that are
indistinguishable from DNS names is yours.

That possibility is what leads to all of the problems you are complaining
about.

You have built yourself a "bear trap", and then walked into the bear trap,
and complained about being stuck in a bear trap.

Nothing in the Introduction of your draft establishes a strict requirement
for GNS names to be indistinguishable from DNS names.
It appears to an uninterested reader that you want this
indistinguishability rather than need it.

Am I missing something in the logic you use for reaching for
indistinguishable names?


> You are hand-wavingly proposing to cripple the usability of the names
> used in alternative name systems below which would also require us to
> define
> in the draft what we mean by "name" instead of being able to point to
> RFC8499.
> How is that better than an established process that was applied very
> recently. Twice.
>

8499 definitions for Label and Domain Name do not restrict themselves to
the syntax required by the Global DNS.
You can mean name and label and use those definitions, without restricting
yourself to letter-digit-hyphen syntax.

I'm not suggesting all the labels be distinguishable from DNS labels.
I'm suggesting GNS use Domain Names which are possible to distinguish from
DNS names at a strictly syntactic level.

E.g. "Is the last character of the Domain Name equal to $GNS_THING? If so,
resolve using GNS. If not, resolve using DNS."

This is a suggestion, which you can use or ignore as you prefer.

Using that suggestion removes any and all conflicts, and makes all of the
IETF stuff moot (specifically the 6761 etc stuff).

I offered a variety of single letter terminators (to the GNS Domain Name)
that might be adequate, but which is by no means comprehensive.


>
> >
> > (That rules out .alt  and something.arpa obviously, and probably anything
> > that starts with underscore or even contains the asterisk character).
> >
> > So, pretty much pick any other UTF-8 string that is not a potential DNS
> > label, and is easy to type, short, and unambiguously "NOT DNS".
> >
> > Choice is left as an exercise to those wanting to paint the bike shed.
> >
> > The mnemonic of "!" would be clear, meaning "not", or possibly "~",
> > which is a different kind of "not", or even "^" as another "not".
> > Other non-shift key candidates ",/=;" or any of "[]\`'" (but less
> favorable
> > due to interaction with the unix shell).
> > Similar one-character shift-key options have various
> > pros/cons: @#$%&():"{}|<>?"
> > Basically, pick any of the above, but not any of ".+@-_*", and you are
> good
> > to go.
> > If it makes a DNS resolver complain, it is a good choice.
> > (Even "**" would be okay, as it is not a legal DNS label.)
> >
>
> The reason is usability and the often in this discussion invoked "user
> expectation". A "." is just a lot easier to type, everything you propose
> not only looks awkward but is also difficult to type.
> Not to mention that a lot of applications that use domain names
> expect domain names.
>

You are conflating the term "domain names" here, to avoid clarity.
If you mean to say, "applications that use DNS domain names expect domain
names syntactically identical to DNS domain names", then say so.
I don't think anyone would disagree with that statement.

I daresay that the DNS community does not particularly care about the
usability of GNS names, generally speaking.


>
> > At which point, no conflict exists, ISE and DNSOP are all happy, your
> draft
> > can be published (with the proviso that this suffix MUST be used always)
> > and we can stop having this discussion, permanently.
>
> Should that[1] be(come) consensus/the outcome of the IESG review I think
> we need
> to discuss internally if we'd rather take the conflict as that would
> significantly change the purpose of GNS.
>

The purpose of GNS as specified in the draft you submitted does not appear
to require use of DNS-compatible names.
Not using DNS-compatible names does not appear to impact the purpose of GNS
as described.
It might alter the ease of implementation and use.


> Such an outcome would likely also stop this discussion permanently I
> think. I guess you should get rid of RFC 6761 as well then at some point.
>
> Please note that it is not us requesting a sub-namespace or TLD with our
> draft.
> Our current version of the draft proposes a technical protocol to resolve
> domain names as defined in RFC8499.
> Whether a deployment uses a sub-namespace or not is not really relevant.
> In my opinion (but that is something that could be discussed), it is also
> a lot
> cleaner to define the protocol in such a
> way and not assigning a namespace along with it.
> But, we would be happy to accomodate concerns regarding user safety
> and namespace consistency *within reason*.
> Note that .alt would not make it clear for an implementation if a given
> name can or should be resolved in GNS as currently there is no registry
> for the
> subdomains proposed.
> So, while being adamant that this is a problem in DNS, it seems odd that
> it would not immediate also be a concern for GNS.
> In practice, I concede, this may not be a problem.
> But in practice, I think the "DNS namespace in danger" discussion is
> smilarly not
> a problem.
>
> Anyway, going to ICANN in order to collect a TLD is not a reasonable
> process for
> publishing our draft.
> We would not even know what the process would be (after the RFC? before
> writing it? While writing it? What if ICANN denies a request? All the
> work is moot?)
> Similarly using "www.example.com!gns" et al. is not a reasonable change.
> As that impairs usability and is incompatible with applications that
> expect domain names.
>
> BR
>
> [1] "that" being that alternative name systems are not welcome and are
> required to bake into their technical specifications "poison pills" that
> make them unattractive to use.
>

If you change your statement to "are permitted to" instead of "required",
it is closer to my personal opinion of a better approach.
I'm not sure how it makes them unattractive to use, other than applications
needing to have support for GNS added to them.

There is no such thing as a free lunch.

There is no such thing as "policy neutral" when your proposal is supporting
usage of GNS names that conflict with DNS names.

Either your policy is Global DNS (aka ICANN) friendly (not permitting GNS
names that could conflict with DNS names), or it is not.
In the case of "not", that means it is unfriendly to Global DNS (aka
ICANN), with all that entails.
There is no middle ground.
If you do not allow names that can be parsed as DNS names, the whole issue
is moot. (I'm pointing this out to you, and suggesting methods of doing
this, to help you out here. Caveat emptor.)

If you do allow names that can be parsed as DNS names, some method is
required to distinguish "real" DNS names from GNS names, or you are
explicitly endorsing the use of squatting on portions of the DNS namespace.
(I'm not the one saying this, I'm summarizing the various messages from the
thread for your convenience. Your argument is not with me, it is with
everyone else.)

These issues really are black and white.
Saying you are not getting involved in policy won't persuade anyone.
What your spec supports *is* the policy issue.

Brian


> >
> > Brian
> >
> > On Mon, Aug 1, 2022 at 10:11 AM Martin Schanzenbach <
> [e-mail]>
> > wrote:
> >
> > > Excerpts from Stephane Bortzmeyer's message of 2022-08-01 17:29:38
> +0200:
> > > > On Mon, Aug 01, 2022 at 02:31:48PM +0200,
> > > >  Independent Submissions Editor (Eliot Lear) <[e-mail]
> >
> > > wrote
> > > >  a message of 89 lines which said:
> > > >
> > > > > Whether that means using TLD labels that begin with _ or whether
> > > > > that means suffixing them with ".ALT", I leave to you experts to
> > > > > sort.  I do agree with Martin that it would be helpful to have some
> > > > > registration of names so that conflicts between name spaces can be
> > > > > avoided.  This would also encourage formal documentation of those
> > > > > projects.
> > > >
> > > > I agree and I think publication of these drafts would be a good idea
> > > > (may be with status Experimental since, as Joe Abley said, there is
> > > > clearly no IETF consensus). Note that I am skeptical about their use:
> > > > most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol
> will
> > > > not read the RFC and, if they do, won't follow it. But at least we
> > > > will be able to say that we tried and we have a solution (and not a
> > > > ridiculous one such as "pay ICANN 185 000 US $").
> > > >
> > >
> > > tl;dr:
> > > I am a bit ambivalent towards the ".alt" approach.
> > > For alternative name systems that are specified with status
> > > "Informational"  the use of ".alt" seems highly unattractive as there
> is
> > > absolutely no benefit in using it but at the same time there are
> > > (obvious) disadvantages especially compared to other name systems which
> > > do not (try to) publish in the RFC series.
> > >
> > > ---
> > >
> > > Reasons:
> > >
> > > With our draft you would have one system which references
> > > this "solution", as opposed to specifying solution looking for a
> problem.
> > > That being said, since our current draft is Informational, I do not
> > > think the existence of an ".alt"-RFC would significantly alter our
> protocol
> > > implementation or deployment for now.
> > >
> > > There is just no benefit for a name system in using it. The benefit
> lies
> > > solely with DNS and the existing infrastructure.
> > > After all, a new "Standards Track" name system that could potentially
> be
> > > used as
> > > a DNS-drop-in would not be designed or specified using ".alt", right?
> > > That would be like requiring DoH servers to only process names under
> > > ".doh.alt".
> > > But they do not and never have, because even though the technical
> > > resolution process is different, it is still the same namespace.
> > > So what if (yes I know very theoretical) ICANN and TLD-registrars
> > > publish their zones in GNS? Is it still www.example.com.gns.alt or
> would
> > > it be the _same_ namespace managed by the _same_ authorities resolved
> > > through GNS and become www.example.com?
> > > If the latter is the case, what is the purpose of ".gns.alt"?
> > >
> > > Further, migration becomes more difficult with ".alt".
> > > For example, is it possible to get X.509 certificates issued for those
> > > domains?
> > > Not to mention that users have to deal with (significantly!) longer
> names
> > > as you need a
> > > second-level indicator on which name system is asked for.
> > > e.g.:
> > > www.example.com.gns.alt vs
> > > www.example.com
> > >
> > > So unless IESG actually finds a conflict and we have to put it in the
> > > specification as a requirement, I don't see why we (GNUnet) should use
> it
> > > at all in practice for our implementation.
> > > Since our draft is Informational, I also do not see any urgency.
> > > But, I think it makes sense to have provisions in the draft that
> > > discuss this issue and show how *in a deployment* this possible
> namespace
> > > ambiguity may be avoided using ".alt" independently of how the
> currently
> > > documented implementation operates.
> > > Maybe we would add a ".alt"-RFC-compliance configuration option that
> > > limits resolution to ".gns.alt" etc. (there would be no reason for any
> > > user to set it, realistically)
> > >
> > > Really, though, all this was just a matter of following RFC6761 IMO...
> > >
> > > BR
> > > Martin
> > > _______________________________________________
> > > DNSOP mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/dnsop
> > >
>