jak
----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Leslie Daigle" <leslie@thinkingcat.com>
Cc: <iab@ietf.org>; <iesg@ietf.org>
Sent: Monday, January 06, 2003 10:26 PM
Subject: Re: [Fwd: Request for Advice on VGRS IDN Announcement]
[Steve Bellovin and myself have been talking a bit about this, since
the announcement on the Nanog list (among other places). That the
announcement was done on a Friday, before a holiday in many countries
(including Sweden), is unfortunately something Verisign have done MANY
TIMES, and I start to get really really tired -- it feels like it is
done the times when Verisign feel what they do is on the edge to what
is ok (which for us means it is far out)]
First some background on "Internationalized strings". I don't claim
here I use 100% correct terms for everything, because I have
concentrated on getting the story right, AND, getting something to IAB
and IESG fast.
If you think you know the background, scroll down to "Now to the
issue:".
Background:
When looking at a string, you have a "virtual sequence of characters".
No mapping to any "values" at all. They are just characters. This is
what is drawn on the screen for a user, and what the user think he
type
into for example a web browser.
The string of characters is handled by a sequence of values in a
specific character set (not the IETF version of charset). One such is
Unicode. Another is US-ASCII. A third ISO-8859-1 etc. IETF has decided
that the character set we work with is Unicode / ISO-10646. Reason is
that it is the largest character set that exists, which increases the
chance that it is possible to map from a random character in a random
character set (not Unicode) and be happy. Alternative (which we use in
some standards, like MIME for email) is that we always tell what
charset the data is in.
When talking about characters at this level, we also have to talk
about
equivalence problems. In Unicode, this is resolved by having Unicode
Consortium defining equivalence tables (with variable success), and
normally the normalization (which is what the process is called) works
by mapping one or more characters after each other to another series
of
characters. This is an M:1 mapping, i.e. non-reversable.
Third issue is to represent the string of characters in a specific
charset by bits. Unicode can be represented in various ways, and we
use
normally UTF-8 because it is backward compatible with US-ASCII in an
8-bit clean environment. Negative side is that the characters have
variable length, and by that I one character can be variable number of
octets.
In IDNA, the choice we (as authors) made was to NOT use UTF-8 but
instead an ACE -- ascii encoding. And the reasons are two (mainly):
- Application layer protocols are not 8-bit clean
- Applications which use UTF-8 do not do normalization
The second looks weird, but, we wanted to force people to do changes
in
software when implementing IDN, because the normalization _is_
important, and forcing normalization (changed matching rules) in DNS
servers, and application servers is something we thought was a
definite
showstopper. It is also impossible to distinguish the 8-bit bytes
coming from a correct implementation from something "old". The
"prefix"
(zq--) we use in the ACE makes it possible to implement "better"
mechanisms in the future.
Now to the issue:
Internet Explorer on Windows send out DNS queries using UTF-8, and
other browsers send out IDN using other character sets. No
normalization, no IDNA ACE encoding.
Because of this, with IDNA, what to do with 8-bit octets is still
"unclear" even though most DNS servers map bit by bit for octets where
the 8th bit is set, and for 7-bit octets they are matched in a
case-insensitive matching in US-ASCII.
People register IDNA domain names, which because of IDNA is registered
using the ACE encoding.
When someone which have a software which do not support IDNA, random
bytes will possibly be sent from the application. In the case of
Internet Explorer on Windows, UTF-8 encoding and not ACE encoding (and
not normalization) of registered domain name will be sent.
What Verisign seem to have implemented is the following:
(1) When a query comes which have the 8th bit set in 2nd level domain,
they give back an A record pointing to their servers.
(2) Those servers respond to the HTTP protocol on port 80.
(3) They give back a response which is a webpage which inform about a
plugin.
(4) It also give back ability to click on one alternative domain,
which
is to say what domain the user "want to connect to"
(5) Some rumors say the plugin do not work for all TLD's but only
.com,
.net and other TLD's which have paid to Verisign.
(6) The software they have is doing automatically update of itself
Issues:
(1) For me, this could be ok IFF the query was in UTF-8, and only
matched a domain name which actually is registered in ACE according to
IDNA. Verisign give back this A-record _regardless_ of what the query
is.
(2) I have not checked, but I really hope the IP address only have
something listening to HTTP on port 80. This way, non-web-applications
will get an application layer failure instead of DNS NXDOMAIN, and I
think that is "sort of ok". For the user, it gives approximately the
same experience. Can be discussed of course. What is important though
is that the HTTP server MUST verify the HOST header in the HTTP
protocol, and only give back a response if the value of the HOST
header
also matches some domain name registered according to IDNA.
(3) This I think is ok. The webpage SHOULD inform of IDNA, MAY inform
about the plugin.
(4) This is guessing using the DNS, and that is a _VERY_BAD_THING_.
The
guessing is (according to a dump of a webpage I got from Paul Hoffman)
choices based on query not being in UTF-8 Unicode, but a random
character set. For example all ISO-8859-x charsets that exists. Also,
the choices seems to be questionably mapped to actually registered
domain names. If the mapping is not there, then Verisign from my point
of view is doing speculative matchings/redirections and not the
_service_ which they might do as a registry for the registrant.
(5) The plugin _DO_ the right thing for IDNA. This is a good thing,
BUT, if the rumor is correct that it does not work for all labels in
all domains, then it is destroying much more than what it fixes.
(6) Automatic update of software is not a bad thing. BUT, it MUST
always ask for confirmation from the user, which the user can cancel.
This part from doing checksums, and other security measures of course.
Information I have say the update is automatic, in the background, and
the user is not told what happens. REALLY BAD.
I think these are the 6 issues where Verisign could have done a better
job, but they screwed up big time.
It can be fixed though, and should be.
My view is that IAB/IESG should tell ICANN the 6 points above MUST be
fixed by Verisign before IAB/IESG feel the implementation is according
to the IDNA standard and acceptable use of the DNS and other protocols
defined by the IETF process.
I have no problem being the contact person which Verisign can pass
ideas/suggestions/etc to.
paf
On måndag, jan 6, 2003, at 20:45 Europe/Stockholm, Leslie Daigle
wrote:
As expected, here is ICANN's request for input. I suggest
the IAB should work on putting together a reply and/or a
statement, with the help of interested IESG folk.
Leslie.
-------- Original Message --------
Subject: Request for Advice on VGRS IDN Announcement
Date: Mon, 06 Jan 2003 11:37:59 -0800
From: M. Stuart Lynn <lynn@icann.org>
To: Leslie Daigle <leslie@thinkingcat.com>
CC: Chuck Gomes <cgomes@verisign.com>, Brad Verd
<bverd@verisign.com>,
Masanobu Katoh <MKATOH@mkatoh.net>, Steve Crocker
<steve@stevecrocker.com>, Vint Cerf <vinton.g.cerf@wcom.com>,
Louis Touton <touton@icann.org>, Andrew McLaughlin
<McLaughlin@icann.org>
Dear Leslie,
Below is a note seeking IAB advice on a technical question pertinent
to
ICANN DNS coordination activities. I would very much appreciate your
consulting
with the IAB and letting me know any advice at your earliest
convenience.
Warm regards,
Stuart
================================================================
To the Internet Architecture Board:
On Friday, VeriSign Global Registry Services announced a set of steps
relating to the implementation of internationalized domain name
capabilities, including changes in the behavior of the authoritative
name servers for the com and net zones. The announcement is at
<http://www.merit.edu/mail.archives/nanog/msg06058.html>. The
announcement appears to anticipate the RFC Editor's publication of
the remaining component documents that define IDNA (Internationalized
Domain Names in Applications), the standards-track output of the
IETF's IDN Working Group.
In response to the VGRS announcement, some commentators have raised
concerns that VGRS's plan for handling DNS requests containing
non-ASCII octets would be contrary to DNS standards. In particular,
see the communication from Paul Hoffman of the Internet Mail
Consortium,
included with attachment below.
In keeping with ICANN's commitment to seek authoritative technical
guidance from the IETF about the relationship of actual or proposed
DNS
operations to the IETF's standards-track activities, we are
requesting
the advice of the IAB (together with the IESG or other IETF bodies,
if
appropriate) about the announced VGRS changes to the behavior of the
.com and .net name servers. Although ICANN's focus must be on
violations of standards VGRS has agreed to follow, we would also
welcome
any IAB comment on effects the VGRS changes may have on architecture
for
the protocols and procedures used by the Internet.
I am copying Brad Verd and Chuck Gomes of VGRS on this message, and
also
actively invite any input or response VGRS may wish to give. We will
also be referring the issue raised in Paul Hoffman's e-mail to
ICANN's
IDN Committee and Security and Stability Committee.
Sincerely,
Stuart Lynn
cc: Chuck Gomes, Vice President for Policy and Compliance, VGRS
Brad Verd, Resolution Systems Operations Manager, VGRS
Masanobu Katoh, Chair, ICANN IDN Committee
Steve Crocker, Chair, ICANN Security & Stability Committee
-----Original Message-----
From: Paul Hoffman / IMC [mailto:phoffman@imc.org]
Sent: Sunday, January 05, 2003 7:18 PM
To: mclaughlin@pobox.com
Cc: Louis Touton; Patrik Faltstrom
Subject: Serious technical problems with VGRS's announcement
Greetings. This message follows up on the announcement from VeriSign
GRS (the com/net registry) that they will start responding to DNS
requests that contain non-ASCII octets and giving positive answers
when they should be giving negative answers. VGRS's announcement is
at <http://www.merit.edu/mail.archives/nanog/msg06058.html>.
There are many technical problems with this change. It essentially
undermines IDNA, which is now on standards track, by adding a level
of guessing to the DNS that IDNA is explicitly designed to avoid.
Further, it makes it appear that IDNs are only useful in domain names
for web sites (and only for sites in .com and .net), and only at the
second level. VGRS has said that their plug-in will not work with
most of the ccTLDs, for example.
For example, if you enter <a-ring>.com in Internet Explorer for
Windows, where "<a-ring>" is the single hex octet 0xE5, you see the
screen shown in the attached file called "e5.tif". (Sorry about the
TIFF image, but it's the only reliable format for PC screen dumps.)
As you can see, VGRS makes wild guesses about what the user wanted,
some of which are very clearly impossible. Worse yet, they do not
include all of the legal guesses that they could have made. And, just
to make it completely confusing to the user, not all of the choices
work.
The DNS is not supposed to be a best-guess service, yet VGRS has
turned .com and .net into this just before IDNA is to be an RFC. VGRS
should not be allowed, through its monopoly on the .com and .net
gTLDs, to destroy the coherence of the DNS for its own short-term
profit. ICANN should demand that VGRS immediately stop giving
incorrect answers to any query in .com and .net, and should instead
follow the IETF standards. If VGRS refuses, ICANN should re-delegate
the .com and .net zones to registries that are more willing to follow
the DNS standards.
Please let me know if you have any further questions.
--Paul Hoffman, Director
--Internet Mail Consortium
--
__________________
Stuart Lynn
President and CEO
ICANN
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: 310-823-9358
Fax: 310-823-8649
Email: lynn@icann.org
--
-------------------------------------------------------------------
"An essential element of a successful journey
is recognizing when you have arrived."
-- ThinkingCat (c.1983 - 2002)
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------