From nobody Sun Nov 8 12:44:20 2020 Return-Path: X-Original-To: din@ietfa.amsl.com Delivered-To: din@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7993A0E00 for ; Sun, 8 Nov 2020 12:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 pKvDoVHiT3zB for ; Sun, 8 Nov 2020 12:44:17 -0800 (PST) Received: from mout02.posteo.de (mout02.posteo.de [185.67.36.142]) (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 1DFAA3A0AA6 for ; Sun, 8 Nov 2020 12:44:16 -0800 (PST) Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id E201B2400FB for ; Sun, 8 Nov 2020 21:44:13 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4CTmLz4pHKz9rxG for ; Sun, 8 Nov 2020 21:44:11 +0100 (CET) Message-ID: <52ffde7e4f51f4f88c84fe73cb4727bd1d04e22c.camel@gnunet.org> From: Martin Schanzenbach To: din@irtf.org Date: Mon, 09 Nov 2020 05:44:00 +0900 In-Reply-To: <2E228AD3-F5C7-42A6-B59D-5D523E35E5B8@gnunet.org> References: <2E228AD3-F5C7-42A6-B59D-5D523E35E5B8@gnunet.org> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-1W/Nzzm/C20HvNlD8e9h" User-Agent: Evolution 3.38.1 (3.38.1-1.fc33) MIME-Version: 1.0 Archived-At: Subject: Re: [Din] Draft / Specification of the GNU Name System X-BeenThere: din@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2020 20:44:19 -0000 --=-1W/Nzzm/C20HvNlD8e9h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, we wanted to check back with you if it makes sense to coordinate next week at IETF 109. It seems as if dinrg is not (yet) listed on the agenda? According to the minutes of IETF 108, the next steps would involve coordination/deconflicting with DINRG: https://codimd.ietf.org/notes-ietf-108-secdispatch# Best Regards Martin On Sun, 2020-10-18 at 15:13 +0200, Schanzenbach, Martin wrote: > Dear DINRG, >=20 > at IETF 104, we have presented to you our work on the GNU Name System > [1]. > Since then, we have been working on improvements and a technical > specification of the system [2]. > At IETF 108, we appeared at secdispatch in order to discuss if the > draft may fit into any existing WG in IETF (or IRTF) [3]. > We were encouraged to ask DINRG if it would be interested in this > work and continue improving and working on it (see minutes of > secdispatch). Your charter would certainly support the general theme > of the protocol: "The evolution of distributed ledger technologies > and the platforms that leverage them has given rise to the > development of decentralized communication and infrastructure > systems, and experiments with the same. Some examples include name > resolution (Namecoin, Ethereum Name Service), identity management > (OneName), distributed storage (IPFS, MaidSafe), distributed > applications, or DApps (Blockstack), and IP address allocation and > delegation." >=20 > Since our appearance at secdispatch, we have received a lot of > feedback from the community and experts. We have taken the time to > incorporate the feedback and the result is in the current version of > the draft as well as our implementation. > As you can see, the draft versions 01 and 02 differ significantly. > The two major changes regarding the protocol that we have made are: >=20 > 1. Improve crypto agility: Allow other zone key types and key > derivation schemes and define the required properties. > 2. Improve crypto implementation: The used symmetric encryption > scheme has been replaced to be more resilient to IND-CCA >=20 > For (1.) we have drafted an alternative scheme based on Schnorr > signatures. This instantiation is still a draft and not implemented. > Any feedback here is specifically welcomed and helpful. >=20 > Finally, we would be happy to appear at the next IETF and discuss > whether DINRG would be a place to continue our work with you. >=20 > Best > Martin >=20 > [1] > https://www.ietf.org/proceedings/104/slides/slides-104-dinrg-gnu-name-sys= tem-00.pdf > [2] https://datatracker.ietf.org/doc/draft-schanzen-gns/ > [3] > https://www.ietf.org/proceedings/108/agenda/agenda-108-secdispatch-02 --=-1W/Nzzm/C20HvNlD8e9h Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEEZmUgHqklfMaP3nfohDNRMeo9q/AFAl+oWJAUHHNjaGFuemVu QGdudW5ldC5vcmcACgkQhDNRMeo9q/ChGQ/7BKKOFBPq5RHvyafwP1CJRT6nH2Mn vTwbtP2d/lpwZO80RgofSIn7T9CsxzFnevFcZoadDAi5rEC9PGKAB92tlewuZ0KJ Aml9rRRbMmRwNODrW78GpxKSUkPjE7Kir0kwgD6w1T71EYNTBCtDMEO9DZxb1kIO pEmoxr1IVR5TCYLepFXrpxD+raP5y+gsiR2UIOTeBWLGwPbkYkvf7xlab2I71xip GtqurQacbzouyrscvYwWnasht28AgaJ5uBNPXiBihikb71o22B4gS9WcfEVTdQ4D m95bmAJvjD4aIaa0FwYOrpzeJf0TTBx8efzBtZQ77yXGlT82Cs7g0FV9FlLtait0 ercQ6hoOBUBLkM7N2fcEatX8BqGQg24p3w/fUZ599MSWupEOz71+WIoIXjY7CF/M bSNGDNikvf0vbiHV6w52GcsSXgeaR0OQfEPoGI3yNpk4exrmSkYWumRphtVeI180 6WrN4m+zvxE6TwFdWWkdXK2s/ZkJ9/0f7XrlqKdjlBlooCTzZfTMcCpo2+ZC5xZX oIl2lJUJhwJ6j/Bn6omSgzKchVfVIN3vnxP5ChqQSHTnhAUxHOBAtPy17rBjA9Oh FX0dPrqb3lYyNE4ZPQ9OkVwLFg+p4PCVrf2i5i3y9CULXP2jKjlqrX5KxnfTTqgt BlJGgxchu0l4FsY= =hxP8 -----END PGP SIGNATURE----- --=-1W/Nzzm/C20HvNlD8e9h--