[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [secsac] RE: Verisign SiteFinder DNS trickery and IDN (Forwarded)

On 14 okt 2003, at 18.01, Steve Bellovin wrote:

Does anyone have anything useful to say to secsac on this?
Reply to me; I'll forward.

Oh, boy. I didn't think about this. But it is a similar problem/issue as the JET things which John Klensin brough to the IAB once upon a time.

The problem is this:

Without support for IDNA which encodes non-ascii-characters in "junk" where the format of "junk" is not standardized and pretty random. Everything from just local script to UTF-8 encoded Unicode.

So far, all of these "junk" queries has resolved into NXDOMAIN, so debugging is easy.

When IDNA is deployed (slowly) it is easy to know in a client whether IDNA is implemented or not, as the DNS query with IDNA will still be ASCII. Things will "just work".

Now with the wildcard, the "junk" version of something which _IS_ registered as IDNA (xn--....) will not return NXDOMAIN but instead refer to the Verisign site.

_Really_bad_ <<<<<---- With lot of emphasizes please

As Øien says, this IS bad, and completely kills IDN (or rather, the ability to deploy IDN correctly).

paf

------- Forwarded Message

Return-Path: <owner-secsac@icann.org>
Received: from 127.0.0.1 [127.0.0.1]
by localhost with IMAP (fetchmail-6.2.4)
for smb@localhost (single-drop); Tue, 14 Oct 2003 06:47:28 -0400 (EDT)
Received: via tmail-2000(13) for smb; Tue, 14 Oct 2003 06:44:35 -0400 (EDT)
Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102])
by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h9EAiZZ18920
for <smb@bigmail.research.att.com>; Tue, 14 Oct 2003 06:44:35 -0400 (EDT)
Received: by mail-blue.research.att.com (Postfix)
id 8E1F0B8352; Tue, 14 Oct 2003 06:36:54 -0400 (EDT)
Delivered-To: smb@research.att.com
Received: by mail-blue.research.att.com (Postfix, from userid 612)
id 8084DB835A; Tue, 14 Oct 2003 06:36:54 -0400 (EDT)
Received: from janus (fpfw.research.att.com [135.207.1.2])
by mail-blue.research.att.com (Postfix) with SMTP id A50B3B8352
for <smb@research.att.com>; Tue, 14 Oct 2003 06:36:53 -0400 (EDT)
Received: from mail-pink.research.att.com ([192.20.225.111]) by janus; Tue, 14 Oct 2003 06:44:34 -0400 (EDT)
Received: from greenriver.icann.org (greenriver.icann.org [192.0.35.121])
by mail-pink.research.att.com (Postfix) with ESMTP id 1074E582CC
for <smb@research.att.com>; Tue, 14 Oct 2003 06:40:44 -0400 (EDT)
Received: (from majordomo@localhost)
by greenriver.icann.org (8.11.6/8.11.6) id h9EAhOB07538;
Tue, 14 Oct 2003 03:43:24 -0700
Received: from pechora.icann.org (pechora.icann.org [192.0.34.35])
by greenriver.icann.org (8.11.6/8.11.6) with ESMTP id h9EAhOb07535
for <secsac@greenriver.icann.org>; Tue, 14 Oct 2003 03:43:24 -0700
Received: from EXECDSL.COM (ns.execdsl.net [208.184.15.238])
by pechora.icann.org (8.11.6/8.11.6) with ESMTP id h9EAjDW16094
for <secsac@icann.org>; Tue, 14 Oct 2003 03:45:13 -0700
Received: from [66.92.150.17] (HELO SCROCKER)
by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
with ESMTP id 5620069; Tue, 14 Oct 2003 06:43:23 -0400
From: "Steve Crocker" <steve@stevecrocker.com>
To: <secsac@icann.org>
Subject: [secsac] RE: Verisign SiteFinder DNS trickery and IDN
Date: Tue, 14 Oct 2003 06:42:41 -0400
Message-ID: <007b01c3923f$e49c7680$0affa8c0@SCROCKER>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <Pine.GSO.4.58.0310132334010.5993@hilton.cec.wustl.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300
Importance: Normal
X-MIME-Autoconverted: from quoted-printable to 8bit by greenriver.icann.org id h9EAhOb07536
Sender: owner-secsac@icann.org
Precedence: discussion
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by bigmail.research.att.com id h9EAiZZ18920
X-Spam-Status: No, hits=-6.3 required=5.0
tests=BAYES_10,IN_REP_TO,QUOTED_EMAIL_TEXT
version=2.55
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)

SECSAC folks,

My goodness!  See Dag Øien's message below re interaction betwene wild
cards and IDN.  This is definitely tangled.

It seems to me we need to ask VeriSign about this, but I don't enough
knowledge to pose the question or interpret the answer. Who is familiar
with the IDN impmlementation? John?

Thanks,

Steve

-----Original Message-----
From: Ari E-B [mailto:Ari@Elias-Bachrach.com]
Sent: Tuesday, October 14, 2003 12:36 AM
To: steve@shinkuro.com; pmott@gwu.edu; galvin@elistx.com;
mstjohns@mindspring.com
Subject: Re: Verisign SiteFinder DNS trickery and IDN


Does the wildcard kill Internationalized domain names?
and just for reference:
http://www.ietf.org/internet-drafts/draft-hoffman-rfc3490bis-00.txt

On Thu, 25 Sep 2003, [ISO-8859-1] Dag Øien wrote:

Hello

I would like you to investigate the confusion Verisign'
SiteFinder DNS
trickery creates when the international internet community
now is on
the brink of introducing IDN.

It seems to me that Verisign's DNS trickery will create
more confusion
for developers trying to implement IDN into their
applications and DNS
resolvers.


I own the domain oien.net. My last name is actually Øien with an
O-slash, so I have also registered the domain name
øien.net, which in 
Verisign's IDN-testbed was encoded bq--ad4gszlo.net. However this
domain name never actually resolved in DNS, but now
resolves to some 
non-functional Verisign service. bq--ad4gszlo.mltbd.net resolves in
DNS to the correct hyp.net nameservers. By the way of
Verisign's DNS 
trickery, DNS-queries to øien.net - using ISO-8859-1 charset in the
query - currently resolves to some Verisign service. Soon
bq--ad4gszlo.net is to be converted into the correct punycode
translation: xn--ien-zna.net. After the conversion it may not yet
resolve in DNS. Queries to www.bq--ad4gszlo.net might lead me to
SiteFinder, perhaps - depending on the trcks employed by Verisign.

Trying to figure out DNS now requires one to keep track of
the various
business practice tricks implemented by Verisign. This is
not ideal in
normal circumstances, and specially not now when the world
is finally
racing to implement IDN properly in DNS.

My opinion is that Verisign is a threat to the stability of
the .com
and .net zones, and that their tricks combined with the
introduction 
of IDN risk returning ambiguous or incorrect data in a time of
critical importance for the implementation of IDN, and
mislead people
to non-functional Verisign web-services confusing potential
users even
more.

This is a scandal, really. My opinion is that Verisign should
immidiately ordered to stop their DNS-trickeries, and
should as soon
as possible be relieved of their duties maintaining the
root zones for
.com and .net.


regards

Dag Øien, Oslo, Norway





------- End of Forwarded Message



--Steve Bellovin, http://www.research.att.com/~smb