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

"Schanzenbach, Martin" <schanzen@gnunet.org> Tue, 08 March 2022 02:52 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 0C7FC3A0AAB for <i18ndir@ietfa.amsl.com>; Mon, 7 Mar 2022 18:52:39 -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 tbJLBVa7J62j for <i18ndir@ietfa.amsl.com>; Mon, 7 Mar 2022 18:52:34 -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 6C4473A0AA8 for <i18ndir@ietf.org>; Mon, 7 Mar 2022 18:52:33 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 99E8D240101 for <i18ndir@ietf.org>; Tue, 8 Mar 2022 03:52:29 +0100 (CET)
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4KCKcX5DsKz6tmv; Tue, 8 Mar 2022 03:52:28 +0100 (CET)
From: "Schanzenbach, Martin" <schanzen@gnunet.org>
Message-Id: <A8D931EF-8124-4AED-9B9A-DD94EA3B96EF@gnunet.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_7F537E7A-9B7A-4A0B-A2FA-CF3910947F84"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Date: Tue, 08 Mar 2022 02:52:24 +0000
In-Reply-To: <20220308012252.30E2538A3C32@ary.qy>
Cc: i18ndir@ietf.org
To: John Levine <johnl@taugh.com>
References: <20220308012252.30E2538A3C32@ary.qy>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/J-R01xCx1nd9CB97LSbVilOiQr4>
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: Tue, 08 Mar 2022 02:52:39 -0000


> On 8. Mar 2022, at 02:22, John Levine <johnl@taugh.com> wrote:
> 
> It appears that Schanzenbach, Martin <schanzen@gnunet.org> said:
>> 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.
> 
> IDNA only allows a subset of Unicode characters in domain U-labels.  If your name has characters outside
> that set, it's not a domain name.

Yeah but that is not what an application must handle. The application must decide how to resolve the name
based on what it is given by the user. This may include a string that is not a valid IDNA protocol name.
That is my interpretation of rfc5895.

So, this means that ultimately the application must decide if the name can be mapped to a valid DNS name or not based on
context/user expectation and RFC5895 is intentionally not normative in this regard.
But that would also mean that the application can decide if the name can be used as a GNS name or not based on context/user expectation.

There may be applications that only and explicitly resolve through GNS and so implicitly what the user provides can only be interpreted
as a GNS name.
There may be applications that want to handle both DNS and GNS names. In those cases I think we need to provide some considerations
with respect information leakage when "accidentally" trying to resolve a GNS name in DNS.

BR

> 
> R's,
> John