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

From: Jiankang Yao via Datatracker <[email-masked]>
Date: Fri, 04 Mar 2022 02:04:43 -0800

Reviewer: Jiankang Yao
Review result: Not Ready

Some review comments below:
1)This document says something about internaitonalisation, but some wording
related to internaitonalisation make the readers confusing. For example, in
section 5.2.2, there is a definition " DNS NAME  The name to continue with in
DNS.  The value is UTF-8 encoded and 0-terminated." It seems to indicate that
the DNS name can be UTF-8. If it is a DNS name, it should be in ASCII, not in
UTF-8 because all names including IDN stored in DNS are in ASCII or A-label
form.

2)It seems that both this system and current DNS share the same name space. So
it is possible that two name spaces will collide with each other in the future.
It may confuse the future applications when looking up for the same name. Does
this name belong to DNS or GNU name system?

3)It is interested to know that there is a section named with "GANA
Considerations". It seems that GANA will replace some function of IANA.
  If we follow the current way, the parameters produced by this document need
  to be managed by IANA instead of GANA.

4)ICANN manages the DNS name root space. I suggest to ask some experts from
ICANN to review this document.

---

From: Independent Submissions Editor <[email-masked]>
Date: Fri, 4 Mar 2022 11:59:38 +0100

Jiankang

Thank you for this review.  Please see below.

Did you see the note at the bottom of Section 5.2.2:

>     NOTE: If an application uses DNS names obtained from GNS2DNS records
>     in a DNS request they MUST first be converted to an IDNA compliant
>     representation [RFC5890].

I think you may also be commenting on the text below Figure 12. I think 
there are indeed some implications here about when to convert the 
representation.  Can the authors comment?

> this name belong to DNS or GNU name system?

Could the authors respond to this?  I wonder if indeed such a clash is 
possible

>    to be managed by IANA instead of GANA.

Can you explain why you think that is?

> ICANN to review this document.

This is a name space NOT managed by ICANN.  The issues we are concerned 
about are interactions with the DNS, and of course i18n.

Regards,

Eliot

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Fri, 4 Mar 2022 12:46:45 +0100

Hi Martin,

Thanks for your lightning-fast response.  Below, please.

On 04.03.22 12:36, Schanzenbach, Martin wrote:
> Thanks for the review!
>
> My comments are inline below.
>
>> On 4. Mar 2022, at 11:59, Independent Submissions Editor <[email-masked]> wrote:
>>
>> Jiankang
>>
>> I think you may also be commenting on the text below Figure 12.  I think there are indeed some implications here about when to convert the representation.  Can the authors comment?
>>
>>
> It is arguably also not true. An IDNA-compliant name may consist of U-labels: https://datatracker.ietf.org/doc/html/rfc5890#section-2.3.2.1
> Anyway, there is a note which clearly states that the UTF-8 string in this field MUST be converted
> to something DNS understands through the respective IDNA spec.
>
> The field name is "DNS NAME", but the does not say that this is a "DNS name". It is the
> "name to continue with in DNS" represented as an UTF-8 string.

Ok.  I see what you are saying.  If you can think of a simple example 
that could demonstrate this inline, it might be helpful. I am not saying 
it is required, so just let me know you're preference.

>> Could the authors respond to this?  I wonder if indeed such a clash is possible
>>
>>
> I would like to refer to our previous efforts on integrating GNS into the DNS namespace via
> RFC6761 here: https://mailarchive.ietf.org/arch/msg/dnsop/wu_uAtNaUieZ5Tb2imJEzW4F5vM/
>
> A DINRG presentation also noted this: https://datatracker.ietf.org/meeting/104/session/dinrg
>
> tl;dr: Our initial approach was to use a special-use TLD. But, RFC6761 was not followed.
> We do know this also clashes with RFC8244 but what can we do?
> Should there ever be a consensus or a special-use TLD which should be used for GNS
> names, the document could be amended and/or a new document detailing the use
> could be written.
> But as it stands, our request is/was not granted (maybe Christian can be a bit clearer on the outcome
> of the proposed drafts) and as such the use of GNS may clash with the DNS namespace.
>
> The system itself is also designed in this way to circumvent censorship by
> registrars as requests to do so are quite real  (ICANN, gTLD or others).
> https://www.icann.org/en/system/files/correspondence/marby-to-fedorov-02mar22-en.pdf

