Re: [Secdispatch] GNU Name System

Christian Grothoff <grothoff@gnunet.org> Tue, 21 July 2020 22:07 UTC

Return-Path: <grothoff@gnunet.org>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135D43A0AFE; Tue, 21 Jul 2020 15:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJsHWjTCY2v7; Tue, 21 Jul 2020 15:07:16 -0700 (PDT)
Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43D173A0AE9; Tue, 21 Jul 2020 15:07:15 -0700 (PDT)
Received: from fencepost.gnu.org ([2001:470:142:3::e]:36979) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from <grothoff@gnunet.org>) id 1jy0Po-0004UG-Kj; Tue, 21 Jul 2020 18:07:12 -0400
Received: from [2001:1620:fe9:0:7285:c2ff:fe62:b4c9] (port=48230) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from <grothoff@gnunet.org>) id 1jy0Ph-0001VQ-KL; Tue, 21 Jul 2020 18:07:12 -0400
To: Michael Richardson <mcr+ietf@sandelman.ca>, "secdispatch@ietf.org" <secdispatch@ietf.org>, "draft-schanzen-gns@ietf.org" <draft-schanzen-gns@ietf.org>
References: <31625.1595368614@localhost>
From: Christian Grothoff <grothoff@gnunet.org>
Autocrypt: addr=grothoff@gnunet.org; prefer-encrypt=mutual; keydata= mQINBFSG/g0BEADfUtc2WA8+OWiNVuNuaU5CIFB/6Netaem0tXAc5VF8c/Dr/BbteSG4ZAWg CGioO/sqQ08XbYSdot1/zybFqAaD2Tlz99+GFLDYSMSDv6SkaAww0cGbobjkAO3h1ojeR8gw j2+V2DuM9VLsmB0ITH3zXlLg1wbDUeIpOtk12DWqOTFN0v6xhV3JVdFsMmiM21iyo14FIxZm RTJulrwQFi/LcrUR7kDSjuwv3GzmVy6KSArri6fSZec4os6WJM69+N3kV3SwoWxjikfUodaF +kOMXRyfEDX2ebyvveIvMl2BxNu7JUnFY0AHXnxeNbfkpLCuFnH4cVvK14I+hHOa/JTnF77f 7sWb+E0588YLL7geWucJfw94OzM1z4l/BLSyYiY3PJWRUHwkY7FV3cQGgTfrvbX3afa9Vi2b KHbgsgnOpe55FFJTRhZlGJMrgeNsoRKeivFaSa3HLhkV56VG268IM7iao+soVfeWKTOOSQGV eG6VrY7MUjhNfBbYfuSOW9CdF3p3XbI8DF68id0OQRUIihS42+kSGCZVY31Mx8+bZj+7+Qhs hZrARdrdmDg5IvJykEpn7aKpfyhf1sCfu/gwrpZ90IcaYoeafk6qWcf8JL+5VYHewWjfZ7pF tlurt+hlrdNbqDQ9oHtIsevbgsPlh40BZ0kv2vLK5b+hQ5gd3QARAQABtChDaHJpc3RpYW4g R3JvdGhvZmYgPGdyb3Rob2ZmQGdudW5ldC5vcmc+iQI4BBMBAgAiBQJUhwfWAhsDBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCTnmvh4p/DzLo3EADDO4FO9ZSwG2dWMVqzSflJF2G1 SdNS0AnzP1B7YBv6WNqjtwDhYbo4txZiz+R3e0RSguhcURHCa1EVsTErBU9zHV9+p0mGJ310 rhst3Q54pXdQSVAU8wteKjghRoX+Tn0dldVfowRdYNHYb+g1ReuDc6V7yZV3/T3dQMOg4MTj ZbZGAF5qaYTmB8Tofuv5xtsqoXkj0h71qEMEbBbkekjZwYW35awloFfIEXFAM6d6ZBHDQ+TJ oTZN+RGAvSzirGTKhhS91vDsJ94DaoPiWtqaQm55cBxYZY/UMDSfGlsvkZDqGeT+aL/uBnvL O3KinYPCtYRbVzaEtaJ1r+CsZknB9eDuG7kuzVHMI8HkyqD/CaTKc5qk5a28vPvcbkupZzsr qJDu/e3CD16cJStwhLM79+CVp/ihDUS8yGiBS76ROfwOqI6niWw+oti7oGieb3QIxnRqYxDU b6UOe0mvGcrwxdrin1StvcW9HVghrvN4Mx+Ec1Us7SOcrybdL6ILgu9zMJTFJemPiuL6AGZL mzJ3m3uTu10WkqmG6Rj4fU5t7vBzNtFdj3E637jSMH2Fgkz3Athrad4+9tMBlvJXpzNJvYZ2 EzAIXLNYOCI5Cjhz5DguSIBJYc1EzTgwCPQv4w0Qg5aik9De24DHaghsdXrI3L1k78m88kjd vBzu3fmEzbkCDQRUhv4NARAAoi0SvMUnd5XSZVSmbwfge2p9KeGVVcaz99fgrUTgCwfovVd1 MEXh8FCtxja4xZiuwSGUARuPAXpzhcK1L9vai25GV+y4SALp3wg1/GrsHtEsm+wm7AeIq0ut XnjfnUzfliIIKwt0aGW/zGp/8rHNKh7JVUo0mPSMQfe+6tE2XOnuGDHj1ZyZalmBjVLJYMws I0tfAzU1fa0MOSnhvyP5TFFj6PWKSajEOsFuIR/zceZFtJbN24lbXYwohBDBY2Ajb0y8uYBi /h350UY2mwjKHYM3mxJD3AogWIBz5HD+ueWGUTBpKwLYmN7zVxDMdL7FqGonSw9NV1XxJ3IN 1DYPPdFKStRIUiSMzyj/pp6410ms+N1MtPXDIDdcOcmNHqcnkWqBYHXGi+sYyFpe+825N75d otpEipCnIcTCBjn3RdqFOzT4+airtL7eOkzmooqtPwvNO+4Uza8+W1PLibXqXWqD0uyi1Wn2 9asF+uOEfNA4TpTXT6Df5B1X88eoHccCpPUhiNqs7dX1ye78m9oicD9IoXj3PZ0le2tHXuFc lXjuffpOW6Wt+rbqMrFp4LA4H4UXafai9B5F1JMp+xdK+V0YUT0aQSZwdHyvNsGReRnuuZKH be0xokpVM+ndra2EpsV0C3csoDOWyu7yjUyFeTfAlYBb8rn8WuLnT8xzSJEAEQEAAYkCHwQY AQIACQUCVIb+DQIbDAAKCRCTnmvh4p/DzKGQD/wLhO70IEI06MqaP41im4X7suk4zGOAcBXA csZONq450CA/WHvoMKFoCPHfoC4e1jsoifG8+emfTQhWKwW3a5G/H90a8lY8pH9tqkVUPds5 m6fbWf16xkWUQpH8QQyLwhBIF8onclrDWAHPflpnWp+wso1vxN+WRh5vL1k8dpQLUkOBmE1o vl79/z1zzOYDkOWdQ1crU2EbOXalCmOASmiFhWiYk2aosBxbzGX0JKX5NyIUzz56i9vDYqjk DFYcMMx1Z9YXsvTjglMwnIfwPmvBBgQlwqg+LOts7XF0ZoBZ3NBLpIES0wheVjXtG/T7kZey 7XABVbxK2B4mIRFIvXnHbTEGzSyY7hLCshyCMQTDCoHDOKiNZmteqhHU4zXVgyhrxkYG9iID j9yb6PCjaFwgp42rz0lLqTgmpDEIrz1MaCglhTB68wTsHYx3SH+ClNGmgWTa8dS+l/s0hgE+ WknVGn6ShMkdyYLn3QxTRhZSmRv2hG7AYSemtLxi4lLoJ3kDHLMYAponhzxLYOtc8IyNrrRU 4Tj4keG2ssHSkC9kDIMqzX53ObGkVWN6Rvu+pmZ9iumrNqI/4PyrPi3mOE7ooIkh1L/MEu2c LNWaTG5QmOK0VtYN+3G2qzcjKEpQPIDgRdZ6i7fO6jgb0iy1UJUbAoLQgUTaX99KUKeyCuiG UA==
Message-ID: <b501f68e-f4a4-3955-4991-f6d98e545bb2@gnunet.org>
Date: Wed, 22 Jul 2020 00:06:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <31625.1595368614@localhost>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="koCSjSp2s8wttWDcpBWdXAG2usuo9ZMsj"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/3ftazgFW8IwpByBvZGDc_20exOI>
Subject: Re: [Secdispatch] GNU Name System
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 22:07:18 -0000

