Re: [I18ndir] I18ndir early review of draft-schanzen-gns-10

"Schanzenbach, Martin" <schanzen@gnunet.org> Mon, 07 March 2022 21:03 UTC

Return-Path: <schanzen@gnunet.org>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF34C3A0ABC for <i18ndir@ietfa.amsl.com>; Mon, 7 Mar 2022 13:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.243
X-Spam-Level:
X-Spam-Status: No, score=-1.243 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, 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 E1sEpAO-qwYT for <i18ndir@ietfa.amsl.com>; Mon, 7 Mar 2022 13:03:54 -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 0F11D3A0ABD for <i18ndir@ietf.org>; Mon, 7 Mar 2022 13:03:53 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id F0ACF240104 for <i18ndir@ietf.org>; Mon, 7 Mar 2022 22:03:50 +0100 (CET)
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4KC9tC0RCDz9rxj; Mon, 7 Mar 2022 22:03:46 +0100 (CET)
From: "Schanzenbach, Martin" <schanzen@gnunet.org>
Message-Id: <BB840B7A-8318-4153-A9D7-631DF544DC21@gnunet.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_0496B71C-698D-498C-A526-87585A7954D8"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Mon, 07 Mar 2022 21:03:42 +0000
In-Reply-To: <C05803EF-505B-49EC-96A8-B3183A9E773B@vpnc.org>
Cc: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Christian Grothoff <grothoff@gnunet.org>, Jiankang Yao <yaojk@cnnic.cn>, "draft-schanzen-gns.all" <draft-schanzen-gns.all@ietf.org>, i18ndir@ietf.org
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <164638828309.28413.11846349950083727255@ietfa.amsl.com> <02ce8381-11b8-196a-c0bc-afa21cccec1f@rfc-editor.org> <7A835641-2DF1-4887-A79F-9481C8DB6D6B@gnunet.org> <2022030717083858073951@cnnic.cn> <d81600c6-f224-d805-7d32-901cbecb3412@gnunet.org> <54d2d315-aa18-1498-4844-f1ae94930425@rfc-editor.org> <CCBCC361-976C-439C-B718-C0985913DD31@gnunet.org> <C05803EF-505B-49EC-96A8-B3183A9E773B@vpnc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/ykJ3NuV5y4GmQWzfpo_Cpoz63_E>
X-Mailman-Approved-At: Mon, 07 Mar 2022 13:04:58 -0800
Subject: Re: [I18ndir] I18ndir early review of draft-schanzen-gns-10
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2022 21:03:59 -0000

Hi Paul,

> On 7. Mar 2022, at 21:28, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> 
> On 7 Mar 2022, at 10:45, Schanzenbach, Martin wrote:
> 
>> Ah I think this brings us on the right path.
>> I am thinking about adding a security/privacy consideration with respect to name leakage:
>> 
>> """
>> Name Leakage
>> 
>> GNS names are indistiguishable from DNS names or other special-use domain names [RFC6761].
> 
> This statement is not technically true, and making it definitively true is difficult in the protocol. To help clarify, I think you mean "GNS display names", not on-the-wire names; GNS on-the-wire names are quite different than DNS on-the-wire names.
> 

Hmm true.
This also reminds me that I wanted to change the field "DNS NAME" in the record in order to avoid a similar confusion as highlighted by Jiankang.

> But more significantly, the GNS spec in many places optionally allows GNS names and labels (display) to use Unicode characters and label/name lengths different from the DNS. Thus many GNS names are distinguishable, but many are not, so any security consideration becomes much more involved than the wording you proposed.

Yes I have not considered that. So (displayed) names may be indistinguishable but not necessarily.
Others can at least be ruled out as names which can be resolved through DNS, for example using the
length.
I don't understand what unicode has to do with it because as I understand it an application (browser) will accept
a unicode string (with multibyte characters) as DNS (display) name, convert it to punycode and resolve it.
So this (should not?) be an indicator that this is a GNS name by itself.
You may have sent me down another rabbit hole of RFC8499 with respect to name formats, in particular also
the used concept of "rightmost" labels with rtl names in GNS :)

I do not think we differentiate between GNS display names and on-the-wire names.
But DNS apparently does.
So I would probably word it as "GNS names may be indistinguishable from DNS names in common display format (possibly cite 8499 here) [..]".

BR

> 
> --Paul Hoffman