Ok.

> Please also refer to the "History" section here on the origins of GANA and why we
> can't use IANA: https://git.gnunet.org/gana.git/tree/README
> Christian also may know more here.

Ok.

>> This is a name space NOT managed by ICANN.  The issues we are concerned about are interactions with the DNS, and of course i18n.
> See above?

Ok.

Regards,

Eliot

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 7 Mar 2022 17:09:39 +0800

From: Schanzenbach, Martin
Date: 2022-03-04 19:36
To: Independent Submissions Editor
CC: Jiankang Yao; draft-schanzen-gns.all; i18ndir
Subject: Re: I18ndir early review of draft-schanzen-gns-10

Thanks.
Some comments inline below.

> "name to continue with in DNS" represented as an UTF-8 string.

Your explaination is clear. But the definition of "DNS NAME" belongs to the DNS protocols.
If your document is not part of DNS protocols, it is better not to define or redefine some DNS terminlogy.
If possible, I suggest that you rename "DNS NAME" to other name in your GNU name system.
Otherwise, it might cause some confusiton to the DNS guys.

> of the proposed drafts) and as such the use of GNS may clash with the DNS namespace.

If the use of GNS may clash with the DNS namespace, it might cause some problems in future.
That is why I suggest that this document should get some review from IETFer affiliated with ICANN.

> Christian also may know more here.

If RFC-ISE is ok with the GANA, no objection is from me.

> > This is a name space NOT managed by ICANN.  The issues we are concerned about are interactions with the DNS, and of course i18n.

Yes, it is NOT managed by ICANN, but "the use of GNS may clash with the DNS namespace".

The DNS name space (common global identfiers) is very important to Internet success. https://www.internetsociety.org/issues/internet-way-of-networking/ 

So before moving this document to the next step, I suggest to get some comments from IETFer affiliated with ICANN.

Best Regards
Jiankang Yao

> Best
> Martin

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 7 Mar 2022 16:24:09 +0100

On 3/7/22 10:09, Jiankang Yao wrote:
>> > This is a name space NOT managed by ICANN.  The issues we are
> concerned about are interactions with the DNS, and of course i18n.
>> 
> 
> The DNS name space (common global identfiers) is very important to
> Internet
> success.https://www.internetsociety.org/issues/internet-way-of-networking/
> <https://www.internetsociety.org/issues/internet-way-of-networking/> 
> 
> So before moving this document to the next step, I suggest to get some
> comments from IETFer affiliated with ICANN.
> 

Well, that has been discussed to death, with Warren Kumari even writing
RFC 8244 about the *discussion* that we triggered about it in 2013 (!)
at dnsop and beyond -- including Martin's presentation at ICANN about GNS.

So IMO this is very far outside of the scope of the i18n review, and
simply another topic that the IAB has decided to punt on (my
interpretation). So this is a political issue, which we cannot solve
anymore and will just leave as-is / unresolved / potentially
conflicting.  The expert reviewers (like Bortzmeyer) are also very well
aware of the discussion --- it triggered like 1000 e-mails on dnsop back
in the day...

My 2 cents

Christian

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Mon, 7 Mar 2022 17:10:13 +0100

Can I ask that we suspend this discussion for a day?  Heads seem to be 
running hot.

Thanks,

Eliot (ISE)

---

From: "Independent Submissions Editor (Eliot Lear)" <[email-masked]>
Date: Mon, 7 Mar 2022 18:12:23 +0100

Hi Christian Yiankang, and Martin:

I want to make several points:

 1. Neither Yiangkang nor I represent or are associated with the IAB. 
    Although I am appointed by them, my views are my own, and I have not
    consulted the IAB about this draft.
 2. I agree with Christian that the comments go beyond the scope of
    internationalization.  However, reviewers are allowed to do that,
    and if they don't it is quite likely that people at the next stage
    will.  I would ask Yiankang to confirm that there are no other
    international issues to be addressed.
 3. I think the issue that Yiangkang is demonstrating is some confusion
    on the part of the reader regarding the relationship between GNS and
    DNS.  I believe there *is* an architectural issue around multiple
    name spaces, and it may be good to hit that a bit more head on. 
    Neither ICANN nor the IETF can have a corner on creation of name
    spaces, but understanding how applications should identify which
    name space is in use is something that should be crystal clear.  I
    see two specific ways to tackle this:
     1. How does one know, for instance, when looking at a name that one
        should query the GNS or the DNS?  That could be solved with a
        URI or a URN, for instance.  One could say that the application
        must assume one or another.  One could say that the application
        should take as an option one or another.
     2. A bit more clarity about expected coherency (or lack thereof)
        between the naming systems, when mapped.

None of this is insurmountable but a certain amount of care must be 
given. Christian, Martin, could you please respond directly to me on 
point (3) when you are ready.  Again, thank you Yiangkang for your review.

Eliot (ISE)

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Fri, 4 Mar 2022 11:36:02 +0000

Thanks for the review!

See above?

Best
Martin

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Mon, 7 Mar 2022 18:45:02 +0000

> On 7. Mar 2022, at 18:12, Independent Submissions Editor (Eliot Lear) <[email-masked]> wrote:
> 
> 	• Neither Yiangkang nor I represent or are associated with the IAB.  Although I am appointed by them, my views are my own, and I have not consulted the IAB about this draft.
> 	• I agree with Christian that the comments go beyond the scope of internationalization.  However, reviewers are allowed to do that, and if they don't it is quite likely that people at the next stage will.  I would ask Yiankang to confirm that there are no other international issues to be addressed.
> 	• I think the issue that Yiangkang is demonstrating is some confusion on the part of the reader regarding the relationship between GNS and DNS.  I believe there is an architectural issue around multiple name spaces, and it may be good to hit that a bit more head on.  Neither ICANN nor the IETF can have a corner on creation of name spaces, but understanding how applications should identify which name space is in use is something that should be crystal clear.  I see two specific ways to tackle this:
> 		• How does one know, for instance, when looking at a name that one should query the GNS or the DNS?  That could be solved with a URI or a URN, for instance.  One could say that the application must assume one or another.  One could say that the application should take as an option one or another.
> 		• A bit more clarity about expected coherency (or lack thereof) between the naming systems, when mapped.
> None of this is insurmountable but a certain amount of care must be given. Christian, Martin, could you please respond directly to me on point (3) when you are ready.  Again, thank you Yiangkang for your review.

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 poses a risk when trying to resolve a name through DNS when it is actually a GNS name. In such a case, the GNS name would be leaked as part of the DNS resolution. This risk is also present for special-use domain names which must be handled before starting a DNS resolution request by the application.

Any application MUST take into consideration the user configuration of resolution precedence when trying to resolve a name. One example of such a configuration which at the same time allows applications to delegate the resolution itself is the Name Service Switch (NSS) of Unix-like operating systems. It allows system administrators to configure host name resolution precedence and is integrated with the system resolver implementation.

The order of resolution mechanisms to try is under the discretion of the user or system administrator. In the absence of an explicit configuration it is RECOMMENDED that applications try to resolve a given name in GNS before any other method in order to honor potential TLD overrides in GNS by the user. If no suffix-to-zone mapping for the name exists, resolution MAY continue with other methods. If a suffix-to-zone mapping exists for the name and the query succeeds, fails or returns no results, resolution MUST NOT continue by other means.
"""

This makes it explicit that GNS names cannot be distinguished from DNS names (or special-use tlds, or any other domain name for that matter).
It also addresses the issue of potential leakage of names in another system.
Note that is leakage issue is generally a problem also for special-use names (e.g. .onion, .bit etc) but it makes sense to highlight it I think.

BR

>>>>>> 4)ICANN manages the DNS name root space. I suggest to ask some
>>>>>> 
>>> experts from
>>>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 07 Mar 2022 12:28:34 -0800

On 7 Mar 2022, at 10:45, Schanzenbach, Martin wrote:

> 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.

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.

--Paul Hoffman

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Mon, 7 Mar 2022 21:03:42 +0000

Hi Paul,

> On 7. Mar 2022, at 21:28, Paul Hoffman <[email-masked]> wrote:
> 
>> 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

---

From: "John Levine" <[email-masked]>
Date: 7 Mar 2022 20:22:51 -0500

>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.

R's,
John

---

From: "Schanzenbach, Martin" <[email-masked]>
Date: Tue, 8 Mar 2022 02:52:24 +0000

> On 8. Mar 2022, at 02:22, John Levine <[email-masked]> wrote:
> 

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