Re: [Fwd: Request for Advice on VGRS IDN Announcement]

["James Kempf" <kempf@docomolabs-usa.com>]

Patrik,

Do you feel comfortable with having just Verisign do this for the TLDs it
controls and not other operaters, and ccTLDs?

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