On Mon, Dec 20, 2021 at 6:15 PM John C Klensin <john-ietf@xxxxxxx> wrote:
Hi.
Aside from the more substantive content of the suggestion,
including whether this could actually be done and all costs
covered for one time charges of USD 0.10, I see three major
concerns / questions that you should probably address:
(1) Why .ARPA? In addition to the concern Nick raised, my
recollection of the agreement between IETF and ICANN is that the
TLD is supposed to be used for _network_ infrastructure, not as
a cheap substitute for a gTLD. Granted that boundary has been
pushed a bit in the past, but what you are talking about sounds
like personal identifiers and definitely not network
infrastructure.
Because it is the TLD that has been traditionally used for permanent delegations.
When I was originally thinking of this scheme, my expectation was that ISOC would divest itself of the .NET registry and the massive conflict of interest that creates for IETF.
As far as my approach goes, mesh.arpa is a lot costlier to me (an RFC at least) than .mesh (free as in beer).
(2) Assuming the IETF went along with this (and ICANN did not
have a fit about their perception of the agreement), what would
be the acceptance or rejection criterion for whenever the next
such request came along? In other words, when someone proposed
a different scheme for, say, "hsem.arpa." or "tangle.arpa."
rather than "mesh.arpa.", what criteria would the IETF use to
accept or reject it? Equally important, when a fight breaks
out as to who is the real Alice, or, as in the mistakes that
were made in the delegation of the NAME TLD illustrate, who gets
to administer the *.alice.mesh.arpa" subtree? Given that, at
least in the absence of some complex administrative adjudication
procedure (like ICANN's UDRP), debates about "who is the real
Alice" tend to attract lawyers, some of whom find our theories
about DNS delegations and delegated authority inconvenient, how
would you propose to protect the IETF (or the IETF LLC) from
becoming enmeshed in such disputes? If nothing else, that set
of issues might be a strong argument for "mesh" second level
domains underneath ccTLDs: countries are, if they choose to get
involved, good at determining the legitimate owners of a name
and associated attributes and can immunize themselves from
disputes about those questions in ways in which the IETF or your
hypothetical non-profit probably cannot.
There are really two separate sets of issues there.
First there is the 'how does a registry shift the cost of the inevitable disputes onto the parties with the complaint'. I am very familiar with that whole process, it was a major concern for us long before VRSN bought network solutions. I was also heavily involved in the 'how does VRSN operate a PKI and not get sued into pieces' which Michael Baum spent a lot of time working on.
The short answer is that obviously @microsoft has to resolve to Microsoft Inc or really bad things start happening besides the IP issues. And so you have to have a process, you can't just ignore it (one reason most proposals are non starters). But once you have a process and you tell the courts that you will abide by their decision, there are ways to control/contain the liability.
But it doesn't eliminate the issue and there is the risk of the liability leaking up the chain as you observe. So that probably seems to rule out .mesh.arpa.
Fine, I will use .mesh
(3) The DNS was not designed for, and has never been good at,
handling very large zones (independent of the level of the tree
at which they occur). In the last couple of decades, throwing
some database technology and a great deal of computer horsepower
at the DNS has increased the plausible maximum zone size by
several orders of magnitude over what I believe were the
expectations in 1987 or even 1994, but the fundamental problem
remains. Perhaps I don't understand your explanation and
example, but if the subnodes of mesh.arpa are going to be
callsigns bound to people and this model is successful, then you
are talking about a zone with four or five billion nodes in it
today (and growing). I can think of some plausible ways around
that, perhaps including your idea about separating the resolver
function from that of a registry, but they fall well short of
"respects the DNS data model" and the computationally intensive
versions would, at scale, causes Alice's coffee to get rather
cold before she could drink it.
I have always regarded the DNS hierarchy as a blunder. All that dividing the root zone has meant is that instead of there being one place to reserve a name, there were first three and then a hundred and now thousands and they are all primarily rent seekers.
The registry log will grow by less than 1K per entry. So a billion callsigns is only 1TB. I have built very big iron but this is really not that demanding. The registry can run on a regular PC, I have run simulations with millions of add operations an hour using magnetic disks and would definitely use SSD in production.
Resolvers can run incrementally. They can process the log and map out to a lookup table mapped out on SSD. Haven't written one yet but it's really not much of a concern. Updating the mapping table can be parallelized and resolution can be parallelized if needed.
Unlike in the DNS system, the resolver service is not provided by the registry. That immediately brings robustness. Taking out VeriSign's ATLAS brinds down DNS for the whole Internet. If Verizon, Comcast and such all ran their own resolvers that did not depend on connection to the registry, the incentive to abuse the DNS root and TLDs would be very much reduced. Further, the providers can limit external access or shut it down completely if they come under attack. They have much more ability to control abuse coming from the inside.
Taking out the registry will be challenging. The attackers would have to find it first.
best,
john
--On Monday, December 20, 2021 13:28 -0500 Phillip Hallam-Baker
<phill@xxxxxxxxxxxxxxx> wrote:
> TL;DR; I have two ways of achieving my desired end. One of
> which people are not going to like, the other of which they
> are totally going to hate. I do not actually require IETF
> permission for either, nor am I the only person thinking along
> these lines, I am merely the person whose approach is least
> likely to result in collateral damage, consider responses in
> those terms.
>
> I have been following various naming proposals in the
> PonziCoin world for some time. There are many companies who
> for a mere $10-200/year will register a shortname for your
> ethereum wallet so people can give you money. And of course,
> the cost of ethereum gas for making the payments only makes
> the cost even stupider. But don't worry, there will be a
> technical fix for that the minute they find themselves a
> virgin and a unicorn.
>
> OK, so those proposals are obvious nonsense but the notion of
> using a Certificate Transparency type log to issue names for
> life on a first come first served basis is not. Hence my
> callsign proposal:
>
> https://www.ietf.org/archive/id/draft-hallambaker-mesh-callsig
> n-01.html
>
> [A very similar proposal has been made to ITU by the Chinese
> delegation under their 'New Internet' scheme though I only
> became aware of the details of that after I wrote my own. It
> is my belief that the primary motivation behind the ITU
> proposal is to prevent the abuse of DNS as a control point in
> the Internet infrastructure.]
>
> Running infrastructure costs real money but I see no reason
> for the cost of running the infrastructure proposed to be more
> than a one-time $0.10 per name. No renewal fees. Names are
> sold freehold, not rented.
>
> The objective here is to give Internet users a name they can
> use for life. And yes, I realize that it is impossible to
> collect $0.10 fees so I plan to sell names in packs of 50 or
> so. So for the price of a pint of beer you can buy a permanent
> callsign for yourself and pass out the means to grab one to
> your friends.
>
> There are of course many social issues to be considered, not
> least of which where does the surplus go. My proposal being
> that the whole show to be run by a not-for-profit and the
> surplus go to fund open source development of secure Internet
> software, specifications and standards.
>
>
> But that is not the part I want to talk about right now. What
> I do want to talk about is how a new naming scheme interfaces
> to the DNS so that it can be used to connect to legacy
> applications. Legacy in this context meaning 'the stuff that
> is working'.
>
> So Alice registers the callsign @alice and can use that in
> messaging applications that understand the callsign scheme.
> Which is not hard, just hook up to a callsign resolver and
> send over a query. As with blockchain, the resolver maintains
> a complete copy of the log. Queries go to a resolver, not the
> registry. This means far greater robustness than DNS and
> offloads almost all the cost from the registry.
>
>
> But what about that doorbell, that WiFi camera, etc. that
> Alice has? To talk to them she needs to use her browser and
> that runs HTTP.
>
> The obvious solution for this is to put a statement in the
> delegation assertion for @alice to specify an authoritative
> DNS resolver for the DNS addresses *.alice.mesh. The callsign
> resolver then delegates to the authoritatives. The net result
> is that all Alice needs to do to resolve these names is to use
> a DNS resolver that redirects requests in .mesh to one of the
> callsign resolvers.
>
> The net result is a protocol that respects the DNS data model
> at the lower levels while modernizing the root level.
>
>
> OK so nobody expects me to pay to register .mesh. I am not
> even going to lift a finger to make a proposal to ICANN.
>
> But I am not the only person making a proposal in this area
> and while a single pirate TLD designed by someone who knows
> something of what they are doing is likely to be amusing, a
> hundred or more is likely to be less so.
>
> Which has me looking at .ARPA instead.
>
> Having Alice type http://coffee.alice.mesh.arpa/ instead of
> https://coffee.alice.mesh/ is not as nice but she will live
> with it. or if open callsigns win the naming game, the anybox
> in her browser will probably let her type coffee@alice and
> route to the place she expects to go.
>
>
> Problem here is that RFC 3172 was written in a different era
> when people were still frightened about the loss of control.
> The notion that registries are not control points had not yet
> been understood.
>
> So which would people prefer for the pseudo-delegation?
>
> alice.mesh or alice.mesh.arpa?
>
> This would be a reservation in .arpa, not a delegation.
>
>
> PHB
>
>
> (Oh and yes, I do have a browser implementation thanks to the
> heroes who developed WebView2 at Microsoft. It's Windows only
> at the moment but should be fixed with MAUI.)
>
> (Oh and yes, I do understand how complex naming gets, I
> watched it all happening in real time.)
