Subject: [idn] CDNC Final Comments on Last call of IDN drafts

From: "xiaodong lee" <[email-masked]>
Date: Thu, 06 Jun 2002 09:41:29 +0800

--------------------------------------------------------------------------------

Chinese Domain Name Consortium (CDNC) Final Comments
--------------------------------------------------------------------------------

The following comments are made by CDNC:

1)Currently, IETF IESG has begun Last Call on the set of core
documents IDNA+NAMEPREP+PUNYCODE of IDN WG, but
the architecture of IDN defined in the above three documents
does not solve the traditional and simplified Chinese character
variant problem: it’s a half-baked solution for Chinese users.
That will cause serious delegation problem in the application
of Chinese Domain Name.

2)IETF IDN WG does not solve Chinese Domain Name technical
problems. Under the current condition, if IETF approves these
IDN drafts without publishing any complementary documents
simultaneously, registrars will open Chinese Domain Name
registration without considering the requirements of Chinese
Domain Name and Chinese Domain Name will fall into confusion.
This will damage Chinese Internet community seriously.

3)What’s more, it stands a good chance that software vendors
will not deploy or modify client software to support IDN too,
because the current so-called IDN solution is a defective solution,
which will be widely against end users, administrators and Chinese
Internet communities, and bring them into much trouble.

--------------------------------------------------------------------------------------------

Chinese Domain Name Consortium
CDNC Founding members: CNNIC, TWNIC, HKNIC/HKDNR, MONIC
Co-chair of CDNC: Qian Hualin, Professor
Co-chair of CDNC: Shian-Shyong Tseng, Professor
June 5, 2002
--------------------------------------------------------------------------------------------

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Jun 2002 19:32:31 -0700

At 09:41 AM 6/6/2002 +0800, xiaodong lee wrote:
>variant problem: it's a half-baked solution for Chinese users.

It has never been a goal of IDN to create equivalence between different 
character sets.

Therefore, for such requirements, IDN is not as good as half-baked.  It is 
not baked at all.

>That will cause serious delegation problem in the application

The problem of equivalence between different character sets exists more 
broadly, so that the IDN situation is merely an example of a larger 
problem.  That problem needs to be solved for the general case.

IDN chose Unicode, so that IDN was not required to invent basic technology 
for representing different character sets.

Similarly, IDN should not invent solutions for equivalence between 
different character sets.

When standards bodies for character sets define such equivalences, and when 
those equivalences gain popularity, it might be appropriate for the IDN 
effort to consider incorporating these new standards.

>simultaneously,

You do not state what is the nature of the complementary documents.

 From the remainder of your comments, it appears that you are seeking 
documents concerning DNS administration.

These are probably more appropriate for ICANN, since they pertain to 
registry/registrar matters, rather than basic DNS technology, which is the 
purview of the IETF.

>3)What's more, it stands a good chance that software vendors

Predictions about the behavior of software vendors are usually problematic.

Ultimately, the market will decide whether IDN solves a significant problem 
in a useful way.  So far, there is a strong rough consensus among those who 
have participated in the IETF process, indicating that it solves an 
important problem in an acceptable fashion.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Jun 2002 12:52:54 +0200

Dave Crocker <[email-masked]> writes:

> It has never been a goal of IDN to create equivalence between

This means IDN is not guaranteed to be secure on non-Unicode systems.
There are alot of non-Unicode systems out there today...

> The problem of equivalence between different character sets exists
> more broadly, so that the IDN situation is merely an example of a
> larger problem.  That problem needs to be solved for the general case.
>
> IDN chose Unicode, so that IDN was not required to invent basic
> technology for representing different character sets.
>
> When standards bodies for character sets define such equivalences, and
> when those equivalences gain popularity, it might be appropriate for
> the IDN effort to consider incorporating these new standards.

This isn't an adequate solution IMHO, when the consequences of errors
made by such standard bodies, or conflicts between different standard
bodies, or different interpretations of said standards, or changes
between different versions of those standards, or simply a complete
lack of standardisation in the area (which is the situation today),
may be exploitable for attacking systems on the Internet.

(The details of how to attack systems based on charset equivalence
mapping tables differences, or changes in Unicode decomposition
tables, has been discussed recently on the IDN list.)

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 6 Jun 2002 07:52:56 -0700

>There are alot of non-Unicode systems out there today...

Nothing is ever guaranteed to be secure. Even if we supplied mapping 
tables, there is no guarantee that the mapping tables we supplied 
would match those already in use in those systems, so there will be 
the same security issues. In fact, we can be sure that some 
"standardized" mapping tables would disagree with those already 
implemented.

>may be exploitable for attacking systems on the Internet.

And your proposal for an adequate solution is....? Short of forcing 
every current system to use a single set of standardized mapping 
table (which is patently unrealistic), how could you ever avoid such 
an exploit?