Hi! First of all, thanks for reading the draft!

On 7/21/20 11:56 PM, Michael Richardson wrote:
> The document is a bit rough, and could definitely benefit from more
> implementer feedback, but that's of course, why you are here :-)

Indeed.

> There are probably some algorithm agility issues, but I suspect that they
> aren't worse that for ICANN DNSSEC, because the decision to change algorithm
> types can be a partially local decision.

This is actually an area where we already had some feedback via other
channels and are planning on
1) fixing some agility issues, and
2) improving the explanation and write-up to make it
   easier to see how agility can be achieved *and*
   actually give a 2nd instantiation.

Alas, this will require significant changes to the draft and
implementation(s).

> DHT just sort of pops up in the section 3 description.
> And then it isn't until section 6 that we learn that there is a DHT.

Yes, we were already told to improve this part of the write-up. We'll
try, specific suggestions welcome.

> I thought I'd learn more in section 8, but I didn't.
> And then section 9.4 says it's out of scope?

The exact specification, yes. It's way too much for one draft to include
it IMO -- not to mention that GNS can be instantiated over virtually any
DHT.

> I didn't quite figure out how it was used at all actually.
> Since all names are local... wouldn't I always know how to find my
> relationships?

Suppose you have alice.bob.dave.carol.  You must have 'carol' locally,
but you would (typically) lookup 'dave' in carol's namespace in the DHT
already. Basically, the root is local, but the rest is resolved via the DHT.

> I see that GNUnet is being funded by nlnet and NGI, and this is rather good.
> I don't see a clear connection to FSF, and I wonder if they will be happy
> about the naming.  I.e. do you have RMS' blessing here?
> Better to get the name right early.

We do indeed have RMS's blessing.

> If this work is worth doing at the IETF, it probably needs it's own WG.
> There are some RGs that deal with far more distributed networking than the
> IETF has been interested in yet, so maybe that's a route.

Well, we hope to find out what the best home at IETF would be.

> How would it get deploy as other than a niche effort of geeks?

Our plan is to initially integrate it with applications that are
underserved by DNS, like decentralized communication platforms / social
networking applications, identity management (see reclaim:ID) and IoT
applications.

> Do you think that it will be possible to build a GNS Service for Android, or
> for iOS?

For Google and Apple, certainly ;-).  And Apps could certainly link in a
GNS stack for name resolution bypassing the OS resolver entirely if desired.