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

"Schanzenbach, Martin" <mschanzenbach@posteo.de> Thu, 04 August 2022 16:01 UTC

Return-Path: <mschanzenbach@posteo.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C246BC13CCDB for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2022 09:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTgiyKLVrfpe for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2022 09:01:24 -0700 (PDT)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B08C14F5E1 for <dnsop@ietf.org>; Thu, 4 Aug 2022 09:01:24 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id F16AE240026 for <dnsop@ietf.org>; Thu, 4 Aug 2022 18:01:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1659628881; bh=aqNEGdPR9OjwblfZ4JuTnAAPeaZtR/+pyAdgV6/ofPA=; h=Subject:From:Date:Cc:To:From; b=mgZaNDHt8Tq3TPjC6gL1fFJAHIzU5kzx3zLfjc+QC8Ny/lOxGfAULP0PUqsUXDJDH O/YuKCQvukqf081GZ/wFs9ZG3Cg2WZj81GWbhETTfFFmrlOh0PjeF+wHQTTgqhkMSG FKuxlMzksY0qBHEpEob4LBx+dnr4dP1jWRx0VeGqhruL2s2a9KDCuWuq/uFJdtO7p/ 1uCYJIB5nYlxkToYUga2bRPtmrhV8hp1WqLLOAtI0qWzO/UjXnRBG7kLY90fzjUooL wuACCeZnneeiYPH7+yYkfCzQIRxAxEVfkUWoCqScpYTcGviwoXixP/7+F0Xg6ekFe0 ls/Z6aTYvyPMA==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LzD3z435Kz9rxH; Thu, 4 Aug 2022 18:01:18 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7B5F66D0-6D18-4D55-A382-75EC434F11F4"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: "Schanzenbach, Martin" <mschanzenbach@posteo.de>
X-Priority: 3
In-Reply-To: <595181228.6895.1659622649037@appsuite-gw2.open-xchange.com>
Date: Thu, 04 Aug 2022 16:01:14 +0000
Cc: Independent Submissions Editor <rfc-ise@rfc-editor.org>, dnsop <dnsop@ietf.org>
Message-Id: <0F155C86-71D5-49AD-807F-D27314964574@posteo.de>
References: <91abb9ac-9d3b-87bf-5639-174581d625fd@rfc-editor.org> <YufxYmxz9L8zG9hS@nic.fr> <1659368624-sup-8402@werkbank> <CAH1iCirbMBqSkE_+bTtWisEm_LxXj-3n2d1F1qL67_X+U7v7Jg@mail.gmail.com> <1659591584-sup-6027@werkbank> <39865554.5880.1659614798712@appsuite-gw2.open-xchange.com> <DEE9FECE-2647-4B8B-A64A-6D6E0E25F3FE@posteo.de> <595181228.6895.1659622649037@appsuite-gw2.open-xchange.com>
To: Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FB-1gNttHLKLZccOGrOazNxBZdo>
Subject: Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 16:01:28 -0000


> On 4. Aug 2022, at 16:17, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org> wrote:
> 
>> Il 04/08/2022 14:37 CEST Schanzenbach, Martin <mschanzenbach@posteo.de> ha scritto:
>> 
>> You are trying to kill it using, what, political arguments?
> 
> Yes. There is nothing technical in this discussion. We are not arguing over wire formats or algorithms, we are arguing about names and ways to gain control over them, i.e. policy.
> 
> Indeed, many outside of the IETF think that the IETF does not even have the authority to approve anything like what you are proposing. (Don't mention .onion, it was a mistake.)

But the resolution protocol is technology-neutral. I invite you to re-read the draft. We are not proposing a namespace.
The possibility for the user to modify local configurations is as benign as a modification of /etc/hosts or Nsswitch.

> 
>> Is the DNS namespace and its billion dollar industry so fragile that it cannot handle experimental alternative domain name resolution mechanisms that may be used for resolve "DNS-compatible" names as well?
> 
> If your proposal:
> 1. does not allow the creation of new DNS names (TLDs or others) outside of the established registration policies;
> 2. does not allow to redefine, redirect or control names that already exist in the DNS namespace;
> then it is an "alternative domain name resolution mechanism".
> 
> If it allows any of the two functions above, and as I understand it does, and does so in a way that can be shared across the global Internet, then it is not a resolution mechanism but a namespace expansion and even a new name creation policy, and also it does potentially fragment the Internet.

The draft does not "allow to create/redefine" names. Its a protocol for name resolution and zone management/publishing.
You can do a 1:1 mapping from the current governance (ICANN) with a GNS technical infrastructure.

> 
>> And if the IETF is, as you insinuate, some kind of guardian of that industry that relies on the existing infrastructure, what chances would any proposal have going through the respective processes in the future?
> 
> Zero. But you seem to think that the IETF is required to approve whatever proposal it receives, and it is not, even in the independent submission stream.
> 
> Still, you seem to miss my general point, which is not about what I may think of your objectives (indeed, I hate centralization as well, though this is one of the few centralized arrangements for which there are valid reasons).
> 
> My point is that you cannot plan a revolution and at the same time ask parts of the system that you are trying to overturn to rubberstamp it.

We are not asking to rubberstamp.
We proposed this protocol to the IETF and there was no WG interesting in technical discussions. Nevertheless be believe (and were told by a lot of individuals) that the idea and protocol has technical merit.
Which is why we then brought it to ISE.

> 
> If you want the stamps, then you have to turn the revolution into an evolution and accept some compromises, such as "!gns" or whatever else. It may actually be a more productive strategy in the long term.
> 
> If you want a revolution, then you have to be prepared to fight against the system. I easily see people in several (non-EU) countries getting the police at their door if they start using your system for the purposes that you declare right at the top of your draft. That's just how the world works.
> 

If you say that the security issues DNS (still) has are a feature and not a bug, then I have to respectfully disagree.

BR

> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop