[Secdispatch] GNU Name System

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 July 2020 21:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 EE7913A0ADC; Tue, 21 Jul 2020 14:56:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ApJzpeIj3NM6; Tue, 21 Jul 2020 14:56:57 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378A33A0ADA; Tue, 21 Jul 2020 14:56:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DBC038A24; Tue, 21 Jul 2020 17:36:30 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mqRMz5836WjF; Tue, 21 Jul 2020 17:36:29 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4E46C38A23; Tue, 21 Jul 2020 17:36:29 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CA4683F; Tue, 21 Jul 2020 17:56:54 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "secdispatch@ietf.org" <secdispatch@ietf.org>, "draft-schanzen-gns@ietf.org" <draft-schanzen-gns@ietf.org>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 17:56:54 -0400
Message-ID: <31625.1595368614@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/95Rik3YUfm9AKwdz9Py6Cu2FUEk>
Subject: [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 21:56:59 -0000

Hi, I read through draft-schanzen-gns just now.
First, I generally like the idea.
I particularly like the reference to pet names and SDSI.

The SDSI work *not* been paid attention to enough, so I'm glad that this
document goes with it.
I'm perfectly fine with having to say "ICANN's ietf.org" as a petname for a
DNS rooted in ICANN's DNSSEC root.  Some may find that this may be
a stepping stone towards multiple roots, but I see it differently, because it
enable's stuff like "Michael's Neighbour's Work-Server"
{I didn't get to a part where the presentation of this was discussed,
and how I'd type this into a Location box}

The document is a bit rough, and could definitely benefit from more
implementer feedback, but that's of course, why you are here :-)

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.

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.
I thought I'd learn more in section 8, but I didn't.
And then section 9.4 says it's out of scope?
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?

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.

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.

How would it get deploy as other than a niche effort of geeks?
Do you think that it will be possible to build a GNS Service for Android, or
for iOS?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-