Further, the exploit you descirbe is identical in every application 
that allows an encoding of the Unicode character set (such as UTF-8). 
Are you saying that we shouldn't allow any input in UTF-8 in any 
application until there is both a standard set of mapping tables and 
absolute conformance to them?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Jun 2002 08:17:29 -0700

>There are alot of non-Unicode systems out there today...

1.  I assume your use of "secure" does not refer to security technology, 
but rather to something like correct or productive use.

2.  New standards are about new capabilities.  If a system does not support 
the standard -- in its entirety -- then of course it cannot use the standard.

With respect to use of data formats, a system implementing a standard must 
map between the network standard format and their internal format.  That is 
the nature of interoperability formats; it has been the approach to open 
systems standards for more than 30 years and it works well.

>made by such standard bodies, or conflicts between different standard

It appears that you want to do standards development in a different world 
than the one we currently occupy.  Most folks prefer to work within the 
current reality.

On the plus side, the nature of the model is called divide and conquor.  To 
make a complex problem tractable, solve as little of it as is practical, 
using an many existing component solutions as can be found.

My own belief is that the single biggest cause of failed standards efforts 
is failure to constrain the initial solution effort, leading to confusion 
and delay.

>tables, has been discussed recently on the IDN list.)

Discussions are fine.  However the only things that really matters is 
specifications and their acceptance.

This issue has been under discussion for a few years.

Please point me to the detailed specification that solves the equivalence 
problem.

Please point me at the base of community support for this specification.

Absent a concrete specification and community support for it, all you are 
suggesting it that we wait more years in the hope of developing something 
that has so far proved extremely elusive.

That's not a very good plan for getting anything useful and getting it in a 
timely manner.

d/

----------

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 7 Jun 2002 21:16:30 +0900

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
> That's not a very good plan for getting anything useful and getting it in a

Your above defense of  premature and lacking-of-consensus IDN standards won't work because
IDNA proposes universal and irreversible infrastructural changes on DNS by redefining
the subspace ([a-z][a-z]--*) of ASCII domain namespace to have new i18n meanings which have
been proved to be problematic.
No application which supports ASCII hostnames  can avoid this redefinition in the
higer/later/human interpretation level. IDN standards are not like the message protocol "quoted-printable"
which use is optional and we have many other alternatives like "base64". We have no alternative other than to-be-redefined DNS which
is unique. You should not extend your logic into IDN standards. Finding any analogy between IDN standards efforts and those for tiny
application protocols will be proved to be false.

We have only single slot for new IDN standard. Incremental or "divide and conquor"-style changes or
revisions on IDNA standards were already ruled out in IDNA documents themselves.
if ever issued and deployed, DNS standards cannot be upgraded because they form  crucial internet identifier system which should be
stable. DNS is no more the sole property of US DoC/DoD/IETF/IANA, but rather internationallly shared resource.

 I hope you Dave share with us  serious concerns about how to secure DNS from
irreversible jeopardizations by commercial driving forces of IDN.

"Be liberal in what you accept, Be conservative in what you *ISSUE*  ".

Soobok Lee

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Jun 2002 14:00:00 -0700

At 09:16 PM 6/7/2002 +0900, Soobok Lee wrote:
>Your above defense of  premature and lacking-of-consensus IDN standards 
>won't work

If you review the amount of time spent on developing this work, you will 
discover that it is a long way from premature.  Quite the contrary.  The 
work has gone on approximately two years longer than it needed to.

If you review the usual IETF processes for developing rough consensus, you 
will discover that IDN is a long way from lacking rough consensus.  In fact 
the process has continued beyond achieving adequate rough consensus, 
because the IETF has been heeding the concerns of a vocal minority of the 
community, where most of the concerns of that vocal minority concern 
technical issues that are outside of the scope of this working group.

>irreversible jeopardizations by commercial driving forces of IDN.

We heard similar hyperbole about MIME.

It failed to prove true then.  It will fail to prove true for IDN.

IDN is a careful, focused response to a specific problem with DNS character 
sets.  IDN correctly limits its scope to the solution of that character set 
problem.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 08 Jun 2002 16:43:28 -0500

> technical issues that are outside of the scope of this working group.

If that were true we wouldn't be up to rev 9 of the core draft.

Gee, maybe some of the concerns are real, in spite of two years of harping
that we are finished.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 08 Jun 2002 16:28:19 -0700

>If that were true we wouldn't be up to rev 9 of the core draft.

9 revisions is not unusual.

It is also demonstrably true that one can keep revising a spec 
forever.  Some working groups are very good at it.  On the other hand, they 
are not very good at shipping a spec and getting it used.  It would be nice 
for the IDN effort not to suffer that fate.

d/

----------