From owner-idn@ops.ietf.org Tue Feb 15 11:16:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28032 for ; Tue, 15 Feb 2005 11:16:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D15Fm-000CcY-Q8 for idn-data@psg.com; Tue, 15 Feb 2005 16:08:46 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D15Ff-000Cat-Fn for idn@ops.ietf.org; Tue, 15 Feb 2005 16:08:43 +0000 Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.73]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1FG8LH4027096 for ; Tue, 15 Feb 2005 11:08:25 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1FG8JGL079422; Tue, 15 Feb 2005 11:08:28 -0500 Mime-Version: 1.0 Message-Id: Date: Tue, 15 Feb 2005 11:08:18 -0500 To: idn@ops.ietf.org From: tedd Subject: [idn] homograph attacks Cc: ericj@shmoo.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Hi people: You all knew this was going to happen. http://www.p&1072;ypal.com You might find -- http://www.shmoo.com/idn/homograph.txt -- an interesting read. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Tue Feb 15 14:07:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21363 for ; Tue, 15 Feb 2005 14:07:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D17xV-000Egd-R5 for idn-data@psg.com; Tue, 15 Feb 2005 19:02:05 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D17xS-000Eg1-Fi for idn@ops.ietf.org; Tue, 15 Feb 2005 19:02:02 +0000 Received: (qmail 28502 invoked from network); 15 Feb 2005 19:01:59 -0000 Received: from unknown (HELO [80.185.153.240]) (544451@[80.185.153.240]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Feb 2005 19:01:59 -0000 Message-ID: <42124728.2090507@v.loewis.de> Date: Tue, 15 Feb 2005 20:02:00 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tedd CC: idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > You all knew this was going to happen. > > http://www.p&1072;ypal.com Indeed. However, I am somewhat disheartened that this could happen. IMO, Verisign should have never have registered that domain - the registrar should have provided a language for the label, that language should have been "Russian" (or else &1072; should not have been allowed), and this combination of Cyrillic and Latin letters should not be allowed for the Russian language. Regards, Martin From owner-idn@ops.ietf.org Tue Feb 15 14:12:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22628 for ; Tue, 15 Feb 2005 14:12:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1831-000FUc-OH for idn-data@psg.com; Tue, 15 Feb 2005 19:07:47 +0000 Received: from [65.205.251.75] (helo=robin.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D182x-000FTp-LC for idn@ops.ietf.org; Tue, 15 Feb 2005 19:07:43 +0000 Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (mailer3.verisign.com [65.205.251.55]) by robin.verisign.com (8.12.11/8.12.11) with ESMTP id j1FJ7Yf6007397; Tue, 15 Feb 2005 11:07:39 -0800 (PST) Received: by mou1wnexc03.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 15 Feb 2005 11:07:34 -0800 Message-ID: <66F7005C4F04C14B89DE467C76D2445053D5E4@MOU1WNEXMB01.vcorp.ad.vrsn.com> From: "Krall, Gary" To: "'tedd'" , idn@ops.ietf.org Cc: ericj@shmoo.com Subject: RE: [idn] homograph attacks Date: Tue, 15 Feb 2005 11:07:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk All: And an interesting follow-up by Paul Hoffman: http://LookIt.proper.com/archives/000302.html#000302 Gary. -----Original Message----- From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On Behalf Of tedd Sent: Tuesday, February 15, 2005 8:08 AM To: idn@ops.ietf.org Cc: ericj@shmoo.com Subject: [idn] homograph attacks Hi people: You all knew this was going to happen. http://www.p&1072;ypal.com You might find -- http://www.shmoo.com/idn/homograph.txt -- an interesting read. tedd -- ---------------------------------------------------------------------------- ---- http://sperling.com/ From owner-idn@ops.ietf.org Tue Feb 15 14:27:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25781 for ; Tue, 15 Feb 2005 14:27:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D18I5-000HuB-6V for idn-data@psg.com; Tue, 15 Feb 2005 19:23:21 +0000 Received: from [207.219.45.42] (helo=mx2.namesbeyond.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D18I0-000HtE-GK for idn@ops.ietf.org; Tue, 15 Feb 2005 19:23:16 +0000 Received: from [207.219.45.62] (helo=edmontr3) by mx2.namesbeyond.com with smtp (Exim 4.32) id 1D18Hx-0006fa-Tv for idn@ops.ietf.org; Tue, 15 Feb 2005 14:23:15 -0500 Message-ID: <0acf01c51393$c6f74020$8f01a8c0@edmontr3> From: "Edmon Chung" To: References: Date: Tue, 15 Feb 2005 14:23:03 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-SA-Exim-Connect-IP: 207.219.45.62 X-SA-Exim-Mail-From: edmon@neteka.com Subject: Re: [idn] homograph attacks Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X-SA-Exim-Version: 4.0 (built Fri, 16 Apr 2004 11:36:03 -0400) X-SA-Exim-Scanned: Yes (on mx2.namesbeyond.com) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_05,MIME_BASE64_BLANKS autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgbWVhc3VyZSB0byBkaXNhYmxlIElETiBpcywgbGlrZSBhIENhbnRvbmVzZSBz YXlpbmc6ICJjdXR0aW5nIG9mZiBvbmUncyB0b2VzIHRvIGF2b2lkIHNhbmQgd29ybXMiLi4uDQoN CllvdSBhcmUgcmlnaHQgdGhhdCB3ZSBrbmV3IGFsbCBhbG9uZywgaW4gc29tZSB3YXlzLCBpdCBt YXkgYmUgZ29vZCB0aGF0IGl0IGZpbmFsbHkgZGlkIGhhcHBlbiBhbmQgcmFpc2VkIHNvbWUgY29u Y2Vybi4gIE5vdywgdGhlIHJpZ2h0IGF0dGl0dWRlIGlzIHRvIGFkZHJlc3MgaXQgcmF0aGVyIHRo YW4gc2h5IGF3YXkgZnJvbSBpdC4NCg0KSGVyZSBpcyBhIGxpc3QgSSBwdXQgdG9nZXRoZXIgd2F5 IGJhY2sgb2YgYSBsaXN0IG9mIHRoZSBjaGFyYWN0ZXJzIGluIHRoZSBMYXRpbiwgR3JlZWssIEN5 cmlsaWMsIEFybWVuaWFuIGNoYXJhY3RlcnMgKGJhc2VkIG9uIFVuaWNvZGUpIHRoYXQgY3JlYXRl cyBwb3RlbnRpYWwgImhvbW9ncmFwaHMiDQoNCmEgMDA2MSAwM0IxIDA0MzAgICAgDQpiIDAwNjIg MDNCMiAwNDMyICAgIA0KYyAwMDYzIDA0NDEgMDQ0MSAgICANCsSQIDAxMTEgMDI1NiAgICAgDQpl IDAwNjUgMDNCNSAwNDM1ICAgIA0KyZkgMDI1OSAwNEQ5ICAgICANCmggMDA2OCAwM0I3IDA0M0Qg MDU3MCAwMjlDICANCmkgMDA2OSAwM0I5IDA0NTYgMDRDMCAwMTMxIDA0NTYgMDEzMA0KaiAwMDZB IDA0NTggMDNGMyAwNDU4ICAgDQprIDAwNkIgMDNCQSAgICAgDQrEuCAwMTM4IDA0M0EgICAgIA0K bSAwMDZEIDAzQkMgMDQzQyAgICANCsmvIDAyNkYgMDU2MSAgICAgDQrJsCAwMjcwIDA1N0EgICAg IA0KbiAwMDZFIDAzQkQgMDU3OCAgICANCm8gMDA2RiAwM0JGIDA0M0UgDQpwIDAwNzAgMDNDMSAw NDQwIA0KcyAwMDczIDA0NTUgMDU3RiANCnQgMDA3NCAwM0M0IDA0NDIgDQp1IDAwNzUgMDU3RCAg DQp4IDAwNzggMDNDNyAwNDQ1IA0KeSAwMDc5IDAzQzUgMDRBRiAwNDQzDQp6IDAwN0EgMDNCNiAg DQrOoyAwMjgzIDAzQzMgIA0KDQpJdCBpcyBieSBubyBtZWFucyBleGhhdXN0aXZlLCBidXQgY291 bGQgYmUgYSBzdGFydCB0byB0aGluayBtb3JlIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgaXNzdWUu Li4NCg0KQWxzbywgYmVsb3cgaXMgYSB3cml0ZXVwIGZyb20gSG90dGEtc2FuIG9mIEpQUlMgKHNl bnQgdG8gdGhlIEFQVExEKSBpbiByZXNwb25zZSB0byB0aGUgaXNzdWU6DQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSGlyb0hPVFRBIiA8aG90dGFAanBycy5jby5qcD4N ClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAxMiwgMjAwNSAyOjI2IFBNDQpTdWJqZWN0OiBbbWVt YmVyXSBBYm91dCByZWNlbnQgYXJ0aWNsZXMgcmVnYXJkaW5nIHBoaXNoaW5nIHVzaW5nIGhvbW9n cmFwaHNhbW9uZyBJRE5zDQoNCg0KPiBEZWFyIEFQVExEIGZvbGtzLA0KPiANCj4gQXMgeW91IGFs bCBtYXkgYmUgYXdhcmUsIHBoaXNoaW5nIHVzaW5nIGhvbW9ncmFwaHMgYW1vbmcgSUROcyB3YXMg DQo+IHJlcG9ydGVkLiBodHRwOi8vd3d3LnNobW9vLmNvbS9pZG4vaG9tb2dyYXBoLnR4dA0KPiBU aGUgcmVwb3J0IHdhcyBhbHNvIGludHJvZHVjZWQgaW4gSmFwYW5lc2UgbGFuZ3VhZ2UgYnkgbWVk aWFzLg0KPiBUaGUgZmVhciBzZWVtcyB0b28gbXVjaCBleGFnZ2VyYXRlZCBhbmQgY2FuIGJlIHZl cnkgbXVjaCByZWR1Y2VkIA0KPiBieSBKRVQgYW5kIElDQU5OIGd1aWRlbGluZXMuIFNvLCBKUFJT IG1hZGUgYW4gYW5ub3VuY2VtZW50IG9uIA0KPiB0aGlzIChjdXJyZW50bHkgaW4gSmFwYW5lc2Ug YW5kIHdpbGwgYmUgbWFkZSBpbiBFbmdsaXNoIGluIGEgYSBmZXcgDQo+IGRheXMpLg0KPiBIZXJl IEkgc2VuZCB5b3UgbXkgaW1tYXR1cmUgRW5nbGlzaCB0cmFuc2xhdGlvbiBvZiBvdXIgc3RhdGVt ZW50Lg0KPiBJIGhvcGUgZXZlcnkgY29sbGVhZ3VlIGNjVExEIHdpbGwgbWFrZSBzaW1pbGFyIGFu bm91bmNlbWVudCBhbmQgDQo+IGdpdmUgZWFzZSB0byBJRE4gdXNlcnMuDQo+IA0KPiBSZWdhcmRz LA0KPiBIaXJvDQo+IA0KPiA9PT09PT09PT09PT09PT0NCj4gDQo+IEFib3V0IHJlY2VudCBhcnRp Y2xlcyByZWdhcmRpbmcgcGhpc2hpbmcgdXNpbmcgaG9tb2dyYXBocyBhbW9uZyBJRE5zDQo+IC0g Q291bnRlcm1lYXN1cmVzIGFscmVhZHkgZXhpc3QgYW5kIC5KUCBhbHJlYWR5IGZvbGxvd3MgdGhl bS0NCj4gDQo+IFJlY2VudGx5LCBzZXZlcmFsIGFydGljbGVzIHBvaW50ZWQgb3V0IHRoZSBpbmNy ZWFzZWQgcG9zc2liaWxpdGllcyANCj4gb2YgcGhpc2hpbmcvYXR0YWNraW5nIHVzaW5nIGhvbW9n cmFwaHMgdGhyb3VnaCB0aGUgaW50cm9kdWN0aW9uIG9mIA0KPiBJRE5zLiBIb3dldmVyLCB0aGUg ZXNzZW5jZSBvZiBzdWNoIHByb2JsZW1zIGlzIG5vdCByb290ZWQgb24gdGhlIA0KPiBJRE4gaXRz ZWxmIG9yIGl0cyBhcHBsaWNhdGlvbnMuIFJhdGhlciwgaXQgaXMgYmFzZWQgb24gaG93IGRvbWFp biANCj4gbmFtZSByZWdpc3RyaWVzIGhhbmRsZSBob21vZ3JhcGhzIGFtb25nIGRvbWFpbiBuYW1l IHN0cmluZ3MuIEhlcmUsIA0KPiBleHBsYW5hdGlvbiBpcyBnaXZlbiBmcm9tIHRoZSBmb2xsb3dp bmcgdmlld3BvaW50cyA6DQo+IC0gcm9vdCBvZiB0aGUgcHJvYmxlbQ0KPiAtIGV4aXN0aW5nIGNv dW50ZXJtZWFzdXJlcyB0aGF0IGFyZSBhcHBsaWVkIHRvIElETiByZWdpc3RyYXRpb24gYnkgDQo+ ICAgZG9tYWluIG5hbWUgcmVnaXN0cmllcw0KPiAtIGNvbnNpZGVyYXRpb24gYWxyZWFkeSBnaXZl biB0byBKYXBhbmVzZSAuSlAgZG9tYWluIG5hbWUgDQo+ICAgcmVnaXN0cmF0aW9uIGZyb20gaXRz IGJlZ2lubmluZw0KPiANCj4gSXQgaXMgd29ydGggc3RhdGluZyBoZXJlIHRoYXQgYWx0aG91Z2gg aG9tb2dyYXBocyBhbW9uZyBkb21haW4gDQo+IG5hbWVzIGFyZSBmb2N1c2VkIGhlcmUsIHN1Y2gg dmlzdWFsIGlsbHVzaW9uIGlzIG5vdCBhbiBlZmZlY3RpdmUgDQo+IG1lYW5zIGZvciBwaGlzaGlu Zywgc2luY2UgYWN0dWFsIHBoaXNoaW5nIHVzZXMgbW9yZSBzb3BoaXN0aWNhdGVkIA0KPiB0cmlj a3Mgc3VjaCBhcyBjYW1vdWZsYWdpbmcgb3IgY29uY2VhbGluZyBmYWxzZSBVUklzLg0KPiANCj4g LSByb290IG9mIHRoZSBwcm9ibGVtDQo+IA0KPiBEb21haW4gbmFtZSBpcyBhIGNoYXJhY3RlciBz dHJpbmcuIFRoZSB2YXJpZXR5IG9mIGNoYXJhY3RlcnMgaW4gDQo+IGRvbWFpbiBuYW1lcyBleHBh bmRzIGFuZCBoZW5jZSB0aGUgbnVtYmVyIG9mIHNpbWlsYXItbG9va2luZyANCj4gY2hhcmFjdGVy cyBtYXkgaW5jcmVhc2Ugd2hlbiBJRE4gaXMgaW50cm9kdWNlZC4gUGhpc2hpbmcgdXNpbmcgDQo+ IGhvbW9ncmFwaHMgYW1vbmcgSUROcywgcmVwb3J0ZWQgdGhlc2UgZGF5cywgaXMgYSB0cmljayBw ZXJmb3JtZWQgDQo+IGJ5IGlsbC13aWxsZWQgd2ViLXNpdGUgb3duZXJzIGJ5IG1ha2luZyBiYWQg dXNlIG9mIHNpbWlsYXItbG9va2luZyANCj4gY2hhcmFjdGVycy4gRXNwZWNpYWxseSwgdGhlIGV4 YW1wbGUgb2YgcmVjZW50IGFydGljbGVzIGNsYWltcyB0aGF0IA0KPiB1c2VycyBvZiBJRE4tZW5h YmxlZCBicm93c2VycyBtYXkgYmUgdmlzdWFsbHkgaWxsdWRlZCBhbmQgcGhpc2hlZCANCj4gYnkg YSBmYWxzZSBVUkwgY29udGFpbmluZyBhIG5vbi1BU0NJSSBjaGFyYWN0ZXIgc2ltaWxhciB0byBh biANCj4gQVNDSUkgbGV0dGVyLiANCj4gDQo+IFRoZSByb290IG9mIHRoaXMgcHJvYmxlbSBpcyBh IHZpc3VhbCBpbGx1c2lvbiwgd2hpY2ggYWxyZWFkeSANCj4gZXhpc3RlZCBhbmQgaXMgbm90IG9y aWdpbmFsbHkgaW50cm9kdWNlZCBieSBJRE4uIEZvciBleGFtcGxlLCANCj4gMSAoZGlnaXQpIGFu ZCBsIChsZXR0ZXIgbCkgYXJlIHNpbWlsYXItbG9va2luZyBhbmQgc28gYXMgMCAoZGlnaXQpIA0K PiBhbmQgTyAobGV0dGVyIE8pLiBUaGVzZSBjaGFyYWN0ZXIgcGFpcnMgY2FuIGJlIHVzZWQgZm9y IGlsbHVzaW9uLiANCj4gSG93ZXZlciwgaXQgaXMgdHJ1ZSB0aGF0IGNvbWJpbmF0aW9ucyBvZiBz aW1pbGFyLWxvb2tpbmcgDQo+IGNoYXJhY3RlcnMgaW5jcmVhc2Ugd2hlbiBJRE4gaXMgaW50cm9k dWNlZC4gRm9yIGV4YW1wbGUsIGRhc2ggbWFyayANCj4gZm9yIHByb2xvbmdlZCBzb3VuZCBhbmQg S2FuamkgY2hhcmFjdGVyIGZvciAnZGlnaXQgb25lJywgd2hpY2ggYXJlIA0KPiBib3RoIHVzZWQg aW4gSmFwYW4sIGFyZSB2ZXJ5IHNpbWlsYXItbG9va2luZy4NCj4gDQo+IA0KPiANCj4gVGhpcyBw cm9ibGVtIHdhcyBhbHJlYWR5IGlkZW50aWZpZWQgd2hlbiBJRE4gd2FzIHN0YW5kYXJkaXplZCBh bmQgDQo+IGludHJvZHVjZWQuIENvdW50ZXJtZWFzdXJlcyB0byBzdXBwcmVzcyB0aGUgcHJvYmxl bSB3ZXJlIGFscmVhZHkgDQo+IGludmVzdGlnYXRlZCBhbmQgc3RhbmRhcmRpemVkIGFzIFJGQyBi eSBJRUlGLiBJbiBhZGRpdGlvbiwgDQo+IGd1aWRlbGluZXMgZm9yIGRvbWFpbiBuYW1lIHJlZ2lz dHJpZXMgdG8gY29uZHVjdCBzdWNoIA0KPiBjb3VudGVybWVhc3VyZXMgaGF2ZSBhbHJlYWR5IGJl ZW4gc2V0IHVwIGJ5IElDQU5OLiBBcyBzdWJzY3JpYmVkLCANCj4gdGhlIGNvdW50ZXJtZWFzdXJl cyBhbHJlYWR5IGV4aXN0IGFuZCBob3cgdGhleSBhcmUgZWZmZWN0aXZlIGRlcGVuZCANCj4gb24g aG93IGRvbWFpbiBuYW1lIHJlZ2lzdHJpZXMgdXRpbGl6ZSB0aGVzZSBjb3VudGVybWVhc3VyZXMg aW4gDQo+IHRoZWlyIElETiByZWdpc3RyYXRpb24gc2VydmljZXMgY29uc2lkZXJpbmcgdGhlIGJh bGFuY2UgYmV0d2VlbiB0aGUgDQo+IHVzYWJpbGl0eSBhbmQgY29uc3RyYWludHMgb2YgSUROcy4N Cj4gDQo+IC0gZXhpc3RpbmcgY291bnRlcm1lYXN1cmVzIHRoYXQgYXJlIGFwcGxpZWQgdG8gSURO IHJlZ2lzdHJhdGlvbiBieSANCj4gICBkb21haW4gbmFtZSByZWdpc3RyaWVzIA0KPiANCj4gQXMg c3RhdGVkIGFib3ZlLCB0aGlzIHByb2JsZW0gd2FzIGFscmVhZHkgaWRlbnRpZmllZCBhbmQgdGhl IA0KPiBmb2xsb3dpbmcgZ3VpZGVsaW5lcyB3ZXJlIGFscmVhZHkgcHVibGlzaGVkDQo+IA0KPiBK RVQgZ3VpZGVsaW5lcyAoUkZDMzc0MykgKGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjL3JmYzM3NDMu dHh0KQ0KPiANCj4gR3VpZGVsaW5lcyBmb3IgSUROIHJlZ2lzdHJhdGlvbi4gVGhleSByZXF1ZXN0 cyByZWdpc3RyaWVzIHRvIGRlZmluZSANCj4gbGFuZ3VhZ2VzIHRvIGJlIHJlZ2lzdGVyZWQgYXMg SUROcywgZGVmaW5lIGNoYXJhY3RlciBjb2RlIHBvaW50cyANCj4gYWxsb3dlZCBpbiBJRE5zLCB0 YWcgYSBsYW5ndWFnZSBuYW1lIHRvIGVhY2ggSUROIGF0IHJlZ2lzdHJhdGlvbiB0byANCj4gZXhj bHVkZSBpbmFwcHJvcHJpYXRlIGNoYXJhY3RlcnMsIGFuZCBkZWZpbmUgdmFyaWFudHMgKGlmIGFu eSkgdG8gDQo+IGVhY2ggY2hhcmFjdGVyLiBUaGVzZSBndWlkZWxpbmVzIGFyZSBkZWZpbmVkIGFs b25nIHdpdGggdGFibGUgDQo+IGZvcm1hdHMgYW5kIGFsZ29yaXRobXMuDQo+IA0KPiBJQ0FOTiBn dWlkZWxpbmVzIChodHRwOi8vd3d3LmljYW5uLm9yZy9nZW5lcmFsL2lkbi1ndWlkZWxpbmVzLTIw anVuMDMuaHRtKQ0KPiANCj4gR3VpZGVsaW5lcyBmb3IgdGhlIEltcGxlbWVudGF0aW9uIG9mIElE Tu+9kyBieSByZWdpc3RyaWVzLiBUaGV5IGd1aWRlIA0KPiByZWdpc3RyaWVzIHRvIGZvbGxvdyB0 aGUgSUROIHRlY2huaWNhbCBzdGFuZGFyZHMsIGRlZmluZSBhbGxvd2VkIA0KPiBjaGFyYWN0ZXIg Y29kZSBwb2ludHMsIGFzc29jaWF0aW9uIG9mIGEgc2luZ2xlIGxhbmd1YWdlIHRvIGVhY2ggSURO LCANCj4gY29vcGVyYXRlIHdpdGggcmVsZXZhbnQgYW5kIGludGVyZXN0ZWQgc3Rha2Vob2xkZXIg dG8gZGV2ZWxvcCANCj4gbGFuZ3VhZ2Utc3BlY2lmaWMgcmVnaXN0cmF0aW9uIHBvbGljaWVzLCBl dGMuDQo+IA0KPiBJZiBlYWNoIHJlZ2lzdHJ5IGZvbGxvd3MgdGhlc2UgZ3VpZGVsaW5lcyBpbiBk ZWZpbmluZyB0aGVpciBJRE4gDQo+IHJlZ2lzdHJhdGlvbiBzZXJ2aWNlcywgSUROcyBjb250YWlu aW5nIGNoYXJhY3RlcnMgaW4gdHdvIG9yIG1vcmUgDQo+IGxhbmd1YWdlcyBhcmUgZXhjbHVkZWQs IGFuZCB0aGlzIHJlc3VsdHMgaW4gYSBzaXR1YXRpb24gd2hlcmUgdmlzdWFsIA0KPiBpbGx1c2lv biBieSBzaW1pbGFyLWxvb2tpbmcgY2hhcmFjdGVycyBhcmUgZHJhbWF0aWNhbGx5IHJlZHVjZWQu IEZvciANCj4gZXhhbXBsZSwgaWYgYSBUTEQgcmVnaXN0cnkgZGVmaW5lcyBDeXJpbCBjaGFyYWN0 ZXIgJ++9gScgdG8gYmUgYSANCj4gdmFyaWFudCBvZiBBU0NJSSAnYScgZm9sbG93aW5nIHRoZXNl IGd1aWRlbGluZXMsICdQYXlw772BbCcgaXMgDQo+IHJlZ2FyZGVkIGFzIGlkZW50aWNhbCB0byAn cGF5cGFsJyB1bmRlciB0aGUgVExELg0KPiANCj4gDQo+IE1vc3Qgb2YgdGhlIHJlZ2lzdHJpZXMg dGhhdCBjdXJyZW50bHkgcHJvdmlkZSBJRE4gcmVnaXN0cmF0aW9uIA0KPiBmb2xsb3cgdGhlc2Ug Z3VpZGVsaW5lcyBvciBwbGFuIHRvIGRvIHNvLiBBcyBhIHJlc3VsdCwgcGhpc2hpbmcgd2l0aCAN Cj4gc2ltaWxhci1sb29raW5nIElETnMgd2l0aCBJRE4tYXdhcmUgYnJvd3NlcnMgaXMgZXh0cmVt ZWx5IHN1cHByZXNzZWQuDQo+IA0KPiAtIGNvbnNpZGVyYXRpb24gYWxyZWFkeSBnaXZlbiB0byBK YXBhbmVzZSAuSlAgZG9tYWluIG5hbWUgDQo+ICAgcmVnaXN0cmF0aW9uIGZyb20gaXRzIGJlZ2lu bmluZw0KPiANCj4gT25seSBLYW5qaSwgSGlyYWdhbmEsIEthdGFrYW5hLCBhbmQgTERILCB3aGlj aCBhbGwgYXJlIHVzdWFsbHkgdXNlZCANCj4gaW4gSmFwYW4sIGFyZSBhbGxvd2VkIHRvIGJlIHVz ZWQgaW4gSmFwYW5lc2UgSlAgZG9tYWluIG5hbWVzLiANCj4gQ2hhcmFjdGVycyB0aGF0IGFyZSB2 aXN1YWxseSBzaW1pbGFyIHRvIEFTQ0lJIGFscGhhYmV0cywgaS5lLiwgQ3lyaWwgDQo+IGNoYXJh Y3RlciAn772BJywgYXJlIG5vdCBhbGxvd2VkIGFuZCB0aHVzIElETnMgdGhhdCBhcmUgDQo+IHNp bWlsYXItbG9va2luZyB0byBBU0NJSSBkb21haW4gbmFtZXMgZG8gbm90IGV4aXN0IHVuZGVyIC5K UCBUTEQuIA0KPiBGb3IgZXhhbXBsZSwgJ1BheXDvvYFsLmpwJyBjYW5ub3QgYmUgcmVnaXN0ZXJl ZCBhbmQgY2Fubm90IGJlIHVzZWQgYXMgDQo+IGZhbHNlIHNpdGUgZm9yIHBoaXNoaW5nLg0KPiAN Cj4gSW4gYWRkaXRpb24sIHRoZXJlIGFyZSB0aG91Z2h0IHRvIGJlIGxlc3MgdmlzdWFsIGlsbHVz aW9uIGluIA0KPiBKYXBhbmVzZSBjaGFyYWN0ZXIgc3RyaW5ncyB0aGFuIGluIHN0cmluZ3Mgb25s eSBpbiBFbmdsaXNoIGFscGhhYmV0cyANCj4gZm9yIHRoZSBwZW9wbGUgd2hvIGFyZSBmYW1pbGlh ciB3aXRoIEphcGFuZXNlIHN0cmluZ3MgYW5kIGFyZSBub3QgDQo+IGZhbWlsaWFyIHdpdGggRW5n bGlzaCBzcGVsbGluZy4gVGhlc2UgY291bnRlcm1lYXN1cmVzIGhhdmUgYmVlbiANCj4gYXBwbGll ZCB0byBKYXBhbmVzZSBKUCBkb21haW4gbmFtZXMgZnJvbSB0aGUgdGltZSBvZiBmaXJzdCANCj4g cmVnaXN0cmF0aW9uLg0KPiANCj4gSG93ZXZlciwgc3VjaCBwcm9ibGVtcyBtYXkgdGVuZCB0byB0 YWtlIHBsYWNlIG1vcmUgZWFzaWx5IGluIGEgDQo+IHNlcnZpY2UgYnkgcmVnaXN0cmllcyB3aGlj aCBkb24ndCBmb2xsb3cgdGhlc2UgZ3VpZGVsaW5lcy4gQXMgc3RhdGVkIA0KPiBhYm92ZSwgdGhl IHByb2JsZW0gaXMgcm9vdGVkIGluIElETiByZWdpc3RyYXRpb24gcG9saWNpZXMgb2YgZWFjaCAN Cj4gZG9tYWluIG5hbWUgcmVnaXN0cnkgbm90IGluIElETi1hd2FyZSBhcHBsaWNhdGlvbnMgc3Vj aCBhcyBicm93c2Vycy4gDQo+IEphcGFuZXNlIEpQIGRvbWFpbiBuYW1lcywgd2hpY2ggd2VyZSBp bnRyb2R1Y2VkIGNvbnNpZGVyaW5nIHRoZSANCj4gYWJvdmUsIGNhbiBiZSB1c2VkIHdpdGhvdXQg c3R1cGVuZG91cyBjYXV0aW9ucy4NCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBtZW1iZXIgbWFpbGluZyBsaXN0DQo+IG1lbWJlckBh cHRsZC5vcmcNCj4gaHR0cDovL2ludGVybmV0bnoubmV0Lm56L21haWxtYW4vbGlzdGluZm8vbWVt YmVyDQo+IA0KDQoNCg0KRWRtb24NCg0KDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJ0ZWRkIiA8dGVkZEBzcGVybGluZy5jb20+DQpUbzogPGlkbkBvcHMuaWV0Zi5v cmc+DQpDYzogPGVyaWNqQHNobW9vLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDE1LCAy MDA1IDExOjA4IEFNDQpTdWJqZWN0OiBbaWRuXSBob21vZ3JhcGggYXR0YWNrcw0KDQoNCj4gSGkg cGVvcGxlOg0KPiANCj4gWW91IGFsbCBrbmV3IHRoaXMgd2FzIGdvaW5nIHRvIGhhcHBlbi4NCj4g DQo+ICAgICBodHRwOi8vd3d3LnAmMTA3Mjt5cGFsLmNvbQ0KPiANCj4gWW91IG1pZ2h0IGZpbmQg LS0NCj4gDQo+ICAgICBodHRwOi8vd3d3LnNobW9vLmNvbS9pZG4vaG9tb2dyYXBoLnR4dA0KPiAN Cj4gLS0gYW4gaW50ZXJlc3RpbmcgcmVhZC4NCj4gDQo+IHRlZGQNCj4gLS0gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IGh0dHA6Ly9zcGVybGluZy5jb20vDQo+ From owner-idn@ops.ietf.org Tue Feb 15 14:33:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26277 for ; Tue, 15 Feb 2005 14:33:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D18Oi-000J7x-8N for idn-data@psg.com; Tue, 15 Feb 2005 19:30:12 +0000 Received: from [209.132.96.45] (helo=skutsje.san.webweaving.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D18Oh-000J7k-BS for idn@ops.ietf.org; Tue, 15 Feb 2005 19:30:11 +0000 Received: from skutsje.san.webweaving.org (skutsje.san.webweaving.org [209.132.96.45] (may be forged)) by skutsje.san.webweaving.org (8.12.9/8.12.9) with ESMTP id j1FJUALA089709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Feb 2005 11:30:11 -0800 (PST) (envelope-from dirkx@webweaving.org) Received: from localhost (dirkx@localhost) by skutsje.san.webweaving.org (8.12.9/8.12.9/Submit) with ESMTP id j1FJUA8r089706; Tue, 15 Feb 2005 11:30:10 -0800 (PST) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: skutsje.san.webweaving.org: dirkx owned process doing -bs Date: Tue, 15 Feb 2005 11:30:10 -0800 (PST) From: Dirk-Willem van Gulik X-X-Sender: dirkx@skutsje.san.webweaving.org To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= cc: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks Message-ID: <20050215112522.D89528@skutsje.san.webweaving.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8BIT On Tue, 15 Feb 2005, "Martin v. Lwis" wrote: > > http://www.p&1072;ypal.com > > Indeed. However, I am somewhat disheartened that this could > happen. IMO, Verisign should have never have registered that > domain - the registrar should have provided a language for > the label, that language should have been "Russian" (or > else &1072; should not have been allowed), and this combination > of Cyrillic and Latin letters should not be allowed for the > Russian language. Which is easier than it sounds - there are thousands of homonyms in unicode (depending on the font sometimes even significantly more) and even in the easy western european languages you may have a accentgrave dropping of in some fonts/cases with lowercase chars. And wether it is a true homonym may differ from language to language and even depends on wether this is uppercase or not. Even in an easy language like dutch - would you see the difference between wwww.ijselmeer.nl and www.?selmeer.nl ('i'+'j' or just unicode 0133 (or 0133 for uppercase)) ? And even that - to a lot of readers the URLs www.langorse.co.uk and www.1angorse.co.uk will appear identical. (Try Courier (new) or Gill Sans). Plus it is not uncommon in some asian company/logo's to see essentially two or even three "scripts" combined. Dw From owner-idn@ops.ietf.org Tue Feb 15 14:34:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26403 for ; Tue, 15 Feb 2005 14:34:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D18Ph-000JEy-1Q for idn-data@psg.com; Tue, 15 Feb 2005 19:31:13 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D18Pe-000JEY-UX for idn@ops.ietf.org; Tue, 15 Feb 2005 19:31:11 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j1FJPvop003842; Tue, 15 Feb 2005 14:25:57 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Tue, 15 Feb 2005 14:31:08 -0500 Message-ID: From: "Kane, Pat" To: =?iso-8859-1?Q?=27=22Martin_v=2E_L=F6wis=22=27?= , tedd Cc: idn@ops.ietf.org, ericj@shmoo.com Subject: RE: [idn] homograph attacks Date: Tue, 15 Feb 2005 14:30:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable VeriSign does prevent domains with the Russian language tag from = commingling A-Z with the Cyrillic characters. It does permit 0-9 and the dash to = be used. This filter also applies to other Cyrillic based languages such = as Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. =20 There are other languages that are listed within ISO 639-2 that today = use a combination of Latin and Cyrillic as they were originally Latin based = (Tajik was Arabic prior to being Latin based), migrated to Cyrillic during the Soviet era and today are migrating back to Latin. It is common to use = Latin and Cyrillic characters in Tajik, from what I understand not being a = native speaker. Granted there are not a lot of registrations in com net that = are Tajik, but this is just the point of an IDN. Pat Kane -----Original Message----- From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf = Of "Martin v. L=F6wis" Sent: Tuesday, February 15, 2005 2:02 PM To: tedd Cc: idn@ops.ietf.org; ericj@shmoo.com Subject: Re: [idn] homograph attacks tedd wrote: > You all knew this was going to happen. >=20 > http://www.p&1072;ypal.com Indeed. However, I am somewhat disheartened that this could happen. IMO, Verisign should have never have registered that domain - the registrar should have provided a language for the label, that language should have been "Russian" (or else &1072; should not have been allowed), and this combination of Cyrillic and Latin letters should not be allowed for the Russian language. Regards, Martin From owner-idn@ops.ietf.org Tue Feb 15 15:19:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07045 for ; Tue, 15 Feb 2005 15:19:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D195c-0000Bv-Kw for idn-data@psg.com; Tue, 15 Feb 2005 20:14:32 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D195Z-0000Be-Gn for idn@ops.ietf.org; Tue, 15 Feb 2005 20:14:29 +0000 Received: (qmail 12060 invoked from network); 15 Feb 2005 20:14:27 -0000 Received: from unknown (HELO [80.185.153.240]) (544451@[80.185.153.240]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Feb 2005 20:14:27 -0000 Message-ID: <42125822.6030302@v.loewis.de> Date: Tue, 15 Feb 2005 21:14:26 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk-Willem van Gulik CC: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: <20050215112522.D89528@skutsje.san.webweaving.org> In-Reply-To: <20050215112522.D89528@skutsje.san.webweaving.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dirk-Willem van Gulik wrote: >>Indeed. However, I am somewhat disheartened that this could >>happen. IMO, Verisign should have never have registered that >>domain - the registrar should have provided a language for >>the label, that language should have been "Russian" (or >>else &1072; should not have been allowed), and this combination >>of Cyrillic and Latin letters should not be allowed for the >>Russian language. > > > Which is easier than it sounds - there are thousands of homonyms in > unicode (depending on the font sometimes even significantly more) and even > in the easy western european languages you may have a accentgrave dropping > of in some fonts/cases with lowercase chars. Please read carefully. I'm not at all suggesting that homo*graphs* should be used in considering whether registration is allowed. I'm suggesting that Verisign does what they say they do: define "language packs" for each language, see http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_001382.html > Even in an easy language like dutch - would you see the difference between > wwww.ijselmeer.nl and www.?selmeer.nl ('i'+'j' or just unicode 0133 (or > 0133 for uppercase)) ? By design, IDN normalizes U+0133 as ij, so whether you have "ij" or "ij" in the URL - IDNA will resolve that as the same machine in all cases. > Plus it is not uncommon in some asian company/logo's to see essentially > two or even three "scripts" combined. Yes, that's why the language pack needs to define what characters are acceptable. For example, in the .de zone, you simply cannot register labels with Cyrillic or Japanese characters - DENIC just won't register them, by policy. An adequate policy should be in place for .COM as well. Indeed, the SRS (shared registry system) requires that each registrar provides a language tag for each IDN label. I'm curious why this failed for the paypal case. Regards, Martin From owner-idn@ops.ietf.org Tue Feb 15 15:32:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08749 for ; Tue, 15 Feb 2005 15:32:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D19Jj-0001rm-KV for idn-data@psg.com; Tue, 15 Feb 2005 20:29:07 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D19Ji-0001rO-CK for idn@ops.ietf.org; Tue, 15 Feb 2005 20:29:06 +0000 Received: (qmail 24891 invoked from network); 15 Feb 2005 20:29:06 -0000 Received: from unknown (HELO [80.185.153.240]) (544451@[80.185.153.240]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 15 Feb 2005 20:29:06 -0000 Message-ID: <42125B90.20609@v.loewis.de> Date: Tue, 15 Feb 2005 21:29:04 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kane, Pat" CC: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kane, Pat wrote: > VeriSign does prevent domains with the Russian language tag from commingling > A-Z with the Cyrillic characters. It does permit 0-9 and the dash to be > used. This filter also applies to other Cyrillic based languages such as > Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. > > There are other languages that are listed within ISO 639-2 that today use a > combination of Latin and Cyrillic as they were originally Latin based (Tajik > was Arabic prior to being Latin based), migrated to Cyrillic during the > Soviet era and today are migrating back to Latin. Thanks for the clarification. Is this information publically available somehow? On http://www.verisign.com/static/002533.pdf I can find the language code list (which shows that indeed TGK and RUS might be treated differently); I wonder whether you somehow list the constraints implemented for each tag. How did the applicant know that he would have to use Tajik in order to get a cyrillic letter into an otherwise latin label? As for the Tajik writing system: why is it then necessary to allow mixed scripts? Wouldn't the Tajik users be satisfied if you could either register all-Latin or all-Cyrillic labels (perhaps allowing all-Arabic as well)? Regards, Martin From owner-idn@ops.ietf.org Tue Feb 15 19:53:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06757 for ; Tue, 15 Feb 2005 19:53:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1DKt-0009tr-6X for idn-data@psg.com; Wed, 16 Feb 2005 00:46:35 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1DKp-0009tY-Td for idn@ops.ietf.org; Wed, 16 Feb 2005 00:46:32 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1DKl-0004In-0q; Tue, 15 Feb 2005 16:46:29 -0800 Message-Id: <6.1.2.0.2.20050216013649.02ec2c20@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Feb 2005 01:43:51 +0100 To: "Kane, Pat" , "'\"Martin v. Lwis\"'" , tedd From: "JFC (Jefsey) Morfin" Subject: RE: [idn] homograph attacks Cc: idn@ops.ietf.org, ericj@shmoo.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dear Pat, I have several questions here. 1. where do you maintain an ASCII list of your language tags? Should it not be supported on the IANA server and common to all the gTLDs? 2. is there a list of the permitted UNICODEs codes per languages? For example I am interested in the French and Ukrainian sets. 3. did you decide them by yourself, or did you gather a group of lingual authorities to assist you. This would be very interesting. 4. would there not be a way to register IDN in using their "xn--" version? It would simplify international management by resellers? Thank you for your assistance. At 20:30 15/02/2005, Kane, Pat wrote: >VeriSign does prevent domains with the Russian language tag from commingling >A-Z with the Cyrillic characters. It does permit 0-9 and the dash to be >used. This filter also applies to other Cyrillic based languages such as >Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. > >There are other languages that are listed within ISO 639-2 that today use a >combination of Latin and Cyrillic as they were originally Latin based (Tajik >was Arabic prior to being Latin based), migrated to Cyrillic during the >Soviet era and today are migrating back to Latin. It is common to use Latin >and Cyrillic characters in Tajik, from what I understand not being a native >speaker. Granted there are not a lot of registrations in com net that are >Tajik, but this is just the point of an IDN. > >Pat Kane > > >-----Original Message----- >From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf Of >"Martin v. Lwis" >Sent: Tuesday, February 15, 2005 2:02 PM >To: tedd >Cc: idn@ops.ietf.org; ericj@shmoo.com >Subject: Re: [idn] homograph attacks > >tedd wrote: > > You all knew this was going to happen. > > > > http://www.p&1072;ypal.com > >Indeed. However, I am somewhat disheartened that this could >happen. IMO, Verisign should have never have registered that >domain - the registrar should have provided a language for >the label, that language should have been "Russian" (or >else &1072; should not have been allowed), and this combination >of Cyrillic and Latin letters should not be allowed for the >Russian language. > >Regards, >Martin From owner-idn@ops.ietf.org Wed Feb 16 01:19:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25404 for ; Wed, 16 Feb 2005 01:19:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1IQC-0007pQ-AI for idn-data@psg.com; Wed, 16 Feb 2005 06:12:24 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1IQA-0007pB-FW for idn@ops.ietf.org; Wed, 16 Feb 2005 06:12:22 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 22:12:21 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 22:12:32 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 22:12:21 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 22:12:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] homograph attacks Date: Tue, 15 Feb 2005 22:12:21 -0800 Message-ID: Thread-Topic: [idn] homograph attacks thread-index: AcUTngjACNgNOJQyQUSJ5z5iUWTr4wATvUpg From: "Michel Suignard" To: "Kane, Pat" Cc: , , =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , "tedd" X-OriginalArrivalTime: 16 Feb 2005 06:12:20.0532 (UTC) FILETIME=[7921A740:01C513EE] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable No languages used in the former soviet union should require a mix of = latin and cyrillic in a single dns label. Unicode contains many latin homographs in the Cyrillic block exactly for = that reason, to avoid mixing the two scripts in a single word. It is = unfortunate that the exact visual match is now haunting us. However it = should not be used as a rationale to accept registration of mixed = Cyrillic/Latin labels by tld registries. To answer another message in this thread, there is no definitive answer = about which Unicode characters are allowed for a given languages. But in = all languages that have a reasonable concept of 'words', you should = never need to allow mixed script in a word, at least in the context of = IDN label. There are exceptions to these rules, like in South and East = Asia (Japanese comes to mind), but these languages can be detected = reasonably using the Unicode script property. Michel=20 -----Original Message----- From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf = Of Kane, Pat VeriSign does prevent domains with the Russian language tag from = commingling A-Z with the Cyrillic characters. It does permit 0-9 and = the dash to be used. This filter also applies to other Cyrillic based = languages such as Belarusian, Ukrainian, Serbian, Macedonian and = Bulgarian. =20 There are other languages that are listed within ISO 639-2 that today = use a combination of Latin and Cyrillic as they were originally Latin = based (Tajik was Arabic prior to being Latin based), migrated to = Cyrillic during the Soviet era and today are migrating back to Latin. = It is common to use Latin and Cyrillic characters in Tajik, from what I = understand not being a native speaker. Granted there are not a lot of = registrations in com net that are Tajik, but this is just the point of = an IDN. Pat Kane From owner-idn@ops.ietf.org Wed Feb 16 01:54:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28078 for ; Wed, 16 Feb 2005 01:54:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1J1U-000DrR-SK for idn-data@psg.com; Wed, 16 Feb 2005 06:50:56 +0000 Received: from [80.67.18.13] (helo=smtprelay01.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1J1Q-000Dqp-V1 for idn@ops.ietf.org; Wed, 16 Feb 2005 06:50:53 +0000 Received: (qmail 22791 invoked from network); 16 Feb 2005 06:50:50 -0000 Received: from unknown (HELO [80.185.155.176]) (544451@[80.185.155.176]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 06:50:50 -0000 Message-ID: <4212ED49.8060303@v.loewis.de> Date: Wed, 16 Feb 2005 07:50:49 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: "Kane, Pat" , tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: <6.1.2.0.2.20050216013649.02ec2c20@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050216013649.02ec2c20@mail.jefsey.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I don't speak for Verisign, but I can answer some of the questions: > 1. where do you maintain an ASCII list of your language tags? It is *maintained* probably on some development infrastructure inside Verisign, it is published atleast at http://www.verisign.com/static/002533.pdf (found on http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_002088.html ) > Should it not be supported on the IANA server and common to all the gTLDs? I personally don't see why it should be on a IANA server. It is specific to the SRS (so I assume it is also described in the SRS documentation). The only real users of the ASCII list of language tags (what is an ASCII list, BTW?) are the SRS users, as they need to communicate the language code to the SRS. As for "should it be common to all the gTLDs", I honestly believe the answer should be "no". Each registrar can come up with its own policy - in particular, the question whether to support IDN or not alone is the choice of the registrar. But then, I don't care that much about IDN in .gov and .mil... For .int, it seems natural to never allow IDN. The other gTLD registries apparently haven't considered IDN yet. > 2. is there a list of the permitted UNICODEs codes per languages? For > example I am interested in the French and Ukrainian sets. This I wonder myself. The answer to your literal question is certainly "yes". The corollary question is "can we get it?" to which the answer might be "if you are a SRS participant", or "no". > 3. did you decide them by yourself, or did you gather a group of lingual > authorities to assist you. This would be very interesting. See http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_001485.html While working to address the issue of character variants, VeriSign has consulted and will continue to work with all interested stakeholders. These groups include China Network Information Center (CNNIC) (.cn), Taiwan Network Information Center (TWNIC) (.tw), Korea Network Information Center (KRNIC) (.kr), Japan Registry Service (JPRS) (.jp), the Chinese Domain Name Consortium (CDNC), and the IDN Implementation Committee established by ICANN. > 4. would there not be a way to register IDN in using their "xn--" > version? It would simplify international management by resellers? Why do you think the SRS currently does not use the xn-- version in registrations? I believe it does - the registrar has to provide the xn-- version, but the SRS will *still* perform the language filters as if a sequence of Unicode characters was provided. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 02:02:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01040 for ; Wed, 16 Feb 2005 02:02:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1J9c-000Fen-Hl for idn-data@psg.com; Wed, 16 Feb 2005 06:59:20 +0000 Received: from [80.67.18.13] (helo=smtprelay01.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1J9a-000Fe4-E9 for idn@ops.ietf.org; Wed, 16 Feb 2005 06:59:18 +0000 Received: (qmail 24306 invoked from network); 16 Feb 2005 06:59:17 -0000 Received: from unknown (HELO [80.185.155.176]) (544451@[80.185.155.176]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 06:59:17 -0000 Message-ID: <4212EF44.4040208@v.loewis.de> Date: Wed, 16 Feb 2005 07:59:16 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Suignard wrote: > To answer another message in this thread, there is no definitive > answer about which Unicode characters are allowed for a given > languages. There is no definitive answer to that question. However, I sure hope there is a definitive answer to the question "which Unicode characters are allowed for a given language" *when used as a label in the .COM zone*. For another example, the definitive list of (additional) characters for a German label in the .DE zone is http://www.denic.de/de/domains/idns/liste.html On the other hand, a German label in the .CH zone is http://www.switch.ch/de/id/faq/idn.html which is a subset of the .DE list. I'm (now) certain that Verisign has a definitive list of characters for a German label in the .COM zone (and I expect this is the same list that DENIC uses, as that is the superset of the Austrian and Swiss sets). Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 02:11:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09690 for ; Wed, 16 Feb 2005 02:11:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1JHs-000HwR-VZ for idn-data@psg.com; Wed, 16 Feb 2005 07:07:52 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1JHr-000HwA-Ow for idn@ops.ietf.org; Wed, 16 Feb 2005 07:07:52 +0000 Received: (qmail 1940 invoked from network); 16 Feb 2005 07:07:50 -0000 Received: from unknown (HELO [80.185.155.176]) (544451@[80.185.155.176]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 07:07:50 -0000 Message-ID: <4212F145.8020005@v.loewis.de> Date: Wed, 16 Feb 2005 08:07:49 +0100 From: =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soobok Lee CC: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: <42124728.2090507@v.loewis.de> <4212ED49.9000203@lsb.org> In-Reply-To: <4212ED49.9000203@lsb.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Soobok Lee wrote: > All Cyrillic label "HP" (.com) can be registered even in Russian > language pack. > > Cyrillic "HP".COM in its uppercase form looks the same as all ASCII > "HP.COM". > > Any Registration Process should filter out these "HP" like combinations.. I think this is unreasonable. The lower-case forms ("НР" vs "hp") look quite differently, and browsers typically display domain names in all-lower in the address bar. The other question, of course, is whether two-letter domain names should be allowed in the first place, but this is off-topic. If they are allowed, you should not ban pairs of cyrillic or greek letters just because they are homograph with a latin combination. Then, the same would apply to Greek vs. Cyrillic. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 04:50:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19086 for ; Wed, 16 Feb 2005 04:49:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1LjU-000ANI-GY for idn-data@psg.com; Wed, 16 Feb 2005 09:44:32 +0000 Received: from [212.227.126.201] (helo=mxintern.schlund.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1LjT-000AMw-02 for idn@ops.ietf.org; Wed, 16 Feb 2005 09:44:31 +0000 Received: from [172.19.16.7] (helo=home.kundenserver.de) by mxintern.kundenserver.de with esmtp (Exim 4.34) id 1D1LjM-0005T5-5q; Wed, 16 Feb 2005 10:44:24 +0100 Received: from tom by home.kundenserver.de with local (Exim 3.35 #1) id 1D1LjM-0007hX-00; Wed, 16 Feb 2005 10:44:24 +0100 Date: Wed, 16 Feb 2005 10:44:24 +0100 From: Thomas Keller To: Michel Suignard Cc: "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, Martin =?iso-8859-1?Q?v=2E_L=F6wis?= , tedd Subject: Re: [idn] homograph attacks Message-ID: <20050216094424.GH25086@schlund.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Schlund + Partner AG User-Agent: Mutt/1.5.5.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk I'm by no means a linguist but I would assume that there are a plethora of good and usefull mixtures of scripts that exist in daily life. Passing this problem (of which all of us have been aware of for years now) back to the policy arena won't help anyone since I doubt that there can be any kind working group (now or in the future) that can come up with a good rational for all scripts and languages without restricting "good" and usefull mixtures. By design the IDNA processing happens inside the application and therefore in my thinking the applications are the right place for any security meassures as well. Talking about about security measures we have to think about what exactly we want to prevent from happening. Do we in general want to battle fraud than we would have to have a look at typo domain names like pajpal.com as well or is the goal to enable the user to better understand exactly what URL he is using. In that case we are not talking about security anymore but about awareness. If a user is aware of the fact that a URL he wants to use is a mixture of scripts he can decide for himself whether he wants to trust it or not. I guess thats fair enough afterall are all users responsible for there own behavior and the risks comming along with it. Best, tom Am 15.02.2005 schrieb Michel Suignard: > No languages used in the former soviet union should require a mix of latin and cyrillic in a single dns label. > Unicode contains many latin homographs in the Cyrillic block exactly for that reason, to avoid mixing the two scripts in a single word. It is unfortunate that the exact visual match is now haunting us. However it should not be used as a rationale to accept registration of mixed Cyrillic/Latin labels by tld registries. > > To answer another message in this thread, there is no definitive answer about which Unicode characters are allowed for a given languages. But in all languages that have a reasonable concept of 'words', you should never need to allow mixed script in a word, at least in the context of IDN label. There are exceptions to these rules, like in South and East Asia (Japanese comes to mind), but these languages can be detected reasonably using the Unicode script property. > > Michel > > -----Original Message----- > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf Of Kane, Pat > > VeriSign does prevent domains with the Russian language tag from commingling A-Z with the Cyrillic characters. It does permit 0-9 and the dash to be used. This filter also applies to other Cyrillic based languages such as Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. > > There are other languages that are listed within ISO 639-2 that today use a combination of Latin and Cyrillic as they were originally Latin based (Tajik was Arabic prior to being Latin based), migrated to Cyrillic during the Soviet era and today are migrating back to Latin. It is common to use Latin and Cyrillic characters in Tajik, from what I understand not being a native speaker. Granted there are not a lot of registrations in com net that are Tajik, but this is just the point of an IDN. > > Pat Kane > > > > Gruss, tom (__) (OO)_____ (oo) /|\ A cow is not entirely full of | |--/ | * milk some of it is hamburger! w w w w From owner-idn@ops.ietf.org Wed Feb 16 05:35:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22374 for ; Wed, 16 Feb 2005 05:35:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1MRN-000Idt-RE for idn-data@psg.com; Wed, 16 Feb 2005 10:29:53 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1MRD-000Iaf-Qi for idn@ops.ietf.org; Wed, 16 Feb 2005 10:29:44 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1GATfJR010969 for ; Wed, 16 Feb 2005 19:29:42 +0900 Message-ID: <42132091.4010600@lsb.org> Date: Wed, 16 Feb 2005 19:29:37 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] homogram attacks: cyrillic and registration guideline Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit IDN WG had discussed about this IDN-based homogram attacks 3 years ago. The conclustion is that: the problem should be solved in registration stage, not in encoding/protocol level. So we have now "IDN registration guideline for CJK (han ideographs) languages", but that does not cover cyrillic / greek ones yet. IETF seems to have no plan to expand and publish it. that is, "Do it yourself , registries !", http://www.unicode.org/charts/PDF/U0400.pdf I ask you all to open this PDF unicode chart and see how many lowercase cyrllic alhpabets look exactly the same as their latin-alphabet lowercase counterparts . To list some of them, " a e i y c o s j". (some of them are not russian,but for eastern europe) In the uppercase characters, "B H M P" including the above 8 chars. cyrillicHP.com /ascii HP.com came from the latter category. please compare the lowercase "cyrillic iii.com" with ascii "iii.com" . In the address bar, they may look exactly the same, because cyrillic/ascii fonts are almost the same ones in many OS/GUI environments. Soobok From owner-idn@ops.ietf.org Wed Feb 16 06:09:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24803 for ; Wed, 16 Feb 2005 06:09:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1MzC-000PTX-Ai for idn-data@psg.com; Wed, 16 Feb 2005 11:04:50 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Mz2-000PMd-AC for idn@ops.ietf.org; Wed, 16 Feb 2005 11:04:40 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1Mz1-00087N-CG for idn@ops.ietf.org; Wed, 16 Feb 2005 03:04:39 -0800 Message-Id: <6.1.2.0.2.20050216114841.032d7eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Feb 2005 12:02:30 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] homogram attacks: cyrillic and registration guideline In-Reply-To: <42132091.4010600@lsb.org> References: <42132091.4010600@lsb.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Dear Soobook, it would have been so easy to say 'all the IDNs are to be punycoded 3LD+ with "xn--ISO 639 language code" as an SLD, language code+TLD being documented by the TLD table'. This would have permitted additional limited/full mixed tables in permitting ISO 639+1 or 2 chars tags. This would have been so coherent with DNS that this is probably the way plug-ins resolve the problem, until some fed-up Govs create their own conpressed "xn--ISO 639.ccTLD" version under the form of MLTLDs with their common addition to the root. Anyway all this is of low interest since what we discuss are SLDs, not 3LDs and lower where the registrant is free. jfc On 11:29 16/02/2005, Soobok Lee said: >IDN WG had discussed about this IDN-based homogram attacks 3 years ago. >The conclustion is that: the problem should be solved in registration stage, > not in encoding/protocol level. > >So we have now "IDN registration guideline for CJK (han ideographs) >languages", but that >does not cover cyrillic / greek ones yet. IETF seems to have no >plan to expand and >publish it. that is, "Do it yourself , registries !", > >http://www.unicode.org/charts/PDF/U0400.pdf > >I ask you all to open this PDF unicode chart and see how many >lowercase cyrllic >alhpabets look exactly the same as their latin-alphabet lowercase >counterparts . > >To list some of them, " a e i y c o s j". >(some of them are not russian,but for eastern europe) > >In the uppercase characters, "B H M P" including the above 8 chars. >cyrillicHP.com /ascii HP.com came from the latter category. > >please compare the lowercase "cyrillic iii.com" with ascii "iii.com" >. In the address bar, >they may look exactly the same, because cyrillic/ascii fonts are almost >the same ones >in many OS/GUI environments. > >Soobok > > > From owner-idn@ops.ietf.org Wed Feb 16 06:10:20 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24911 for ; Wed, 16 Feb 2005 06:10:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Mz3-000PN0-Sc for idn-data@psg.com; Wed, 16 Feb 2005 11:04:41 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Mz1-000PMR-9f for idn@ops.ietf.org; Wed, 16 Feb 2005 11:04:39 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1Mz0-00087N-2s for idn@ops.ietf.org; Wed, 16 Feb 2005 03:04:38 -0800 Message-Id: <6.1.2.0.2.20050216110348.04110630@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Feb 2005 12:04:30 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] homograph attacks In-Reply-To: <4212EF44.4040208@v.loewis.de> References: <4212EF44.4040208@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit I will try to review some of the points with an intergovernance consistency in mind (what we want the user to get the same service whatever the Registry). On 07:12 16/02/2005, Michel Suignard said: >No languages used in the former soviet union should require a mix of latin >and cyrillic in a single dns label. Recent Ukrainian comments on ietf-languages@alvestrand.no (the reference list for language tags) said they are back to roman characters, so I suppose there are mixed TMs which need a mix. This shows the WIPO should be part of the debate. >To answer another message in this thread, there is no definitive answer >about which Unicode characters are allowed for a given languages. In a domain name, yes: the IANA Table by the ccTLD Manager. In an IRI DN part this should be the same. Beware, these are just ICANN recommendations to sovereign entities. What we should agree upon is that when there is a mix, the user could be warned a way or another. >But in all languages that have a reasonable concept of 'words', you should >never need to allow mixed script in a word, at least in the context of IDN >label. There are exceptions to these rules, like in South and East Asia >(Japanese comes to mind), but these languages can be detected reasonably >using the Unicode script property. As discussed above, this is debatable. But the mere fact that you accept an exception create the need to support what happens in such cases. At 07:50 16/02/2005, Martin v. Lwis wrote: >I don't speak for Verisign, but I can answer some of the questions: You comment them. My questions to Pat Kane remain. >>1. where do you maintain an ASCII list of your language tags? > >It is *maintained* probably on some development infrastructure inside >Verisign, it is published atleast at > >http://www.verisign.com/static/002533.pdf PDF is hardly an ASCII list. >>Should it not be supported on the IANA server and common to all the gTLDs? > >I personally don't see why it should be on a IANA server. >As for "should it be common to all the gTLDs", I honestly believe >the answer should be "no". These opinions of yours are opposed by gTLD contracts with ICANN. There is a IANA registration for IDN Table, even very poor. The proposed "RFC 3066bis" Draft lead to a debate where the authors who are discussing the language tags to be registered by IANA described as outrageous the idea that they should consider IDNs and be consistent with them. Do you support that? >>3. did you decide them by yourself, or did you gather a group of lingual >>authorities to assist you. This would be very interesting. > >While working to address the issue of character variants, VeriSign has >consulted and will continue to work with all interested stakeholders. We co-created Eurolinc with Louis Pouzin and some others. We are members of the ccTLD WG-IDN. Never been consulted by VRSN. >>4. would there not be a way to register IDN in using their "xn--" >>version? It would simplify international management by resellers? > >Why do you think the SRS currently does not use the xn-- version in >registrations? ??? I just say I want to be able to register the name in entering its ASCII xn-- string. On 10:44 16/02/2005, Thomas Keller said: >By design the IDNA processing happens inside the application and therefore in >my thinking the applications are the right place for any security meassures >as well. Talking about about security measures we have to think about what >exactly we want to prevent from happening. Incorrect. "Application" as in a browser etc. is a wrong idea and will probably never fly. Application can realistically be understood as an application to the path. This is the OPES concept. Has been documented for HTTP and is on the (slow) work for SMTP. However IRI consistency/analysis could be of interest, should the IRI specs. permit it. > > There are other languages that are listed within ISO 639-2 that today > use a combination of Latin and Cyrillic as they were originally Latin > based (Tajik was Arabic prior to being Latin based), migrated to Cyrillic > during the Soviet era and today are migrating back to Latin. It is > common to use Latin and Cyrillic characters in Tajik, from what I > understand not being a native speaker. Granted there are not a lot of > registrations in com net that are Tajik, but this is just the point of an IDN. This is the basic problem of the hybrid two keyboards IDN.ASCII domain names. The character set should be indicated by the TLD own character set and registered table. The resulting security violations come from ICANN. The mixed Tajik table is legitimate for Tajik people, not for others. Let understand that naming is going to be as spam: a need for technical and legal cooperation to protect users. On 07:59 16/02/2005, Martin v. Lwis said: >Michel Suignard wrote: >>To answer another message in this thread, there is no definitive >>answer about which Unicode characters are allowed for a given >>languages. > >There is no definitive answer to that question. There is an attempt to a confused that we are to fight which is Draft 3066bis defining languages tags. >However, I sure >hope there is a definitive answer to the question "which Unicode >characters are allowed for a given language" *when used as >a label in the .COM zone*. For another example, the definitive list >of (additional) characters for a German label in the .DE zone is There is a IANA section for that to gather such Tables. All what this shows is that there is a need for users to discuss technical issues and propose BCPs. This is not an uncommon problem so it might be worth proposing the IADs a WG-USERS? The WG-IDN charter proposed by James Seng initially included a market study. All this would have been part of the IESG approved/IAB reviewed charter of the WG-IDN. But the market would have most probably opposed the IDN.ASCII strategy. jfc From owner-idn@ops.ietf.org Wed Feb 16 07:56:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05031 for ; Wed, 16 Feb 2005 07:56:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1OfD-000LmM-5A for idn-data@psg.com; Wed, 16 Feb 2005 12:52:19 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Of9-000Ljt-JQ for idn@ops.ietf.org; Wed, 16 Feb 2005 12:52:15 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j1GCl1op017461; Wed, 16 Feb 2005 07:47:01 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 07:52:14 -0500 Message-ID: From: "Kane, Pat" To: =?iso-8859-1?Q?=27=22Martin_v=2E_L=F6wis=22=27?= Cc: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 07:52:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We list what we do as opposed what we do not do at http://www.verisign.com/products-services/naming-and-directory-services/= nami ng-services/internationalized-domain-names/idn-standards/idn-character-v= aria nts/page_002087.html. Korean is missing from this list and should be = there. We are currently updating this portion of the site.=20 As far as Tajik, and for that matter most of the languages that have available tags, the matter is the availability of tables to support the tags. I am not an expert on Tajik, but I do know that there may be = some mapping that may be inclined to do for their language between scripts. = I don't know, so I have to wait for the table. It would be the same if = the Germans determined that want to map u with =FC. I can't and won't make = that determination. VeriSign has always wanted to use the tables that were developed by appropriate bodies (either NICs or local language bodies), = but the development process for those tables appears to be stalled at best. = For many languages there are just no tables. CJK tables are clearly available and have been deployed within = VeriSign. As others are developed we are deploying them. We are moving forward this = year with German, Danish, Swedish, Norwegian and Thai as those tables have = been listed with appropriate documentation on IANA. There are ccTLDs that = have IDN programs that have not listed their table or have identified = characters that serve a broader community within their constituency such as Denic opening up 92 additional characters or NASK developing their own Hebrew = and Arabic tables. These don't speak to a language, but the practices of a specific tld. Pat -----Original Message----- From: "Martin v. L=F6wis" [mailto:martin@v.loewis.de]=20 Sent: Tuesday, February 15, 2005 3:29 PM To: Kane, Pat Cc: tedd; idn@ops.ietf.org; ericj@shmoo.com Subject: Re: [idn] homograph attacks Kane, Pat wrote: > VeriSign does prevent domains with the Russian language tag from commingling > A-Z with the Cyrillic characters. It does permit 0-9 and the dash to = be > used. This filter also applies to other Cyrillic based languages = such as > Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. =20 >=20 > There are other languages that are listed within ISO 639-2 that today = use a > combination of Latin and Cyrillic as they were originally Latin based (Tajik > was Arabic prior to being Latin based), migrated to Cyrillic during = the > Soviet era and today are migrating back to Latin. Thanks for the clarification. Is this information publically available somehow? On http://www.verisign.com/static/002533.pdf I can find the language code list (which shows that indeed TGK and RUS might be treated differently); I wonder whether you somehow list the constraints implemented for each tag. How did the applicant know that he would have to use Tajik in order to get a cyrillic letter into an otherwise latin label? As for the Tajik writing system: why is it then necessary to allow mixed scripts? Wouldn't the Tajik users be satisfied if you could either register all-Latin or all-Cyrillic labels (perhaps allowing all-Arabic as well)? Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 08:10:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06445 for ; Wed, 16 Feb 2005 08:10:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1OsR-000PBw-HR for idn-data@psg.com; Wed, 16 Feb 2005 13:05:59 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1OsO-000PBU-8j for idn@ops.ietf.org; Wed, 16 Feb 2005 13:05:56 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j1GD0fop018081; Wed, 16 Feb 2005 08:00:41 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 08:05:54 -0500 Message-ID: From: "Kane, Pat" To: "'JFC (Jefsey) Morfin'" , =?iso-8859-1?Q?_=22Mar?= =?iso-8859-1?Q?tin_v=2E_L=F6wis=22_?= , tedd Cc: idn@ops.ietf.org, ericj@shmoo.com Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 08:05:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jefsey, 1. The language tags that we permit are a subset of the languages = within ISO 639-2. The list of these can be found at http://www.verisign.com/static/002533.pdf. The IANA server is a = listing of language tables to be used with a language tag. Commonality amongst = TLDs in general would be good. That is why VeriSign uses tables such as those = from JET and others. 2. I am interested in the French and Ukrainian sets as well as all of = the others that we permit that currently do not have language tables. I = have not seen them so VeriSign does not have a table for either of those = valid language tags. We are deploying this year those that have been posted = on IANA and are appropriate sources. 3. We follow tables as published. We do not develop these tables on = our own as there are more appropriate sources. We did recognize that with Cyrillic based languages there was a possibility of inappropriate commingling of characters so we excluded all Latin and ASCII characters = with the exception of 0-9 and the dash. 4. I am not sure of your exact question here, but in the registration process each registrar actually encodes the characters and passes to VeriSign the encoded string. Pat -----Original Message----- From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com]=20 Sent: Tuesday, February 15, 2005 7:44 PM To: Kane, Pat; "Martin v. L=F6wis" ; tedd Cc: idn@ops.ietf.org; ericj@shmoo.com Subject: RE: [idn] homograph attacks Dear Pat, I have several questions here. 1. where do you maintain an ASCII list of your language tags? Should it = not=20 be supported on the IANA server and common to all the gTLDs? 2. is there a list of the permitted UNICODEs codes per languages? For=20 example I am interested in the French and Ukrainian sets. 3. did you decide them by yourself, or did you gather a group of = lingual=20 authorities to assist you. This would be very interesting. 4. would there not be a way to register IDN in using their "xn--" = version?=20 It would simplify international management by resellers? Thank you for your assistance. At 20:30 15/02/2005, Kane, Pat wrote: >VeriSign does prevent domains with the Russian language tag from commingling >A-Z with the Cyrillic characters. It does permit 0-9 and the dash to = be >used. This filter also applies to other Cyrillic based languages such = as >Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. > >There are other languages that are listed within ISO 639-2 that today = use a >combination of Latin and Cyrillic as they were originally Latin based (Tajik >was Arabic prior to being Latin based), migrated to Cyrillic during = the >Soviet era and today are migrating back to Latin. It is common to use Latin >and Cyrillic characters in Tajik, from what I understand not being a = native >speaker. Granted there are not a lot of registrations in com net that = are >Tajik, but this is just the point of an IDN. > >Pat Kane > > >-----Original Message----- >From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf = Of >"Martin v. L=F6wis" >Sent: Tuesday, February 15, 2005 2:02 PM >To: tedd >Cc: idn@ops.ietf.org; ericj@shmoo.com >Subject: Re: [idn] homograph attacks > >tedd wrote: > > You all knew this was going to happen. > > > > http://www.p&1072;ypal.com > >Indeed. However, I am somewhat disheartened that this could >happen. IMO, Verisign should have never have registered that >domain - the registrar should have provided a language for >the label, that language should have been "Russian" (or >else &1072; should not have been allowed), and this combination >of Cyrillic and Latin letters should not be allowed for the >Russian language. > >Regards, >Martin From owner-idn@ops.ietf.org Wed Feb 16 08:26:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07746 for ; Wed, 16 Feb 2005 08:26:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1P8T-0002Fp-58 for idn-data@psg.com; Wed, 16 Feb 2005 13:22:33 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1P8P-0002FT-8P for idn@ops.ietf.org; Wed, 16 Feb 2005 13:22:29 +0000 Received: (qmail 29358 invoked by uid 0); 16 Feb 2005 21:25:25 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.386975 secs); 16 Feb 2005 13:25:25 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.386975 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 16 Feb 2005 21:25:22 +0800 Message-ID: <421348F8.9060406@dready.org> Date: Wed, 16 Feb 2005 21:22:00 +0800 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= CC: Michel Suignard , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> In-Reply-To: <4212EF44.4040208@v.loewis.de> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin v. Lwis wrote: > > which is a subset of the .DE list. I'm (now) certain that Verisign > has a definitive list of characters for a German label in the > .COM zone (and I expect this is the same list that DENIC uses, > as that is the superset of the Austrian and Swiss sets). > Pat can correct me if I'm wrong, but my understanding is that VGRS does NOT have a table associated with the German language. So, if you went ahead and register an IDN, and selected the German language, you can pretty much register any label that is permitted by IDNA, including characters that aren't remotely related to German. Regsards, wil. From owner-idn@ops.ietf.org Wed Feb 16 08:36:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08487 for ; Wed, 16 Feb 2005 08:36:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1PGa-000408-ME for idn-data@psg.com; Wed, 16 Feb 2005 13:30:56 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1PGX-0003zu-Q0 for idn@ops.ietf.org; Wed, 16 Feb 2005 13:30:53 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j1GDPaop019263; Wed, 16 Feb 2005 08:25:36 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 08:30:49 -0500 Message-ID: From: "Kane, Pat" To: "'William Tan'" , =?iso-8859-1?Q?=22Martin_v=2E_L=F6w?= =?iso-8859-1?Q?is=22?= Cc: Michel Suignard , idn@ops.ietf.org, ericj@shmoo.com, tedd Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 08:30:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Wil is correct. We are deploying the German table this year. Pat -----Original Message----- From: William Tan [mailto:wil@dready.org]=20 Sent: Wednesday, February 16, 2005 8:22 AM To: "Martin v. L=F6wis" Cc: Michel Suignard; Kane, Pat; idn@ops.ietf.org; ericj@shmoo.com; tedd Subject: Re: [idn] homograph attacks Martin v. L=F6wis wrote: > > which is a subset of the .DE list. I'm (now) certain that Verisign > has a definitive list of characters for a German label in the > .COM zone (and I expect this is the same list that DENIC uses, > as that is the superset of the Austrian and Swiss sets). > Pat can correct me if I'm wrong, but my understanding is that VGRS does = NOT have a table associated with the German language. So, if you went=20 ahead and register an IDN, and selected the German language, you can=20 pretty much register any label that is permitted by IDNA, including=20 characters that aren't remotely related to German. Regsards, wil. From owner-idn@ops.ietf.org Wed Feb 16 08:53:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09902 for ; Wed, 16 Feb 2005 08:53:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1PYe-0008QG-Ix for idn-data@psg.com; Wed, 16 Feb 2005 13:49:36 +0000 Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1PYc-0008Pu-1F for idn@ops.ietf.org; Wed, 16 Feb 2005 13:49:34 +0000 Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1GDnSu1081154 for ; Wed, 16 Feb 2005 08:49:29 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <66F7005C4F04C14B89DE467C76D2445053D5E4@MOU1WNEXMB01.vcorp.ad.vrsn.com> References: <66F7005C4F04C14B89DE467C76D2445053D5E4@MOU1WNEXMB01.vcorp.ad.vrsn.com> Date: Wed, 16 Feb 2005 08:49:27 -0500 To: idn@ops.ietf.org From: tedd Subject: RE: [idn] homograph attacks Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk >All: > >And an interesting follow-up by Paul Hoffman: > >http://LookIt.proper.com/archives/000302.html#000302 > >Gary. But of course, Paul has solved the problem again. I know this to be true, because I recognize his manner of presenting the solution. First, Paul to divides people into two groups; 1) those who know everything about the net, which includes Paul and other "God's of the Internet" -- those who invented the Internet (I guess this includes Al Gore); 2) everyone else in the world who doesn't know squat, of which I'm a member. Of course, those like me are asked for our opinion, but when we give it we are often met with "Well... it's clear that you didn't read such and such draft" and then are presented with tens of pages (if not hundreds) of pages of Geek speak to comprehend. If that doesn't shut us up, then he is most happy to tell us to "Look up the word 'hubris' in the dictionary" because we are questioning his view of the world -- but I digress. Second, after his introduction, which leaves no doubt that you either are smart and agree with him, or... well, you get the picture. But, sometimes, that just doesn't solve the problem and I often find myself back to "If it looks like a duck, and it sounds like a duck..." Now I realize that after reading Paul's solution, that he really doesn't want to be "pulled back in" to the fray. After all, he has already provided us with the tablets and now wants to lead his people around in the desert away from all of this, but, unfortunately, we keep having problems with the commandments he left -- like what's this "Thou shall not mix scripts without doing it right" thing? I think we can all agree with Paul that the "Quick" answers don't work. But, you know, I don't understand Paul's "better solutions" either. Let's take a look. The first one has a pretty image of a "hover pop-up" that shows a domain name where ASCII characters are in Cyan and Cyrillic characters are in Yellow -- that looks pretty smart. Let's see, if I understand the solution, we use Cyan for ASCII and Yellow for Cyrillic, and... -- hey just how many scripts are there and how many colors are available? You know, a single domain name might take on the look of one of my granddaughter's fruit-loop bracelets. So, I'm not sure how that would work. Of course, one might just use white for "normal" scripts and yellow for everything else. That might work. That way everyone in the world could have their own script appear "normal" whereas mixed scripts would be... ah mixed, right? Of course, those countries who use mixed scripts, would always have colored domains -- but there can't be too many of those, right? Of course, the colored domain name solution doesn't address the section 508 issue with regard to the disabled, but then again, who thinks of the needs of those people, right? Oh, and don't forget the blinking domain thing that Paul mentioned either -- am sure that would go over well in the disabled market, not to mention that every web page designer I know thinks that a blinking anything is a real "no-no". But then again, Paul is not a designer. Oh, and don't forget the lawyers of the person who owns a mixed script (liek caf But Paul is also not super at understanding the problem his solution creates. At present we have more than a couple of browsers and OS's to contend with. My "Browser Cam" count shows 24 different browser/os combinations (if you don't count Flash). So Paul's solution would require the creation of 24 different "plug-in's" . I don't know who's going to do that, but I doubt that it's going to get done. Of course, there's also the problem in distribution of those plug-in's to zillions of computers -- (zillions is OK, because Paul used that number). I don't understand how that is going to work either. -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Wed Feb 16 08:59:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10477 for ; Wed, 16 Feb 2005 08:59:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Pei-000AWk-Jh for idn-data@psg.com; Wed, 16 Feb 2005 13:55:52 +0000 Received: from [216.168.239.71] (helo=falcon.verisign.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Pef-000AWE-JV for idn@ops.ietf.org; Wed, 16 Feb 2005 13:55:49 +0000 Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id j1GDoRop020542; Wed, 16 Feb 2005 08:50:27 -0500 (EST) Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 08:55:40 -0500 Message-ID: From: "Kane, Pat" To: "'Roozbeh Pournader'" Cc: =?iso-8859-1?Q?=22Martin_v=2E=22_L=F6wis=22?= , tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 08:55:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Roozbeh, Thank you for that clarification. I still would not want to deploy an assumptive table. Do you know of anyone working on a table for Tajik? Also, have you had any involvement in an Arabic table? Pat -----Original Message----- From: Roozbeh Pournader [mailto:roozbeh@farsiweb.info]=20 Sent: Wednesday, February 16, 2005 8:48 AM To: Kane, Pat Cc: "Martin v." L=F6wis"; tedd; idn@ops.ietf.org; ericj@shmoo.com Subject: RE: [idn] homograph attacks On Tue, 2005-02-15 at 14:30 -0500, Kane, Pat wrote: > There are other languages that are listed within ISO 639-2 that today = use a > combination of Latin and Cyrillic as they were originally Latin based (Tajik > was Arabic prior to being Latin based), migrated to Cyrillic during = the > Soviet era and today are migrating back to Latin. It is common to = use Latin > and Cyrillic characters in Tajik, from what I understand not being a native > speaker. Granted there are not a lot of registrations in com net = that are > Tajik, but this is just the point of an IDN. Tajik doesn't mix Latin and Cyrillic, I can definitely tell you that. But it has three different and separate orthographies, one using Latin, one using Cyrillic, and one using Arabic. I can tell you that because I read Tajik. I can also be considered a native speaker somehow, since I speak Persian, that Tajik is sometimes considered a dialect of. roozbeh From owner-idn@ops.ietf.org Wed Feb 16 09:13:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12098 for ; Wed, 16 Feb 2005 09:13:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Psh-000ERZ-0x for idn-data@psg.com; Wed, 16 Feb 2005 14:10:19 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Psd-000ERC-Df for idn@ops.ietf.org; Wed, 16 Feb 2005 14:10:15 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1PsY-0003WA-T9; Wed, 16 Feb 2005 06:10:14 -0800 Message-Id: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Feb 2005 15:09:43 +0100 To: "Kane, Pat" From: "JFC (Jefsey) Morfin" Subject: RE: [idn] homograph attacks Cc: idn@ops.ietf.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Dear Pat, Thank you for your response. Let assume this list is the missing International coordination list. As you know we are in a gray situation regarding the IANA and language tags. There is the RFC 3066 which accepts ISO 639 as a reference and which permits the language "specialists" (ISO and W3C) of the http://www.alvestrand.no/mailman/listinfo/ietf-languages mailing list to discuss missing languages. This is clean. But then we have a confusion. 1. When you register a IANA tag, you are to register it by language, script and ccTLD. This is clear. 2. W3C discovered that a language tag by ISO 639 was not enough to describe an XML document. So they introduced two new ideas the IESG could buy: '(1) RFC 3066 language tags could become ISO 639+ISO 15924 script+ISO 3166 country code (2) that _all_ the langtags should be resgitered, not only the additions. So, each language is known as a single version - what culture people shout at! When explained the conflict with IDN they claimed they do not care. IMHO we have a layer violation because I see three layers to support the users demand. 1. internationlisation: this is the IDN and the ccTLD (quoted in the language/script/ccTLD sequence is the authority). So the default should be the IDN Table assuming that ccTLD Managers are the trustees of their communities and know better about their people than anyone else. 2. multilingualization: thus is an added layer to take care of the language, the semantic, the dictionnary, the grammar, the culture, etc. You can have many visions. I said the ccTLD vision should be the default and described in IDN Tables, then univesities, Govs, artists, writers, etc. can have theirs. So the tag should include language.script/ccTLD/authority. 3. vernacularization: the way the user is to use the language through applications. This means that an additional element will be the style. This makes a lang5tag including language/script/ccTLD/authority/style. There the application may use the style to warn about a possible spoofing or not. In addition to the lang5tag proposition - I propose we agree upon an XML,ASN.1 format to decribe a TLD better than the current Whois, where the TLD Manager would describe far more elements including its Tables in a computer readable form, so we could easily share the definition. For example this could include a list of foul names to bar in the language, of famous contious marks, etc. We (TLD Registries) could decide to maintain this file available at some published addresses for direct mutual exchange. At 14:05 16/02/2005, Kane, Pat wrote: >1. The language tags that we permit are a subset of the languages within >ISO 639-2. The list of these can be found at >http://www.verisign.com/static/002533.pdf. The IANA server is a listing of >language tables to be used with a language tag. Commonality amongst TLDs in >general would be good. That is why VeriSign uses tables such as those from >JET and others. I would appreciate if we could have it in ASCII in a stable format, so we could work on automating reading of these data. >2. I am interested in the French and Ukrainian sets as well as all of the >others that we permit that currently do not have language tables. I have >not seen them so VeriSign does not have a table for either of those valid >language tags. We are deploying this year those that have been posted on >IANA and are appropriate sources. I have no problem to Publish mine in French. May be could we discuss that together? >3. We follow tables as published. We do not develop these tables on our >own as there are more appropriate sources. We did recognize that with >Cyrillic based languages there was a possibility of inappropriate >commingling of characters so we excluded all Latin and ASCII characters with >the exception of 0-9 and the dash. When you say "published" you mean IANA? I think we need something more reactive and more multingual. Is Nico Popp still invoved in IDNs (he is in the MINC Board for you?) >4. I am not sure of your exact question here, but in the registration >process each registrar actually encodes the characters and passes to >VeriSign the encoded string. As a "reseller" myself, I would like to be able to enter my encoded string, for it to be verified and registered. I have ASCII tools. What is true for the DNS is also for me. All the best. jfc > Pat > >-----Original Message----- >From: JFC (Jefsey) Morfin [mailto:jefsey@jefsey.com] >Sent: Tuesday, February 15, 2005 7:44 PM >To: Kane, Pat; "Martin v. Lwis" ; tedd >Cc: idn@ops.ietf.org; ericj@shmoo.com >Subject: RE: [idn] homograph attacks > >Dear Pat, >I have several questions here. > >1. where do you maintain an ASCII list of your language tags? Should it not >be supported on the IANA server and common to all the gTLDs? >2. is there a list of the permitted UNICODEs codes per languages? For >example I am interested in the French and Ukrainian sets. >3. did you decide them by yourself, or did you gather a group of lingual >authorities to assist you. This would be very interesting. >4. would there not be a way to register IDN in using their "xn--" version? >It would simplify international management by resellers? > >Thank you for your assistance. > > >At 20:30 15/02/2005, Kane, Pat wrote: > >VeriSign does prevent domains with the Russian language tag from >commingling > >A-Z with the Cyrillic characters. It does permit 0-9 and the dash to be > >used. This filter also applies to other Cyrillic based languages such as > >Belarusian, Ukrainian, Serbian, Macedonian and Bulgarian. > > > >There are other languages that are listed within ISO 639-2 that today use a > >combination of Latin and Cyrillic as they were originally Latin based >(Tajik > >was Arabic prior to being Latin based), migrated to Cyrillic during the > >Soviet era and today are migrating back to Latin. It is common to use >Latin > >and Cyrillic characters in Tajik, from what I understand not being a native > >speaker. Granted there are not a lot of registrations in com net that are > >Tajik, but this is just the point of an IDN. > > > >Pat Kane > > > > > >-----Original Message----- > >From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf Of > >"Martin v. Lwis" > >Sent: Tuesday, February 15, 2005 2:02 PM > >To: tedd > >Cc: idn@ops.ietf.org; ericj@shmoo.com > >Subject: Re: [idn] homograph attacks > > > >tedd wrote: > > > You all knew this was going to happen. > > > > > > http://www.p&1072;ypal.com > > > >Indeed. However, I am somewhat disheartened that this could > >happen. IMO, Verisign should have never have registered that > >domain - the registrar should have provided a language for > >the label, that language should have been "Russian" (or > >else &1072; should not have been allowed), and this combination > >of Cyrillic and Latin letters should not be allowed for the > >Russian language. > > > >Regards, > >Martin From owner-idn@ops.ietf.org Wed Feb 16 09:17:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12347 for ; Wed, 16 Feb 2005 09:17:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1PwV-000FLO-KR for idn-data@psg.com; Wed, 16 Feb 2005 14:14:15 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1PwL-000FJu-Bd for idn@ops.ietf.org; Wed, 16 Feb 2005 14:14:05 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1Pw9-0004Xk-F0; Wed, 16 Feb 2005 06:13:53 -0800 Message-Id: <6.1.2.0.2.20050216151114.0cb22890@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 16 Feb 2005 15:13:44 +0100 To: "Kane, Pat" , "'William Tan'" , "Martin v. Lw is" From: "JFC (Jefsey) Morfin" Subject: RE: [idn] homograph attacks Cc: Michel Suignard , idn@ops.ietf.org, ericj@shmoo.com, tedd In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 14:30 16/02/2005, Kane, Pat wrote: >Wil is correct. We are deploying the German table this year. If I am reading you correctly, you mean that you will deploy the German table this year because the DENIC or ASNIC will enter a table. If they differ which table do you pick? The addition or what? In your contract with ICANN are you not bound by some obligations irt the tables? Thank you. jfc >Pat > >-----Original Message----- >From: William Tan [mailto:wil@dready.org] >Sent: Wednesday, February 16, 2005 8:22 AM >To: "Martin v. Lwis" >Cc: Michel Suignard; Kane, Pat; idn@ops.ietf.org; ericj@shmoo.com; tedd >Subject: Re: [idn] homograph attacks > > > >Martin v. Lwis wrote: > > > > > which is a subset of the .DE list. I'm (now) certain that Verisign > > has a definitive list of characters for a German label in the > > .COM zone (and I expect this is the same list that DENIC uses, > > as that is the superset of the Austrian and Swiss sets). > > >Pat can correct me if I'm wrong, but my understanding is that VGRS does >NOT have a table associated with the German language. So, if you went >ahead and register an IDN, and selected the German language, you can >pretty much register any label that is permitted by IDNA, including >characters that aren't remotely related to German. > >Regsards, >wil. From owner-idn@ops.ietf.org Wed Feb 16 12:25:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28788 for ; Wed, 16 Feb 2005 12:25:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Soa-0007NV-5D for idn-data@psg.com; Wed, 16 Feb 2005 17:18:16 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1SoN-0007Lc-2O for idn@ops.ietf.org; Wed, 16 Feb 2005 17:18:04 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D1SoM-000Kil-Bx; Wed, 16 Feb 2005 12:18:02 -0500 Date: Wed, 16 Feb 2005 12:17:58 -0500 From: John C Klensin To: idn@ops.ietf.org cc: dam@icann.org Subject: RE: [idn] homograph attacks Message-ID: In-Reply-To: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Responding to several messages together, rather than sending a series of fragmented messages... Folks, I'm pleased to see so much interest on this list, but note that the issue has already been extensively discussed on the IETF list and elsewhere. I'm copying Tina Dam, who has the IDN lead for ICANN, on this message; if there is further traffic, you might want to include her as well (or, for the reasons discussed below, she might want to move part of the conversation to an appropriate ICANN list). --On Wednesday, 16 February, 2005 15:09 +0100 "JFC (Jefsey) Morfin" wrote: >... > Thank you for your response. Let assume this list is the > missing International coordination list. While I think that an "International coordination list" would be helpful, my assumption is that ICANN's idn-discuss list (see http://www.icann.org/topics/idn.html for subscription information and some other information that might be useful) is intended to serve that purpose. It is pretty clearly not this, or any other, IETF list: the IETF made a series of fairly explicit decisions to not get into the business of deciding what things could or could not be registered within the very broad coding mechanisms specified as part of IDNA. > As you know we are > in a gray situation regarding the IANA and language tags. > There is the RFC 3066 which accepts ISO 639 as a reference and > which permits the language "specialists" (ISO and W3C) of the > http://www.alvestrand.no/mailman/listinfo/ietf-languages > mailing list to discuss missing languages. This is clean. >=20 > But then we have a confusion. >=20 > 1. When you register a IANA tag, you are to register it by > language, script and ccTLD. This is clear. Actually, that is not the ICANN/IANA requirement, nor is it clear where their requirement applies (e.g., such registrations are optional). Their requirement is unclear and, IMO, needs updating. I hope that they will get to that updating process RSN. On the other hand, I have had that hope for well over a year. Progress is unlikely to be made on those subjects by further discussion here. >... > 1. internationlisation: this is the IDN and the ccTLD (quoted > in the language/script/ccTLD sequence is the authority). So >... Jefsey, as you know, we do not agree on your analysis of language and cultural issues and how they relate to the Internet's protocol suites or the DNS and agree even less with your model of how the DNS works and its role in the world. We also disagree on what appears to be your desire --exhibited by citing OPES as an Internet norm-- to move all sorts of issues from the edges of the network to the center. For me, one of the major strengths of the Internet, and a key reason it has been deployed worldwide and achieved as much penetration as it has, is that it strongly resemblances an "edge"-based network and has avoided the many traps associated with a design in which significant functionality, especially significant applications functionality, is located in between peers or clients and servers I won't reprise the rest of my side of that disagreement here. In a separate note, at Tuesday, February 15, 2005 7:44 PM, you wrote, in part... >> Should it not be supported on the IANA server and common to >> all the gTLDs? I agree with Pat that commonality --among gTLDs and even more generally -- would be a good thing, especially for the would-be registrant who wishes to register the same name in multiple domains. But ICANN has so far chosen to not to try to impose it, and I hope they don't. We have so far discovered at least two things that may argue for caution in this area: (i) As I trust everyone on this list knows, phishing is only part of a far more general set of issues that can cause end-user confusion (whether through accident or malice). For any given domain, there is a tradeoff between maximum safety (which might require permitting only a small number of characters and imposing significant restrictions on how they are used) and maximum registration flexibility (which might argue for much more flexible rules). In my personal opinion, at least, it is far better for the Internet to let domains compete on how protective or flexible they want to be, assuming the advantages and risks of whatever solution point they pick, than to try to impose some Procrustian solution. (ii) An interesting distinction has been identified between the needs of a domain that must serve the requirements of a particular country and a domain that supports the language commonly associated with that country. For the first case, of which .DE is the best-worked-out example, there is a legitimate requirement for registration of common names, company names, street names, etc., in Germany. Given history, that list will include strings and characters that don't exist in the German language. It may include strings the contain combinations of characters that do no appear together in any contemporary language that uses Roman-based characters. By contrast, if a gTLD creates a language table defined around the German language, many of the characters needed by .DE are simply invalid. That contrast, which Martin has identified in the form of the difference between the "German" tables used in the TLDs for Austria and Switzerland relative to those used in Germany) may require taking a different look at the rules and guidelines (and table registration models) than we have heretofore taken: either for rather different guidelines for ccTLDs than for gTLDs, or for rethinking the registration model, or both. The issue that Pat identifies with Tajik is another piece of the same puzzle: many of us may believe that there is no possible reason to mix the three scripts in which that language can be written in a single label, and I certainly trust Roozbeh's knowledge and experience in that area. Certainly, it would make things safer to prohibit any mixing (note that IDNA's BIDI restrictions essentially prohibit mixing an Arabic-derived script with anything other than itself, another Arabic-derived script, or Hebrew). However, we have a long history of DNS labels that could not possibly be words in any language. Whether or not to permit mixed-script labels is presumably an issue that the registry for .TJ will need to sort out (I have been told, for example, that mixed Cyrillic and Latin-character labels are likely to be a requirement in Serbia and Montenegro, although this illustration might give them pause). And the best answer for them might or might not be the best answer for a gTLD. In addition, as Hotta-san's very helpful note points out, one could considerably reduce the scope of the identified confusion/phishing problems by aggressively applying a variant model across scripts, restricting the registration of homographs to the same registrant. I personally suspect that will not prove practical, from a policy standpoint, in the collection of alphabetic scripts that share Old Semitic origins, but that is, IMO, just another argument for giving different registries the flexibility to develop their own policies and take responsibility for the consequences of those policies. Again, these issues need to be worked out in an ICANN forum; the IETF has thrown the problem over the wall and shows no signs of wanting it back. --On Wednesday, 16 February, 2005 08:07 +0100 "\"Martin v. L=F6wis\"" wrote, responding to Soobok Lee: >> All Cyrillic label "HP" (.com) can be registered even in >> Russian language pack. >>=20 >> Cyrillic "HP".COM in its uppercase form looks the same as >> all ASCII "HP.COM". >>=20 >> Any Registration Process should filter out these "HP" like >> combinations.. But the only way to do that would require that a domain that permits Cyrillic characters must ban ASCII characters and vice versa. I would predict that will just never happen, if only because every domain that exists today has a long of all-ASCII labels in it. It is not a very good example (see below), but I note that this particular example is only of the reasons why "identify a mixed-script label in the application" may be a useful tool, but is not a solution -- this is not a mixed-script label. > I think this is unreasonable. The lower-case forms ("??" vs > "hp") > look quite differently, and browsers typically display domain > names in all-lower in the address bar. Regardless of what browsers do (there is a case to be made that, for traditional labels, if they get an all-upper-case label back from a DNS query and display it in lower case, they are violating the intent of the spec), note that, for IDNs, mapping through IDNA and back (ToUnicode followed by ToASCII) will always result in lower case and application of several other mappings. >... > just because they are homograph with a latin combination. = Then, > the same would apply to Greek vs. Cyrillic. Yes, banning a mixture of Latin characters with those of any other script won't work either because one can get homographs among other pairs of scripts. However, it might be realistic to ban the combination of Greek and Cyrillic in the same zone, while it would not be practical to ban the presence of Roman-based characters with either. Mostly, again, this points out the importance of zone-specific policies that are well-tailored to the needs of that particular zone. To repeat what I have said on the IETF list and elsewhere, nothing is going to make these issues 100% foolproof or easy. A number of tools may help. Certainly carefully-designed restrictions on what can be registered in a particular zone and what characters can be used together in the same label will help. Intelligent and well-thought-out use of variant models may help a good deal. If labels that can be identified as having no use other than to confuse or defraud can be rejected at registration time, that would eliminate a lot of problems down the line -- that may be practical in some cases but not in others. I'm a bit skeptical about identification of mixed-script labels in applications, not because I think it wouldn't be useful, but because carrying those tables around and keeping them up to date could be a bar to implementation and performance, but there may be ways to make it practical. I think users --both those whose preferred scripts are written in Roman-based characters and those whose preferred scripts are not-- are going to need to become educated about some of these issues, not just to protect themselves but to understand when IDNs or IRIs can be exchanged with others with high odds that they will be usable and unambiguous. I think there is a lot of potential in distinctions like the Firefox one between "copy link location" / "paste link" and "copy"/"paste" and that we may discover that the former pair should convert to punycode and URIs and back to UTF-8 (or whatever) and IRIs to prevent inter-application and inter-system cut and paste problems. And I hope we can all figure out a way to work together to make this work. It is important, "don't use IDNs" isn't an answer now and never has been, and the alternatives are just a choice among ways to fragment the Internet. john From owner-idn@ops.ietf.org Wed Feb 16 14:41:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09284 for ; Wed, 16 Feb 2005 14:41:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Uyk-000Gy4-0r for idn-data@psg.com; Wed, 16 Feb 2005 19:36:54 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Uyi-000Gxn-Cj for idn@ops.ietf.org; Wed, 16 Feb 2005 19:36:52 +0000 Received: (qmail 19150 invoked from network); 16 Feb 2005 19:36:48 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 19:36:48 -0000 Message-ID: <4213A0CE.9050309@v.loewis.de> Date: Wed, 16 Feb 2005 20:36:46 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Keller CC: Michel Suignard , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd Subject: Re: [idn] homograph attacks References: <20050216094424.GH25086@schlund.de> In-Reply-To: <20050216094424.GH25086@schlund.de> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Keller wrote: > I'm by no means a linguist but I would assume that there are a plethora > of good and usefull mixtures of scripts that exist in daily life. Passing > this problem (of which all of us have been aware of for years now) back > to the policy arena won't help anyone since I doubt that there can be any > kind working group (now or in the future) that can come up with a good > rational for all scripts and languages without restricting "good" and usefull > mixtures. Right. So what the working groups do is to come up with a good rationale for all scripts and languages that *do* restrict "good" and useful mixtures. I find no problems in that restrictions: it is better to be restrictive now and permissive later than the other way 'round. > By design the IDNA processing happens inside the application and therefore in > my thinking the applications are the right place for any security meassures > as well. Not only. Right from the beginning, the idea was to enforce policy in the registry. > Talking about about security measures we have to think about what > exactly we want to prevent from happening. In the specific case, I think paypal.com with a Cyrillic "a" should have been prevented from becoming registered. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 14:55:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11675 for ; Wed, 16 Feb 2005 14:55:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1VDP-000KdF-W1 for idn-data@psg.com; Wed, 16 Feb 2005 19:52:03 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1VDN-000Kca-ME for idn@ops.ietf.org; Wed, 16 Feb 2005 19:52:02 +0000 Received: (qmail 21509 invoked from network); 16 Feb 2005 19:52:01 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 19:52:01 -0000 Message-ID: <4213A45F.6020203@v.loewis.de> Date: Wed, 16 Feb 2005 20:51:59 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> <6.1.2.0.2.20050216110348.04110630@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050216110348.04110630@mail.jefsey.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: >> http://www.verisign.com/static/002533.pdf > > > PDF is hardly an ASCII list. Well, it contains only characters from the ASCII charset. >> I personally don't see why it should be on a IANA server. >> As for "should it be common to all the gTLDs", I honestly believe >> the answer should be "no". > > > These opinions of yours are opposed by gTLD contracts with ICANN. Does that apply to the "old" gTLDs as well? > There is a IANA registration for IDN Table, even very poor. > The proposed "RFC 3066bis" Draft lead to a debate where the authors > who are discussing the language tags to be registered by IANA > described as outrageous the idea that they should consider IDNs > and be consistent with them. Do you support that? I don't think consistency across gTLDs is necessary (nor do I think consistency across ccTLDs of countries using the same "scripts" is necessary). What does matter is that the policies are published and open for discussion. It is ok that the policies evolve over time, in which case "legacy" registration need to be considered. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 15:08:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14859 for ; Wed, 16 Feb 2005 15:08:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1VPO-000On6-MB for idn-data@psg.com; Wed, 16 Feb 2005 20:04:26 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1VPM-000OmS-GD for idn@ops.ietf.org; Wed, 16 Feb 2005 20:04:24 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D1VPE-000Lxq-OU; Wed, 16 Feb 2005 15:04:16 -0500 Date: Wed, 16 Feb 2005 15:04:16 -0500 From: John C Klensin To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , "JFC (Jefsey) Morfin" cc: idn@ops.ietf.org, dam@icann.org Subject: Re: [idn] homograph attacks Message-ID: <81CA0375C93968D306614FA0@scan.jck.com> In-Reply-To: <4213A45F.6020203@v.loewis.de> References: <4212EF44.4040208@v.loewis.de> <6.1.2.0.2.20050216110348.04110630@mail.jefsey.com> <4213A45F.6020203@v.loewis.de> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable --On Wednesday, 16 February, 2005 20:51 +0100 "\"Martin v. L=F6wis\"" wrote: > JFC (Jefsey) Morfin wrote: >... >>> I personally don't see why it should be on a IANA server. >>> As for "should it be common to all the gTLDs", I honestly >>> believe the answer should be "no". >>=20 >> These opinions of yours are opposed by gTLD contracts with >> ICANN. >=20 > Does that apply to the "old" gTLDs as well? Actually, this is just confusion at best. The current ICANN guidelines (and gTLD contracts to the extent they are relevant) do not require at all gTLDs use the same tables for a given language, nor that they register the tables they are using. The latter is merely a strong recommendation. >> There is a IANA registration for IDN Table, even very poor. >> The proposed "RFC 3066bis" Draft lead to a debate where the >> authors who are discussing the language tags to be registered >> by IANA described as outrageous the idea that they should >> consider IDNs and be consistent with them. Do you support >> that? >=20 > I don't think consistency across gTLDs is necessary (nor do I > think consistency across ccTLDs of countries using the same > "scripts" is necessary). What does matter is that the policies > are published and open for discussion. It is ok that the > policies > evolve over time, in which case "legacy" registration need to > be considered. That view is consistent with current ICANN policy although, IMO, the current requirements for publication and openness are probably not yet strong enough. It is not clear to me whether or not ICANN would meet resistance if they tried to strengthen those requirements. regards, john From owner-idn@ops.ietf.org Wed Feb 16 16:27:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28048 for ; Wed, 16 Feb 2005 16:27:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1WbR-0000Kg-P8 for idn-data@psg.com; Wed, 16 Feb 2005 21:20:57 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1WbO-0000Ho-Co for idn@ops.ietf.org; Wed, 16 Feb 2005 21:20:54 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1GLKSHb170880; Wed, 16 Feb 2005 16:20:28 -0500 Message-ID: <4213B916.8030108@vanderpoel.org> Date: Wed, 16 Feb 2005 13:20:22 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Tan CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , Michel Suignard , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> <421348F8.9060406@dready.org> In-Reply-To: <421348F8.9060406@dready.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello all, It seems to me that a registry should not allow the registration of an IDN domain name under a particular language if that registry does not have a table for that language. When a registry *does* have a table for a particular language, the IDN domain name is restricted to the characters that appear in that table. So, when there is *no* table for a language, then *no* characters should be allowed. In other words, no IDN domain names (starting with xn--) should be allowed. Also, it seems to me that registries like COM could "stop the bleeding" (for now) by immediately deploying systems that enforce a policy where registrations for languages for which they do not have tables are rejected. After that, they could continue to gather or compile tables. Regards, Erik van der Poel William Tan wrote: > > Pat can correct me if I'm wrong, but my understanding is that VGRS does > NOT have a table associated with the German language. So, if you went > ahead and register an IDN, and selected the German language, you can > pretty much register any label that is permitted by IDNA, including > characters that aren't remotely related to German. > > Regsards, > wil. From owner-idn@ops.ietf.org Wed Feb 16 16:37:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28996 for ; Wed, 16 Feb 2005 16:37:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1WoO-0002xR-Bh for idn-data@psg.com; Wed, 16 Feb 2005 21:34:20 +0000 Received: from [80.67.18.15] (helo=smtprelay03.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1WoE-0002wq-Lp for idn@ops.ietf.org; Wed, 16 Feb 2005 21:34:10 +0000 Received: (qmail 26153 invoked from network); 16 Feb 2005 21:34:09 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 21:34:09 -0000 Message-ID: <4213BC4F.8020505@v.loewis.de> Date: Wed, 16 Feb 2005 22:34:07 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: William Tan , Michel Suignard , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> <421348F8.9060406@dready.org> <4213B916.8030108@vanderpoel.org> In-Reply-To: <4213B916.8030108@vanderpoel.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > It seems to me that a registry should not allow the registration of an > IDN domain name under a particular language if that registry does not > have a table for that language. I strongly agree. It is fine that Verisign was employing a IDN testbed, and people have learned a lot of technology from that. But now, in the operational phase, registrars need to be really careful, and err on the side of restrictiveness as opposed to openess. If people find the rules too restrictive, there is always the possibility to weaken the rules. > After that, they could continue to gather or compile tables. Precisely so. IDN is driven by market needs. So if there is a strong need for registering, say, Tajik labels in .com, Tajik users will work with national bodies to establish a language filter for Tajik that gTLD registrars can use. At the moment, it looks like the missing tables can be used for phishing *only* - something I doubt is in the commercial interest of a gTLD registrar. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 16:44:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29652 for ; Wed, 16 Feb 2005 16:44:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Wu0-0005Af-Tv for idn-data@psg.com; Wed, 16 Feb 2005 21:40:08 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Wtz-0005AK-M7 for idn@ops.ietf.org; Wed, 16 Feb 2005 21:40:08 +0000 Received: (qmail 24028 invoked from network); 16 Feb 2005 21:40:06 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 21:40:06 -0000 Message-ID: <4213BDB5.5070700@v.loewis.de> Date: Wed, 16 Feb 2005 22:40:05 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: "Kane, Pat" , idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > 1. When you register a IANA tag, you are to register it by language, > script and ccTLD. This is clear. I don't see how this is relevant for this discussion. If the .com registrar decides to use a subset of 639 only, I consider this a valid choice. No need to register any language tag with IANA; all tags you ever want to use are already there. > 2. W3C discovered that a language tag by ISO 639 was not enough to > describe an XML document. This is completely unrelated to IDN. > 1. internationlisation: this is the IDN and the ccTLD (quoted in the > language/script/ccTLD sequence is the authority). So the default should > be the IDN Table assuming that ccTLD Managers are the trustees of their > communities and know better about their people than anyone else. Sounds like a reasonable approach; it appears that Verisign is using it. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 16:53:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01021 for ; Wed, 16 Feb 2005 16:53:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1X3j-0007qA-Uy for idn-data@psg.com; Wed, 16 Feb 2005 21:50:11 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1X3g-0007l7-HS for idn@ops.ietf.org; Wed, 16 Feb 2005 21:50:08 +0000 Received: (qmail 7957 invoked from network); 16 Feb 2005 21:50:08 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 21:50:08 -0000 Message-ID: <4213C00E.7060806@v.loewis.de> Date: Wed, 16 Feb 2005 22:50:06 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kane, Pat" CC: tedd , idn@ops.ietf.org, ericj@shmoo.com Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Kane, Pat wrote: > I am not an expert on Tajik, but I do know that there may be some > mapping that may be inclined to do for their language between scripts. I > don't know, so I have to wait for the table. It would be the same if the > Germans determined that want to map u with . As a side note, for German, mapping "" with "ue" would be more meaningful... but the German-speaking ccTLDs have decided not to do that (which IMO is a reasonable decision). I agree that you should not create Tajik tables yourself, but rely on experts to do that. But then, I agree with Erik that you should reject any registration for the Tajik language until you actually have tables. I certainly understand that it is commercially challenging to request that appropriate national bodies come up with tables before even accepting registration. However, given the marketing position of the .com zone, I think users will understand the issues at stake, and somehow find a to make their national bodies move forward. When they have done so (e.g. like in the German case), it is really difficult to understand why you are deferring adoption of the official tables to "later this year". Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 17:23:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04132 for ; Wed, 16 Feb 2005 17:23:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1XVY-000G2D-4j for idn-data@psg.com; Wed, 16 Feb 2005 22:18:56 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1XVU-000G1y-UE for idn@ops.ietf.org; Wed, 16 Feb 2005 22:18:52 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 14:18:54 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 14:18:51 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 14:18:51 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 14:18:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 14:18:51 -0800 Message-ID: Thread-Topic: [idn] homograph attacks thread-index: AcUUbXXvjijNICc5TlWw+/qzDUiAjgABNNCA From: "Michel Suignard" To: "Erik van der Poel" , "William Tan" Cc: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , "Kane, Pat" , , , "tedd" , X-OriginalArrivalTime: 16 Feb 2005 22:18:51.0254 (UTC) FILETIME=[7E4B9960:01C51475] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I think that building language tables for Latin based writing systems is = a nice but mostly futile exercise. Modern language are constantly = borrowing from other languages using the same script. If you think that = English only use a-z, A-Z, you are going to be surprised. Take for = example 'H=E4agen-Dazs", isn't it an English brand? If not what is it? = English is constantly using French and German words, among others, in = everyday life usage. Think of English words such as na=EFve, na=EFvely = and many others. Should non ascii letters in them they be excluded from = 'english' tables? I have seen European standard bodies spending forests of paper to try to = establish these language tables, but there have never been an = authoritative version because simply you can't. =20 It is not a bad idea to have language tables to filter, but you have to = allow exception for the reasons exposed above. Same is true for Cyrillic as well. Furthermore most ccTLD won't follow any registry regulation imposed from = outside. So any such regulation can only be hoped for, not expected in = all cases. I can perfectly see that some gTLD and possibly few ccTLD = will have such rules, but they will have to be fairly accommodating to = accept reality. Michel -----Original Message----- From: Erik van der Poel [mailto:erik@vanderpoel.org]=20 Sent: Wednesday, February 16, 2005 1:20 PM To: William Tan Cc: "Martin v. L=F6wis"; Michel Suignard; Kane, Pat; idn@ops.ietf.org; = ericj@shmoo.com; tedd; dam@icann.org Subject: Re: [idn] homograph attacks Hello all, It seems to me that a registry should not allow the registration of an = IDN domain name under a particular language if that registry does not = have a table for that language. When a registry *does* have a table for a particular language, the IDN = domain name is restricted to the characters that appear in that table. So, when there is *no* table for a language, then *no* characters should = be allowed. In other words, no IDN domain names (starting with xn--) = should be allowed. Also, it seems to me that registries like COM could "stop the bleeding"=20 (for now) by immediately deploying systems that enforce a policy where = registrations for languages for which they do not have tables are = rejected. After that, they could continue to gather or compile tables. Regards, Erik van der Poel William Tan wrote: >=20 > Pat can correct me if I'm wrong, but my understanding is that VGRS=20 > does NOT have a table associated with the German language. So, if you=20 > went ahead and register an IDN, and selected the German language, you=20 > can pretty much register any label that is permitted by IDNA,=20 > including characters that aren't remotely related to German. >=20 > Regsards, > wil. From owner-idn@ops.ietf.org Wed Feb 16 18:32:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11490 for ; Wed, 16 Feb 2005 18:32:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Yai-0009Dq-P5 for idn-data@psg.com; Wed, 16 Feb 2005 23:28:20 +0000 Received: from [80.67.18.13] (helo=smtprelay01.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1Yaf-0009DI-BL for idn@ops.ietf.org; Wed, 16 Feb 2005 23:28:17 +0000 Received: (qmail 17564 invoked from network); 16 Feb 2005 23:28:16 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Feb 2005 23:28:16 -0000 Message-ID: <4213D70E.7040809@v.loewis.de> Date: Thu, 17 Feb 2005 00:28:14 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: Erik van der Poel , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Michel Suignard wrote: > I have seen European standard bodies spending forests of paper to try > to establish these language tables, but there have never been an > authoritative version because simply you can't. Why do you say that? DENIC is using an authorative list for .DE, see http://www.denic.de/de/domains/idns/liste.html > It is not a bad idea to have language tables to filter, but you have > to allow exception for the reasons exposed above. No, you don't. The exception you mention (Hagen-Dazs) is already covered in the list of characters. It might be that some company cannot use its logo as a domain name - tough luck. There might not even be a Unicode character for the logo. They will find a solution, using some sort of transliteration. If enough users complain that they want a certain, say, Greek character to be available in the .de zone, DENIC might reconsider. However, I very much doubt this will ever happen. For the .de zone, the DENIC list of characters covers all actual needs. It may be that artificial needs are not covered, but I could not care less. It is a very good idea to be more restrictive at the beginning, and the gradually become less restrictive. This is how the DNS started out - allowing only ASCII letters. With IDNA, it is possible to widen this, but that does not mean you cannot have a policy more restrictive than "full Unicode". Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 19:34:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18167 for ; Wed, 16 Feb 2005 19:34:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1ZXZ-00007c-Ha for idn-data@psg.com; Thu, 17 Feb 2005 00:29:09 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1ZXW-00007E-60 for idn@ops.ietf.org; Thu, 17 Feb 2005 00:29:06 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 16:29:07 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 16:29:04 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 16:29:05 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 16:29:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 16:29:04 -0800 Message-ID: Thread-Topic: [idn] homograph attacks thread-index: AcUUfzfMIUn5AVHyT2uYhCV+V0PgeQABNwTw From: "Michel Suignard" To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Cc: "Erik van der Poel" , "William Tan" , "Kane, Pat" , , , "tedd" , X-OriginalArrivalTime: 17 Feb 2005 00:29:04.0419 (UTC) FILETIME=[AF4DF730:01C51487] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: "Martin v. L=F6wis" [mailto:martin@v.loewis.de]=20 >=20 > Michel Suignard wrote: > > I have seen European standard bodies spending forests of=20 > > paper to try=20 > > to establish these language tables, but there have never been an=20 > > authoritative version because simply you can't. >=20 > Why do you say that? DENIC is using an authorative list for .DE, see >=20 > http://www.denic.de/de/domains/idns/liste.html > This is not a language table, it is basically all IDN allowable Latin = characters from Unicode block 0000-007F and 0100-017F. This covers many = European languages. As long as you don't call it a language table we may = be in agreement. Note btw that by doing this they are excluding Welsh = and Irish Gaelic which needs Latin characters in the 1Exx range. And = obviously all Latin letters from the Extended-B are not included, which = is excluding de facto many European minorities.=20 =20 > > It is not a bad idea to have language tables to filter, but=20 > you have=20 > > to allow exception for the reasons exposed above. >=20 > No, you don't. The exception you mention (H=E4agen-Dazs) is=20 > already covered in the list of characters. It might be that=20 > some company cannot use its logo as a domain name - tough=20 > luck. There might not even be a Unicode character for the=20 > logo. They will find a solution, using some sort of=20 > transliteration. If enough users complain that they want a=20 > certain, say, Greek character to be available in the .de=20 > zone, DENIC might reconsider. However, I very much doubt this=20 > will ever happen. For the .de zone, the DENIC list of=20 > characters covers all actual needs. It may be that artificial=20 > needs are not covered, but I could not care less. >=20 See above, there are quite a few European languages that need IDN = allowed Latin characters above 017F. It is my belief that registry = policies should be based on scripts, not subset because you are likely = to miss some characters. I am not advocating for script mix as you may = hint. I am not saying either that the the DENIC list is bad. It is in fact = reasonable (with the minor caveat expressed above), but it is by no mean = a German language table or even an European language table. > It is a very good idea to be more restrictive at the=20 > beginning, and the gradually become less restrictive. This is=20 > how the DNS started out - allowing only ASCII letters. With=20 > IDNA, it is possible to widen this, but that does not mean=20 > you cannot have a policy more restrictive than "full Unicode". I never said that. I am just saying that subsetting Unicode script per = language won't work. You are typically better off allowing all = characters from a given script (within the IDN repertoire constraint and = rules of course). By script I mean the script property as defined by = Unicode.=20 >=20 > Regards, > Martin Regards, Michel =20 From owner-idn@ops.ietf.org Wed Feb 16 19:56:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20137 for ; Wed, 16 Feb 2005 19:56:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1Zub-000764-BK for idn-data@psg.com; Thu, 17 Feb 2005 00:52:57 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1ZuZ-00075h-8d for idn@ops.ietf.org; Thu, 17 Feb 2005 00:52:55 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1H0qZpY237740; Wed, 16 Feb 2005 19:52:36 -0500 Message-ID: <4213EAD3.406@vanderpoel.org> Date: Wed, 16 Feb 2005 16:52:35 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel, You make a good point about Latin language tables and that maybe script tables should be used instead, but my real point was that a registry should not allow the registration of a domain name if it is not being filtered by some sort of character inclusion table. You also point out that it may be inappropriate to try to get ccTLDs to follow rules from external organizations (outside that country). My email was not really directed at these ccTLDs either. Many of them seem to be using character inclusion tables rigorously. My main concern, I guess, is COM. Wouldn't it be a good idea for them to reject or restrict registrations in those cases where the applicable table is not there yet? Note also that the ICANN guidelines say: "top-level domain registries will (a) associate each registered internationalized domain name with one language or set of languages" http://www.icann.org/general/idn-guidelines-20jun03.htm This "set of languages" could be a Unicode "script"? Erik From owner-idn@ops.ietf.org Wed Feb 16 20:03:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20868 for ; Wed, 16 Feb 2005 20:03:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1a2H-0009Fp-Bh for idn-data@psg.com; Thu, 17 Feb 2005 01:00:53 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1a2G-0009Em-7b for idn@ops.ietf.org; Thu, 17 Feb 2005 01:00:52 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1H10XOB227464; Wed, 16 Feb 2005 20:00:33 -0500 Message-ID: <4213ECB0.801@vanderpoel.org> Date: Wed, 16 Feb 2005 17:00:32 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org CC: William Tan , =?ISO-8859-1?Q?=22Martin_v=2E_L=F6w?= =?ISO-8859-1?Q?is=22?= , Michel Suignard , "Kane, Pat" , ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> <421348F8.9060406@dready.org> <4213B916.8030108@vanderpoel.org> In-Reply-To: <4213B916.8030108@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Perhaps "immediately" was too strong a word, and arrogant. My apologies. Any such changes should be carefully considered of course. Erik Erik van der Poel wrote: > Also, it seems to me that registries like COM could "stop the bleeding" > (for now) by immediately deploying systems that enforce a policy where > registrations for languages for which they do not have tables are rejected. From owner-idn@ops.ietf.org Wed Feb 16 20:11:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21560 for ; Wed, 16 Feb 2005 20:11:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1a9g-000Bu7-Fs for idn-data@psg.com; Thu, 17 Feb 2005 01:08:32 +0000 Received: from [80.67.18.15] (helo=smtprelay03.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1a9f-000BtD-AB for idn@ops.ietf.org; Thu, 17 Feb 2005 01:08:31 +0000 Received: (qmail 1305 invoked from network); 17 Feb 2005 01:08:28 -0000 Received: from unknown (HELO [80.185.154.65]) (544451@[80.185.154.65]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2005 01:08:28 -0000 Message-ID: <4213EE8B.8000600@v.loewis.de> Date: Thu, 17 Feb 2005 02:08:27 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: Erik van der Poel , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Suignard wrote: >>> I have seen European standard bodies spending forests of paper to >>> try to establish these language tables, but there have never been >>> an authoritative version because simply you can't. > This is not a language table, it is basically all IDN allowable Latin > characters from Unicode block 0000-007F and 0100-017F. This covers > many European languages. As long as you don't call it a language > table we may be in agreement. Note btw that by doing this they are > excluding Welsh and Irish Gaelic which needs Latin characters in the > 1Exx range. And obviously all Latin letters from the Extended-B are > not included, which is excluding de facto many European minorities. All true - but "so what?". This is an official policy what characters can be used in a "German" domain name, in the .de zone. Whether that makes it a "language table", I don't care. This kind of table is what we have been talking about all along. > I am not advocating for script mix as > you may hint. I am not saying either that the the DENIC list is bad. > It is in fact reasonable (with the minor caveat expressed above), but > it is by no mean a German language table or even an European language > table. This is not the point. The point was your claim: "there cannot be an official table", and I'm merely trying to say "but there is". Now, I see that you make a difference between a character table for a language, and a "language table"; I was unaware that "language table" is a reserved term. > I never said that. I am just saying that subsetting Unicode script > per language won't work. But we are not talking about typesetting here: this is about DNS. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 16 20:41:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23918 for ; Wed, 16 Feb 2005 20:41:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1aZp-000Irv-P6 for idn-data@psg.com; Thu, 17 Feb 2005 01:35:33 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1aZo-000IoY-JF for idn@ops.ietf.org; Thu, 17 Feb 2005 01:35:32 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 17:35:34 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 17:35:31 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 17:35:31 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 17:35:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 17:35:31 -0800 Message-ID: Thread-Topic: [idn] homograph attacks thread-index: AcUUjTuKX3dS8zGJSSGepKH33G9LxAAAfpXQ From: "Michel Suignard" To: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Cc: "Erik van der Poel" , "William Tan" , "Kane, Pat" , , , "tedd" , X-OriginalArrivalTime: 17 Feb 2005 01:35:31.0337 (UTC) FILETIME=[F7B15F90:01C51490] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Martin, I don't think we are so far off. My concern is that many people are = abusing the term 'language' for these tables. I am just saying that = creating exclusive subset of Latin characters in European context is not = necessarily a bad idea but will result in future problems because they = will always discover that few characters are missing from the subset. It is reasonably easy for .de to establish a table as they did and again = it is ok. It is much more challenging for a worlwide TLD such as .com to = establish registration rules. Typically script is a much better selector = than language to establish those tables and associated rules. And I was not talking about typesetting, thank you. Although it does not = hurt to have some background in worldwide character set encoding.=20 Michel =20 From owner-idn@ops.ietf.org Wed Feb 16 21:32:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27706 for ; Wed, 16 Feb 2005 21:32:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1bOF-0005SZ-0I for idn-data@psg.com; Thu, 17 Feb 2005 02:27:39 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1bOC-0005SK-Lc for idn@ops.ietf.org; Thu, 17 Feb 2005 02:27:36 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1bO2-00059Q-2s; Wed, 16 Feb 2005 18:27:26 -0800 Message-Id: <6.1.2.0.2.20050217025055.0cb71eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 17 Feb 2005 03:16:11 +0100 To: "Michel Suignard" , "Martin v. Lwis" From: "JFC (Jefsey) Morfin" Subject: RE: [idn] homograph attacks Cc: "Erik van der Poel" , "William Tan" , "Kane, Pat" , , , "tedd" , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 02:35 17/02/2005, Michel Suignard wrote: >Martin, >I don't think we are so far off. My concern is that many people are >abusing the term 'language' for these tables. Dear Michel, you are absolutely right. The problem is the content of the tag and the term. - IANA TLD Tables are described by language/script/ccTLD from ISO 3166 alpha-2 - languages are defined from ISO 639 - RFC 3066 appointed ietf-languages@alvestrand.no advisory mailing list Members have introduced a "langtag" which also concatenates the same content: language (ISO 639) - Script ISO 15924 - Country (ISO 3166 - therefore missing some ccTLDs). The idea is to document the real language being used with some more accuracy. The term that ISO 639 corresponds to "langues" in French and the proposed langtag to "langage" in French, and what they really need to permit automated interintelligibility would be "parler" in French. This might lead to complex and unnecessary debates. This is why we have adopted the following wording: - langtag for a tag including lingual oriented information. We do not speak of language but of tag. Whatever the use. - lang3tag is internationalization with language/script/localization (localization should be far more complete than just ISO 3066) - lang4tag adds the authoritative reference for the used form of that language (multilingualization) - lang5tag adds the style to document the vernacular environment of usage. >I am just saying that creating exclusive subset of Latin characters in >European context is not necessarily a bad idea but will result in future >problems because they will always discover that few characters are missing >from the subset. > >It is reasonably easy for .de to establish a table as they did and again >it is ok. It is much more challenging for a worlwide TLD such as .com to >establish registration rules. Typically script is a much better selector >than language to establish those tables and associated rules. This has been extensively discussed by the authors of the proposed "RFC 3066 bis" Draft. I disagreed enough with only small but key details, to be credible I think when I say that I fully agree with their need of ISO 639 to define the language (7260 in the current revision), but also the script (you are right this is necessary, but this is not enough for many reasons you described in part) and localization which may change some accepted usages. They identified that the political boarders were the leading descriptor here due to legal obligations, common education, etc. Scripts defined by ISO are also disputed. Better to have an authoritative decision of the TLD Manager as a part of his namespace rules. After all what we want is "normality", so there are cultural, legal, IPR related matters to consider. I understand that M$ has decided to wait and see the way the market reacts. This time I approve M$. jfc From owner-idn@ops.ietf.org Wed Feb 16 21:37:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28101 for ; Wed, 16 Feb 2005 21:37:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1bTx-0006v1-1A for idn-data@psg.com; Thu, 17 Feb 2005 02:33:33 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1bTl-0006uK-OK for idn@ops.ietf.org; Thu, 17 Feb 2005 02:33:21 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id CFCFA4F3F4; Wed, 16 Feb 2005 21:33:17 -0500 (EST) Message-Id: <6.0.0.20.2.20050217091251.0360fac0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 09:20:45 +0900 To: =?ISO-2022-JP?B?Ik1hcnRpbiB2LiBMGyRCi1gbKEJpcyI=?= , Michel Suignard From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: Erik van der Poel , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org In-Reply-To: <4213D70E.7040809@v.loewis.de> References: <4213D70E.7040809@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is very important to be clear about the fact that neither the .de table nor the .ch table (at http://www.switch.ch/de/id/faq/idn.html) too close a relationship with German as a language (or French, Italian, or Romansh in the Swiss case). These tables are as much based on user needs (which we can assume have a linguistic basis) as on technical needs. The Swiss registry decided to keep their iso-8859-1-based implementation, whereas the German registry upgraded to utf-8 when they introduced IDNs. What European standards bodies spent forests of paper on was an attempt at some 'ultimately correct' linguistic-based table. What we need for IDN are reasonably okay tables that do not need to be 'linguistically correct'. Regards, Martin. At 08:28 05/02/17, Martin v. L$BX(Bis wrote: >Michel Suignard wrote: >> I have seen European standard bodies spending forests of paper to try >> to establish these language tables, but there have never been an >> authoritative version because simply you can't. > >Why do you say that? DENIC is using an authorative list for .DE, see > >http://www.denic.de/de/domains/idns/liste.html > >> It is not a bad idea to have language tables to filter, but you have >> to allow exception for the reasons exposed above. > >No, you don't. The exception you mention (H$BgB(Bgen-Dazs) is already >covered in the list of characters. It might be that some company >cannot use its logo as a domain name - tough luck. There might not >even be a Unicode character for the logo. They will find a solution, >using some sort of transliteration. If enough users complain that >they want a certain, say, Greek character to be available in the >.de zone, DENIC might reconsider. However, I very much doubt this >will ever happen. For the .de zone, the DENIC list of characters >covers all actual needs. It may be that artificial needs are not >covered, but I could not care less. > >It is a very good idea to be more restrictive at the beginning, >and the gradually become less restrictive. This is how the DNS >started out - allowing only ASCII letters. With IDNA, it is >possible to widen this, but that does not mean you cannot have >a policy more restrictive than "full Unicode". > >Regards, >Martin > From owner-idn@ops.ietf.org Wed Feb 16 21:51:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29431 for ; Wed, 16 Feb 2005 21:51:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1bh9-000BHC-QB for idn-data@psg.com; Thu, 17 Feb 2005 02:47:11 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1bh7-000BDS-Ma for idn@ops.ietf.org; Thu, 17 Feb 2005 02:47:09 +0000 Received: from lns-p19-4-idf-82-65-252-32.adsl.proxad.net ([82.65.252.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1bh6-0005vJ-AE; Wed, 16 Feb 2005 18:47:08 -0800 Message-Id: <6.1.2.0.2.20050217033411.0cbbc4a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 17 Feb 2005 03:47:00 +0100 To: John C Klensin , idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: RE: [idn] homograph attacks Cc: dam@icann.org In-Reply-To: References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk John, I replied privately to most of your points which are not related to my mail to Pat Kane. I want however to address one of your suggestion in here as it is of interest to everyone to understand what is the real situation. At 18:17 16/02/2005, John C Klensin wrote: >While I think that an "International coordination list" would be >helpful, my assumption is that ICANN's idn-discuss list (see >http://www.icann.org/topics/idn.html for subscription >information and some other information that might be useful) is >intended to serve that purpose. I suggest everyone to access the archives of that ICANN list dedicated to the IDNA deployment. http://forum.icann.org/lists/idn-discuss/ 1. one welcome 2. one broadcast 3. three phishing mails > It is pretty clearly not this, >or any other, IETF list: the IETF made a series of fairly >explicit decisions to not get into the business of deciding what >things could or could not be registered within the very broad >coding mechanisms specified as part of IDNA. This is why this list should probably be moved elsewhere when it starts discussing real issues. jfc From owner-idn@ops.ietf.org Wed Feb 16 22:41:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05199 for ; Wed, 16 Feb 2005 22:41:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1cTv-0000tD-9p for idn-data@psg.com; Thu, 17 Feb 2005 03:37:35 +0000 Received: from [216.254.21.212] (helo=cubesearch.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1cTu-0000l6-46 for idn@ops.ietf.org; Thu, 17 Feb 2005 03:37:34 +0000 Received: by cubesearch.com (Postfix, from userid 505) id 4222F6F464; Wed, 16 Feb 2005 19:37:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by cubesearch.com (Postfix) with ESMTP id 40AEB6F462; Wed, 16 Feb 2005 19:37:31 -0800 (PST) Date: Wed, 16 Feb 2005 19:37:31 -0800 (PST) From: Eric Johanson X-X-Sender: ericj@localhost To: idn@ops.ietf.org Subject: [idn] who should be doing IDN filtering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk I've been lurking on this list for the past few days - - and it seems that we've been thrashing about with different filtering techniques IDN on various TLD/registrars, etc. I hope this post won't prove to be a distraction from that dialog (as I'm one of those "don't know anything about unicode" folks). My question for the group: Are you sure that it's the registrars/TLDs/etc whom should be doing this filtering? I understand that that by using the language tag, it generally might make some type of filtering concepts easier & more practical to deploy. Because this 'language tag' is only available to registrars (when I say registrars, I mean anyone involved with the registration of a new domain, on any TLD), I suspect it makes it impractical to do the filtering at the browser/application level. My question is: ...assuming we can make the language tag available via some dns tricks or some API... Shouldn't we leave the filtering up to the user, and the user's browser? It's likely the application will know more about what the user expects as far as site identity (some tricks I've heard proposed is to not warn about sites in the users favorites, or create whitelists of 'trusted sites' [see trustbar]), and knows about the local language settings. For example, if I have windows XP, with the default language set to german, the browser isn't (as obligated) to warn the user of potential IDN phishing attacks when it sees german scripts in the IDN. My hope is that this idea could scale to any script/language, but I fear that I'm missing something. I'm not proposing we don't have some type of filtering of IDNs at the registrars, etc. I'm simply proposing we give application (browser, email) developers the same information the registrars have, in order to give them a fighting chance of warning the user of a homograph attack. Taking this one step further: .. if we think about IDN homograph attacks as the same class of problem as 'spam/UCE'.... ..Then tools will just start to exist to filter it. Imagine, if you will, a RBL which collects IDNs found in spam/phishing attacks, and communicates with a users browser. Comments/ideas/flames? -Eric 'Dodgy Character' Johanson From owner-idn@ops.ietf.org Wed Feb 16 23:19:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08687 for ; Wed, 16 Feb 2005 23:19:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1d4G-000DtF-Hh for idn-data@psg.com; Thu, 17 Feb 2005 04:15:08 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1d4B-000Djy-Sh for idn@ops.ietf.org; Thu, 17 Feb 2005 04:15:04 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1H4EXuq166566; Wed, 16 Feb 2005 23:14:39 -0500 Message-ID: <42141A29.4060302@vanderpoel.org> Date: Wed, 16 Feb 2005 20:14:33 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: idn@ops.ietf.org, dam@icann.org Subject: Re: [idn] homograph attacks References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, It's been a while! In fact, it's been so long since I've really taken part in any RFC or Internet Draft related discussion that I'd like to apologize in advance if the following questions are, um, stupid... John C Klensin wrote: > While I think that an "International coordination list" would be > helpful, my assumption is that ICANN's idn-discuss list (see > http://www.icann.org/topics/idn.html for subscription > information and some other information that might be useful) is > intended to serve that purpose. It is pretty clearly not this, > or any other, IETF list: the IETF made a series of fairly > explicit decisions to not get into the business of deciding what > things could or could not be registered within the very broad > coding mechanisms specified as part of IDNA. I had a look at the welcome message of the idn-discuss list at ICANN, and it seems to be aimed more at the registry operators. I was hoping to find a forum where a broader group of interested parties could discuss the issue of IDN spoofing. I'm thinking of IDN applications, domain registries, ICANN and even IETF. The reason I include IETF in this list is because I believe the IDN RFCs are a product of the IETF, and (1) those RFCs are not at the Standard Maturity Level yet, and (2) any discussion of IDN spoofing should probably include a discussion of the nameprep spec, since that may be something we could tweak, to help solve the problem. If, as you say, the IETF has decided not to get into the business of deciding what can and what cannot be registered, then I suppose a forum centered on the registries (probably ICANN?) would be best. But then I still wonder what forum is going to be discussing the IDN RFCs when they attempt to climb to the Draft Standard Maturity Level. I note that the IETF IDN WG has concluded. Also, I saw that you published a new version of your IDN guidelines: http://www.ietf.org/internet-drafts/draft-klensin-reg-guidelines-06.txt Where is this I-D to be discussed? Thanks, Erik From owner-idn@ops.ietf.org Thu Feb 17 00:11:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14242 for ; Thu, 17 Feb 2005 00:11:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1dsR-000510-C2 for idn-data@psg.com; Thu, 17 Feb 2005 05:06:59 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1dsQ-00050k-8Z for idn@ops.ietf.org; Thu, 17 Feb 2005 05:06:58 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1H56kpY174654; Thu, 17 Feb 2005 00:06:46 -0500 Message-ID: <42142666.6080005@vanderpoel.org> Date: Wed, 16 Feb 2005 21:06:46 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Suignard wrote: > It is much more challenging for a worlwide TLD such as .com to > establish registration rules. Typically script is a much better > selector than language to establish those tables and associated > rules. "Typically"? You make it sound like you've "been there, done that". :-) Seriously, would you please elaborate on your ideas for .com? I would really like to know what you have in mind, specifically, to combat the homograph problem. Thanks, Erik From owner-idn@ops.ietf.org Thu Feb 17 02:02:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26978 for ; Thu, 17 Feb 2005 02:02:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1fZV-000ALJ-Q4 for idn-data@psg.com; Thu, 17 Feb 2005 06:55:33 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1fZL-000AE2-QU for idn@ops.ietf.org; Thu, 17 Feb 2005 06:55:23 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 22:55:23 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 22:55:23 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 22:55:22 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 22:55:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] homograph attacks Date: Wed, 16 Feb 2005 22:55:23 -0800 Message-ID: Thread-Topic: [idn] homograph attacks thread-index: AcUUrpMfk31Bpok/RximvrJwdAT0CwADNGYg From: "Michel Suignard" To: "Erik van der Poel" Cc: =?iso-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , "William Tan" , "Kane, Pat" , , , "tedd" , X-OriginalArrivalTime: 17 Feb 2005 06:55:21.0625 (UTC) FILETIME=[A5FEF090:01C514BD] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: Erik van der Poel [mailto:erik@vanderpoel.org]=20 >=20 > Seriously, would you please elaborate on your ideas for .com?=20 > I would really like to know what you have in mind,=20 > specifically, to combat the homograph problem. >=20 Like many of you this is also a learning phase for me, although I have = been involved around IDN and IRI issues for quite a while now, and = Unicode/10646 much longer. I still think that the best approach is a = collective effort probably through the Unicode Consortium with some = input from W3C and IETF experts. This was discussed at the last week = Unicode Technical Committee (UTC) meeting where many participants wanted = to contribute on this topic. My personal opinion is that gTLDs such as .com can for sure look for = ideas in current ccTLD policies but they have different customers and = will typically have to be more liberal. This is why I think the script = based approach is more practical. =20 Regards, Michel From owner-idn@ops.ietf.org Thu Feb 17 04:51:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00159 for ; Thu, 17 Feb 2005 04:51:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1iF7-000FbV-7m for idn-data@psg.com; Thu, 17 Feb 2005 09:46:41 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1iF6-000FbJ-9e for idn@ops.ietf.org; Thu, 17 Feb 2005 09:46:40 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 260DB4F227; Thu, 17 Feb 2005 04:46:36 -0500 (EST) Message-Id: <6.0.0.20.2.20050217174850.06842c80@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 17:55:28 +0900 To: Erik van der Poel , Michel Suignard From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: "Martin v. Loewis" , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org In-Reply-To: <42142666.6080005@vanderpoel.org> References: <42142666.6080005@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 14:06 05/02/17, Erik van der Poel wrote: >Michel Suignard wrote: >> It is much more challenging for a worlwide TLD such as .com to >> establish registration rules. Typically script is a much better >> selector than language to establish those tables and associated >> rules. > >"Typically"? You make it sound like you've "been there, done that". :-) > >Seriously, would you please elaborate on your ideas for .com? I would really like to know what you have in mind, specifically, to combat the homograph problem. Hello Eric, I can't answer fro Michel. But I just had a look at the ICANN guidelines, and they use the word 'language' 19 times (hope I counted correctly), and the word 'script' not a single time. However, there are at least as much 'script' aspects as there are 'language' aspects in the current problem, and if you look at actual implementation in ccTLD registries that have deployed IDNs, it's also quite a bit about 'script'. As an example, .ch has published a single table although they are very clearly working with three or four languages. Too much emphasis on 'language' rather than 'script' also has lead to strange claims such as that creating IDN TLDs is impossible because we cannot create 6000 versions of .com. Again, looking at this as a script problem is much more appropriate, after all, neither "com" nor any ccTLD nor most of the gTLDs are associated with any single language. Regards, Martin. From owner-idn@ops.ietf.org Thu Feb 17 04:52:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00179 for ; Thu, 17 Feb 2005 04:51:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1iFA-000Fbq-QG for idn-data@psg.com; Thu, 17 Feb 2005 09:46:44 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1iF8-000Fba-K3 for idn@ops.ietf.org; Thu, 17 Feb 2005 09:46:42 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id C7A534F0FD; Thu, 17 Feb 2005 04:46:40 -0500 (EST) Message-Id: <6.0.0.20.2.20050217175620.0685c470@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 18:17:32 +0900 To: Eric Johanson , idn@ops.ietf.org From: Martin Duerst Subject: Re: [idn] who should be doing IDN filtering In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Eric, At 12:37 05/02/17, Eric Johanson wrote: >My question for the group: > >Are you sure that it's the registrars/TLDs/etc whom should be doing this filtering? Yes, this would be ideal. The main reason is that a domain name gets registered 1 time, but it gets used thousands if not millions of times. Also, there is much less software for registration, which can be updated much more easily, than e.g. updating all the browsers around the world. In addition, some approaches require tables, which might be difficult to fit into a mobile phone. This does not exclude that browsers would implement some warnings in certain cases, but that may be with completely different means (e.g. a browser could check a "phishing alert" database and put up a warning for pajpal.com; it seems that you already had a similar idea at the end of this mail). >I understand that that by using the language tag, it generally might make some type of filtering concepts easier & more practical to deploy. > >Because this 'language tag' is only available to registrars (when I say registrars, I mean anyone involved with the registration of a new domain, on any TLD), I suspect it makes it impractical to do the filtering at the browser/application level. Not exactly. The main reason would be that even with language tags, different registries may have different policies. On the other hand, except for those cases where there is a 'reservation' of variants, even the registrar/registry doesn't have to know the lanugage except for tracking purposes. As long as it fits any one of the tables they offer, it's okay. And 'reservation' up to now only has been used to address the simplified/traditional case in Chinese. While it may look nice in theory to e.g. create some mechanism for reserving/ equating o-umlaut and oe in German, and so on, this isn't actually appropriate for names (Goethe (the famous one) would never be written Go"the, altough there are plenty of Germans that write their name that way). Then there are the cases where an 'o' and an 'e' are adjacent without being pronounced like o-umlaut. And then the number of such letters per name is small enough to let people register both variants if they think they need to. >My question is: > >...assuming we can make the language tag available via some dns tricks or some API... > >Shouldn't we leave the filtering up to the user, and the user's browser? It's likely the application will know more about what the user expects as far as site identity (some tricks I've heard proposed is to not warn about sites in the users favorites, or create whitelists of 'trusted sites' [see trustbar]), and knows about the local language settings. These kinds of warnings are indeed appropriate on the user side. But the language tag isn't helpful for that; the user sees (and is potentially fooled by) the characters, not the language tag. >For example, if I have windows XP, with the default language set to german, the browser isn't (as obligated) to warn the user of potential IDN phishing attacks when it sees german scripts in the IDN. My hope is that this idea could scale to any script/language, but I fear that I'm missing something. No, this is an idea worth exploring. But the problem is that it may be a lot of work to try to figure out what kinds of letters German users confuse, and there may be a lot of variation between different users, and browser makers may have a hard time covering more than just a few languages. >I'm not proposing we don't have some type of filtering of IDNs at the registrars, etc. I'm simply proposing we give application (browser, email) developers the same information the registrars have, in order to give them a fighting chance of warning the user of a homograph attack. They have a chance already. Language information doesn't buy them anything more, I think. >Taking this one step further: > >.. if we think about IDN homograph attacks as the same class of problem as 'spam/UCE'.... > >..Then tools will just start to exist to filter it. Imagine, if you will, a RBL which collects IDNs found in spam/phishing attacks, and communicates with a users browser. Feasible maybe, and if feasible, can be used for plain old ASCII stuff, too. Or is it that because it hasn't been used for ASCII, we may conclude that it doesn't work for IDNs? Mind you, there are very serious organizations (e.g. http://www.antiphishing.org/) which are very hard at work to make sure that anybody involved in real phishing (as opposed to setting up an example to show how you might do it) gets removed from the DNS and the Web as quickly as they can manage. Regards, Martin. From owner-idn@ops.ietf.org Thu Feb 17 04:52:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00186 for ; Thu, 17 Feb 2005 04:52:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1iF3-000FbC-Od for idn-data@psg.com; Thu, 17 Feb 2005 09:46:37 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1iF1-000Fas-6K for idn@ops.ietf.org; Thu, 17 Feb 2005 09:46:35 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 591204F227; Thu, 17 Feb 2005 04:46:33 -0500 (EST) Message-Id: <6.0.0.20.2.20050217092809.03625600@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 18:46:16 +0900 To: John C Klensin , idn@ops.ietf.org From: Martin Duerst Subject: RE: [idn] homograph attacks Cc: dam@icann.org In-Reply-To: References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello John, Some points below. At 02:17 05/02/17, John C Klensin wrote: >Responding to several messages together, rather than sending a >series of fragmented messages... >--On Wednesday, 16 February, 2005 15:09 +0100 "JFC (Jefsey) >Morfin" wrote: >Actually, that is not the ICANN/IANA requirement, nor is it >clear where their requirement applies (e.g., such registrations >are optional). Their requirement is unclear and, IMO, needs >updating. I hope that they will get to that updating process >RSN. On the other hand, I have had that hope for well over a >year. Progress is unlikely to be made on those subjects by >further discussion here. I'd be glad to hear about what you think needs updating (I'm thinking there is a need for updating, too), in any appropriate venue. (I subscribed to the ICANN list you mentioned) >In a separate note, at Tuesday, February 15, 2005 7:44 PM, you >wrote, in part... > >>> Should it not be supported on the IANA server and common to >>> all the gTLDs? > (ii) An interesting distinction has been identified > between the needs of a domain that must serve the > requirements of a particular country and a domain that > supports the language commonly associated with that > country. For the first case, of which .DE is the > best-worked-out example, there is a legitimate > requirement for registration of common names, company > names, street names, etc., in Germany. Given history, > that list will include strings and characters that don't > exist in the German language. It may include strings > the contain combinations of characters that do no appear > together in any contemporary language that uses > Roman-based characters. By contrast, if a gTLD creates > a language table defined around the German language, > many of the characters needed by .DE are simply invalid. > That contrast, which Martin has identified in the form > of the difference between the "German" tables used in > the TLDs for Austria and Switzerland relative to those > used in Germany) may require taking a different look at > the rules and guidelines (and table registration models) > than we have heretofore taken: either for rather > different guidelines for ccTLDs than for gTLDs, or for > rethinking the registration model, or both. I think the idea of a gTLD serving German language needs is not necessarily helpful. Of course they need to serve German language needs, as well as the needs of many other languages. But do they have to say "oh, well, .DE developped this table for the needs in Germany, including the needs of the German language as a subset, so we should try and find that subset"? I'd claim that that's mostly investing work at the wrong place. In many cases, a gTLD can just create tables that cover a number of languages at the same time, maybe even a whole script as proposed by Michel. But this has to be done bottom-up, so it may take time. > The issue that Pat identifies with Tajik is another > piece of the same puzzle: many of us may believe that > there is no possible reason to mix the three scripts in > which that language can be written in a single label, > and I certainly trust Roozbeh's knowledge and experience > in that area. Very much agreed. > Certainly, it would make things safer to > prohibit any mixing (note that IDNA's BIDI restrictions > essentially prohibit mixing an Arabic-derived script > with anything other than itself, another Arabic-derived > script, or Hebrew). Good point, but a small correction: These restrictions only prevent mixing RTL scripts (Hebrew, Arabic, Syriac,...) with LTR scripts (all the others). They don't prevent mixing RTL scripts among each other. And of course, exceptions such as Japanese as well as languages that e.g. use a few Greek characters in addition to the Latin alphabet have to be addressed (such languages of course use those characters from Greek that look different from Latin characters, so there should be no, or not much, of a phishing issue). > However, we have a long history of > DNS labels that could not possibly be words in any > language. Whether or not to permit mixed-script labels > is presumably an issue that the registry for .TJ will > need to sort out (I have been told, for example, that > mixed Cyrillic and Latin-character labels are likely to > be a requirement in Serbia and Montenegro, although this > illustration might give them pause). And the best > answer for them might or might not be the best answer > for a gTLD. I'm a bit sceptical for the need for true mixed-script labels for Serbian (i.e. something like latin-CYRILLIC). One main issue here is that it's more work to type in mixed-script labels. >In addition, as Hotta-san's very helpful note points out, one >could considerably reduce the scope of the identified >confusion/phishing problems by aggressively applying a variant >model across scripts, restricting the registration of homographs >to the same registrant. I personally suspect that will not >prove practical, from a policy standpoint, in the collection of >alphabetic scripts that share Old Semitic origins, but that is, >IMO, just another argument for giving different registries the >flexibility to develop their own policies and take >responsibility for the consequences of those policies. I share your suspicions. The 'variant reservation model' was carefully worked out to address concerns about simplified/traditional Chinese. Even the Japanese, who participated in working out this model, haven't adopted it for themselves, although there is a considerable amount of simplified/traditional variants in Japanese, too (though less than in Chinese). >--On Wednesday, 16 February, 2005 08:07 +0100 "\"Martin v. >L$BX(Bis\"" wrote, responding to Soobok Lee: > >>> All Cyrillic label "HP" (.com) can be registered even in >>> Russian language pack. >>> >>> Cyrillic "HP".COM in its uppercase form looks the same as >>> all ASCII "HP.COM". >>> >>> Any Registration Process should filter out these "HP" like >>> combinations.. > >But the only way to do that would require that a domain that >permits Cyrillic characters must ban ASCII characters and vice >versa. I would predict that will just never happen, if only >because every domain that exists today has a long of all-ASCII >labels in it. It is not a very good example (see below), but I >note that this particular example is only of the reasons why >"identify a mixed-script label in the application" may be a >useful tool, but is not a solution -- this is not a mixed-script >label. There is one possible scenario where this might happen. If there is e.g. a Cyrillic equivalent to .ru, it is very probable that the Cyrillic registrations will go into that equivalent rather than into .ru, because a series of Cyrillic labels looks better, is easier to read, is easier to remember, and is easier to type than mixed labels. If such a tendency gets firmly established, it could be possible to at some point simply say that Cyrillic registations go into the Cyrillic TLD, and Latin registrations go into the Latin TLD. Of course, there are a lot of things that need to happen before we could get to such a state, but it's at least a scenario. And please notice that spoofing in TLDs isn't a problem, because TLDs can simply be designed to avoid homographs; the Cyrillic equivalent of .ru would be choosen to not look like .py (Paraguay), but maybe something like Cyrillic r (looks like p) followed by a short i (looks like (small) mirrored N with a hook on top). >And I hope we can all figure out a way to work together to make >this work. It is important, "don't use IDNs" isn't an answer >now and never has been, and the alternatives are just a choice >among ways to fragment the Internet. Yes, this is the most important point! Regards, Martin. From owner-idn@ops.ietf.org Thu Feb 17 04:52:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00238 for ; Thu, 17 Feb 2005 04:52:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1iF1-000Far-1Q for idn-data@psg.com; Thu, 17 Feb 2005 09:46:35 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1iEz-000Faa-43 for idn@ops.ietf.org; Thu, 17 Feb 2005 09:46:33 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id F3DD54F100; Thu, 17 Feb 2005 04:46:30 -0500 (EST) Message-Id: <6.0.0.20.2.20050217090918.0360fda0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 18:24:09 +0900 To: =?ISO-2022-JP?B?Ik1hcnRpbiB2LiBMGyRCi1gbKEJpcyI=?= , "JFC (Jefsey) Morfin" From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: "Kane, Pat" , idn@ops.ietf.org In-Reply-To: <4213BDB5.5070700@v.loewis.de> References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> <4213BDB5.5070700@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 06:40 05/02/17, Martin v. L$BX(Bis wrote: >JFC (Jefsey) Morfin wrote: >> 1. When you register a IANA tag, you are to register it by language, script and ccTLD. This is clear. > >I don't see how this is relevant for this discussion. If the .com >registrar decides to use a subset of 639 only, I consider this a valid >choice. No need to register any language tag with IANA; all tags >you ever want to use are already there. Not exactly correct. For cases like Serbian, Azerbaijani, Tajik, which can be written with different scripts, you need more than ISO 639. Serbian and Azerbaijani have script variant tags registered at IANA (see http://www.iana.org/assignments/language-tags); Tajik doesn't (yet). There is a draft (see http://www.ietf.org/internet-drafts/draft-phillips-langtags-10.txt) that makes script codes generative, i.e. they don't have to be registered anymore. >> 2. W3C discovered that a language tag by ISO 639 was not enough to describe an XML document. [incorrect; extending ISO 639 with country codes was done by RFC 1766, with the main input comming from email] Regards, Martin. From owner-idn@ops.ietf.org Thu Feb 17 05:02:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01261 for ; Thu, 17 Feb 2005 05:02:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1iQf-000Ijl-AX for idn-data@psg.com; Thu, 17 Feb 2005 09:58:37 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1iQc-000IjM-7O for idn@ops.ietf.org; Thu, 17 Feb 2005 09:58:34 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D1iQa-0003rB-00 for ; Thu, 17 Feb 2005 01:58:32 -0800 Date: Thu, 17 Feb 2005 09:58:32 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] who should be doing IDN filtering Message-ID: <20050217095832.GD12777~@nicemice.net> Reply-To: IETF idn working group References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Eric Johanson wrote: > Are you sure that it's the registrars/TLDs/etc whom should be doing > this filtering? I think registries should be doing filtering, but I don't think browsers should depend on it, because it's already too late, as the paypal example proves. I think browsers (and in general, applications that receive domain names from untrusted sources and display them to the user as IDNs) ought to provide a second line of defense by trying to expose suspicious domain names. > Because this 'language tag' is only available to registrars (when I > say registrars, I mean anyone involved with the registration of a > new domain, on any TLD), I suspect it makes it impractical to do the > filtering at the browser/application level. I don't see why. > ...assuming we can make the language tag available via some dns tricks or > some API... I don't see that happening. The IDN working group decided quite deliberately that domain names would not contain any meta-info like language tags; they're just text strings. Still, I expect that some not-terribly-complex heuristics, based only on the bare character strings, could go a long way toward exposing suspicious domain names. AMC From owner-idn@ops.ietf.org Thu Feb 17 07:06:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13641 for ; Thu, 17 Feb 2005 07:06:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1kJi-000Fvm-7E for idn-data@psg.com; Thu, 17 Feb 2005 11:59:34 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1kJd-000FvF-Ob for idn@ops.ietf.org; Thu, 17 Feb 2005 11:59:30 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1HBxPJR001135 for ; Thu, 17 Feb 2005 20:59:28 +0900 Message-ID: <42148717.8040904@lsb.org> Date: Thu, 17 Feb 2005 20:59:19 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering References: <20050217095832.GD12777~@nicemice.net> In-Reply-To: <20050217095832.GD12777~@nicemice.net> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Adam ! Adam M. Costello wrote: >I don't see that happening. The IDN working group decided quite >deliberately that domain names would not contain any meta-info like >language tags; they're just text strings. > > Yes. human transcripting or copy&paste would not coexist with such lang tags. >Still, I expect that some not-terribly-complex heuristics, based only >on the bare character strings, could go a long way toward exposing >suspicious domain names. > > suspicious names from cyrillic i and latin i can be easily compared against in the registration stage without any huristics , only with "tables". Yes. it would not be so terribliy complex. :-) Soobok From owner-idn@ops.ietf.org Thu Feb 17 08:00:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17907 for ; Thu, 17 Feb 2005 08:00:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1l9P-0001LX-LN for idn-data@psg.com; Thu, 17 Feb 2005 12:52:59 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1l9O-0001LE-NN for idn@ops.ietf.org; Thu, 17 Feb 2005 12:52:58 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id A52604EFCA; Thu, 17 Feb 2005 07:52:55 -0500 (EST) Message-Id: <6.0.0.20.2.20050217213605.06d1c3d0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 17 Feb 2005 21:39:29 +0900 To: James Seng From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: idn@ops.ietf.org In-Reply-To: <621f441a8986e71ed205761e0a6e7df1@seng.cc> References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <621f441a8986e71ed205761e0a6e7df1@seng.cc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello James, If using 'language' only, and never mentioning 'script', is by design, then would you mind pointing me to that design, or explaining it to me? Regards, Martin. At 19:05 05/02/17, James Seng wrote: >the choice of words of using language (instead of script) in ICANN community is by design. > >james > >On 17-Feb-05, at PM 04:55, Martin Duerst wrote: > >> At 14:06 05/02/17, Erik van der Poel wrote: >> >Michel Suignard wrote: >> >> It is much more challenging for a worlwide TLD such as .com to >> >> establish registration rules. Typically script is a much better >> >> selector than language to establish those tables and associated >> >> rules. >> > >> >"Typically"? You make it sound like you've "been there, done that". :-) >> > >> >Seriously, would you please elaborate on your ideas for .com? I would really like to know what you have in mind, specifically, to combat the homograph problem. >> >> Hello Eric, >> >> I can't answer fro Michel. But I just had a look at the ICANN guidelines, >> and they use the word 'language' 19 times (hope I counted correctly), >> and the word 'script' not a single time. >> >> However, there are at least as much 'script' aspects as there are >> 'language' aspects in the current problem, and if you look at actual >> implementation in ccTLD registries that have deployed IDNs, it's >> also quite a bit about 'script'. As an example, .ch has published >> a single table although they are very clearly working with three >> or four languages. >> >> Too much emphasis on 'language' rather than 'script' also has lead >> to strange claims such as that creating IDN TLDs is impossible >> because we cannot create 6000 versions of .com. Again, looking >> at this as a script problem is much more appropriate, after >> all, neither "com" nor any ccTLD nor most of the gTLDs are >> associated with any single language. >> >> Regards, Martin. >> > From owner-idn@ops.ietf.org Thu Feb 17 09:41:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29643 for ; Thu, 17 Feb 2005 09:41:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1mmZ-000MzQ-Ac for idn-data@psg.com; Thu, 17 Feb 2005 14:37:31 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1mmW-000Myq-Sj for idn@ops.ietf.org; Thu, 17 Feb 2005 14:37:29 +0000 Received: (qmail 3458 invoked by uid 0); 17 Feb 2005 22:40:30 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.494815 secs); 17 Feb 2005 14:40:30 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.494815 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 17 Feb 2005 22:40:24 +0800 Message-ID: <4214ABF5.3080700@dready.org> Date: Fri, 18 Feb 2005 01:36:37 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , Erik van der Poel , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu Subject: Re: [idn] homograph attacks References: In-Reply-To: X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Michel, >I don't think we are so far off. My concern is that many people are abusing the term 'language' for these tables. I am just saying that creating exclusive subset of Latin characters in European context is not necessarily a bad idea but will result in future problems because they will always discover that few characters are missing from the subset. > > I do not think that a few characters being missing from a particular version of a language table is that big a deal. After all, characters are still being added to Unicode. If the registry finds that there is a real demand for the missing characters, it can decide to revise the table with those characters included with little effort (as compared to shrinking a table.) >It is reasonably easy for .de to establish a table as they did and again it is ok. It is much more challenging for a worlwide TLD such as .com to establish registration rules. > Agreed. However, I think it is a worthwhile effort for a combined effort among gTLDs and relevant language experts to develop language tables that are appropriate for use in a gTLD context, and can be shared by other registries. In some cases, it may not be so difficult as ccTLDs that share a common language with each other often work together while establishing the set of characters to be allowed in their own IDN rollouts (eg. .at/.ch/.de for German and .ca/.ch/.fr for French). >Typically script is a much better selector than language to establish those tables and associated rules. > > A script is a very convenient selector for publishing tables and in other applications such as localization. I don't agree that it applies "typically", although in some cases it does work quite well (.museum and .pl are fine examples.) Even among the 92 characters that DENIC allows, which are all characters from the Latin script, as Roozbeh pointed out in the last ICANN IDN workshop that there is a visual resemblance between U+00D0 (the capital version of U+00F0) and U+0110 (capital version of U+0111). This would be an intra-script conflict (though the characters belong to different code blocks), and compared to the IDN-posing-as-ASCII-domain attack it is arguably less urgent. This serves to illustrate the importance of restricting the characters to the smallest practicable subset in IDN implementations. For a gTLD, the language tag comes in handy, so we could apply different language tables to IDNs according to their intended language. And using a conservative subset of characters for each language table is part of the deal, in order to reduce the possibilities of phishing attack. Best regards, wil. From owner-idn@ops.ietf.org Thu Feb 17 10:25:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05749 for ; Thu, 17 Feb 2005 10:25:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1nTJ-0007QY-Ov for idn-data@psg.com; Thu, 17 Feb 2005 15:21:41 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1nTH-0007QE-99 for idn@ops.ietf.org; Thu, 17 Feb 2005 15:21:39 +0000 Received: from lns-p19-19-idf-82-254-254-137.adsl.proxad.net ([82.254.254.137] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D1nTG-0004nS-5E for idn@ops.ietf.org; Thu, 17 Feb 2005 07:21:38 -0800 Message-Id: <6.1.2.0.2.20050217134801.030d9870@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 17 Feb 2005 16:21:30 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: [idn] Tabtags and IDN tabtag Drafts and open mailing lists? (was RE: [idn] homograph attacks) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On 07:55 17/02/2005, Michel Suignard said: > > From: Erik van der Poel [mailto:erik@vanderpoel.org] > > > > Seriously, would you please elaborate on your ideas for .com? > > I would really like to know what you have in mind, > > specifically, to combat the homograph problem. > > > >Like many of you this is also a learning phase for me, although I have >been involved around IDN and IRI issues for quite a while now, and >Unicode/10646 much longer. I still think that the best approach is a >collective effort probably through the Unicode Consortium with some input >from W3C and IETF experts. This was discussed at the last week Unicode >Technical Committee (UTC) meeting where many participants wanted to >contribute on this topic. > >My personal opinion is that gTLDs such as .com can for sure look for ideas >in current ccTLD policies but they have different customers and will >typically have to be more liberal. This is why I think the script based >approach is more practical. Dear Michel, you, Martin and Erik point out the main problem: a matter which is of the TLD (Registry) Manager and users' sovereign authority is discussed in closed various unrelated fora, like here: as John pointed it out, IETF does not want to get involved. 1. what are we talking about? Users wants consistent language (actually, a vernacular) support. Tables are only a part of the response. The word "language" (different understandings in different languages) is misleading and blocks innovative thinking. An IETF WG-Language would be a bad idea. ietf-languages@alvestrand.no is a private list. We talk of IDN Tables Tags (tabtags) as a crossroad for language ISO 693, Unicode, TLD (there can be other descriptors). 2. where do we want tabtags? IANA tables/files call for creative thinking over tabtags IDN could benefit from. I introduced near Applications IADs the proposition of a WG-Tags. Involved issues are IANA, format, scope, distribution, inheritances, updates, authorities, registry/registrars, functions, applications, etc. etc. I prepare a Draft to push for it. Anyone interested welcome. Its mailing list could show the interest of a WG, in the IETF or not. 3. how do we want to manage them? IDN tabtags are parts of a TLD/PAD namespace policy. Experience in international naming shows that only a grassroots attitude can achieve something. We therefore need an IDN tabtags mailing list, with a clear charter targeting a TLD/PAD IDN BCP and related RFCs for encountered technical administration and application needs. It should be at the same time operational (TLD Managers, PAD Administrators), societal (users), technical (for applied and validated solutions) and political (to respect everyone sovereignty, innovation, privacy). ICANN tried several time, in the proper direction. But by nature it is divisive. ASCII is part of ML, the DNS is part of the global naming. Not the other way around. . ICANN has no and does not claim any legitimacy outside of the RFC 920 scope (cf. ICP-3). So PADs, international keywords, numeric addresses and numbers, RFIDs, OID, handles, etc. are no part of its scope. ICANN is welcome with a "get real, grassroots attitude", in a NRO's/ITU fashion: we do not know if ICANN will still be around in three years time, its strategic plans does not cover our issues while this naming started 28 years ago and will certainly outlive all of us. To make things moving my intent is to propose a framework Draft on the issue. Its discussion could show if there is a need. jfc PS. 1. PAD stands for Private Alias Directory. This is the personal vision of the namespace that users can build or buy from PAD Administrators and use on their own resolver. PADs are obviously fully ML.ML and multisystem. 2. the IDN Tables debate forgets issues like virtual zone management, table updates, that it does not scale: FQDN include lower level phishing car use (YAH00.secure.com). Babel names are good candidates (I did not check if that one works): "emergency@xn--bankofamerica.com" will retain people attention. From owner-idn@ops.ietf.org Thu Feb 17 11:05:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11641 for ; Thu, 17 Feb 2005 11:05:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1o5F-000Foe-Us for idn-data@psg.com; Thu, 17 Feb 2005 16:00:53 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1o5E-000FoN-KC for idn@ops.ietf.org; Thu, 17 Feb 2005 16:00:52 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HG0Quq446290; Thu, 17 Feb 2005 11:00:26 -0500 Message-ID: <4214BF99.9050401@vanderpoel.org> Date: Thu, 17 Feb 2005 08:00:25 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Michel Suignard , "Martin v. Loewis" , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> In-Reply-To: <6.0.0.20.2.20050217174850.06842c80@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Duerst wrote: > Again, looking > at this as a script problem is much more appropriate, after > all, neither "com" nor any ccTLD nor most of the gTLDs are > associated with any single language. Nor is com associated with a single script. I.e. I think you've taken a step in the right direction, namely: language -> script But I believe it would be a good idea to consider taking another step in the same direction: language -> script -> character set StringPrep and NamePrep are great, but I wonder if it might be good to take their ideas one step further to solve the IDN spoofing problem. I.e. to "normalize" the homographs by mapping the similar-looking characters to "base" characters. For example, Cyrillic small 'a' would be mapped to Latin small 'a', since they are virtually identical (and, indeed, given the same glyph index in some fonts, I hear). Of course, this idea is likely to be extremely controversial since any pair of characters that look similar to one person will look different to another. Erik From owner-idn@ops.ietf.org Thu Feb 17 11:09:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12388 for ; Thu, 17 Feb 2005 11:09:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1o9t-000H1X-QS for idn-data@psg.com; Thu, 17 Feb 2005 16:05:41 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1o9p-000H10-Bh for idn@ops.ietf.org; Thu, 17 Feb 2005 16:05:37 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D1o9o-0004V5-Vj for idn@ops.ietf.org; Thu, 17 Feb 2005 11:05:36 -0500 Date: Thu, 17 Feb 2005 11:05:33 -0500 From: John C Klensin To: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering Message-ID: In-Reply-To: <20050217095832.GD12777~@nicemice.net> References: <20050217095832.GD12777~@nicemice.net> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, MAILTO_TO_REMOVE autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 17 February, 2005 09:58 +0000 "Adam M. Costello" wrote: >... >> ...assuming we can make the language tag available via some >> dns tricks or some API... > > I don't see that happening. The IDN working group decided > quite deliberately that domain names would not contain any > meta-info like language tags; they're just text strings. Concur. I also concur with the several folks who have pointed out that, at browser time, language information won't do a whole lot of good, at least without access to every per-domain table for the characters that are assumed to be bound to a given browser. > Still, I expect that some not-terribly-complex heuristics, > based only on the bare character strings, could go a long way > toward exposing suspicious domain names. I used to be convinced of this, but have become increasingly skeptical about how far it would take us. The easiest tests in principle are for for homogeneity of characters within a label (the "one label, one script" test, more or less). Those tests are indeed fairly simple if the label contains characters that form a contiguous block in Unicode that conforms, more or less, to one script. That requires a somewhat fuzzy definition of "script", which is probably ok, but also isn't a hugely good test once one gets out of the low-end of the BMP and the scripts taken over, as blocks, from prior standards. After that, the tests get more complex, to the point that one can imagine needing all of the Unicode script tables (assuming they are adequate, which they probably are for this purpose) within the application to make a good test. A test based on those tables wouldn't be terribly complex computationally, but the notion of carrying those tables around in resource-limited devices, or even in a browser whose footprint one was trying to minimize, gets a little dicey. But the important question, I think, is what attacks that would protect us against. Certainly, it would provide protection against a name accidentally registered with an odd mix of characters. But I suggest that is a null set -- if a label is entered into the DNS with a heterogeneous collection of characters, it is because someone decided to do it and the registrar and registry decided to permit them to do it. That isn't an accident, that is a deliberate set of decisions, for whatever reasons. As the bad guys get more sophisticated, there are going to be attacks that will be far harder to detect than either the paypal or yah00 examples that have shown up on this list, many of them probably involving mixtures of scripts neither of which is Roman-based. So, should the browsers (or other UI programs) take whatever precautions and issue whatever warnings are reasonably feasible? Sure. Should we assume that will help very much against a determined and sophisticated attacker? Nope. Can a lot more be done at registration time than at lookup (or user inspection) time? Yes, certainly -- not only is the code base easier to control and the "language" information available, as has been pointed out, but taking some time on _those_ servers to look up script tables, compare them to labels, and even apply variant or other cross-checking rules if the domain considers that appropriate would be perfectly rational. I think we will find ourselves, a few years down the line, in a situation in which users discover that names in some domains, by virtue of tighter registration policies, will be safer to use than others. If that results in competitive pressures on the more relaxed ones, so much the better. But, in the general case, it may be about as much as can be done. john From owner-idn@ops.ietf.org Thu Feb 17 11:23:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15447 for ; Thu, 17 Feb 2005 11:23:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1oMF-000JbB-VO for idn-data@psg.com; Thu, 17 Feb 2005 16:18:27 +0000 Received: from [68.168.78.199] (helo=mta9.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1oMC-000Jaq-LA for idn@ops.ietf.org; Thu, 17 Feb 2005 16:18:24 +0000 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050217161823.OVLE23282.mta9.adelphia.net@DEWELL>; Thu, 17 Feb 2005 11:18:23 -0500 Message-ID: <004201c5150c$41ca6060$030aa8c0@DEWELL> From: "Doug Ewell" To: Cc: "tedd" References: <66F7005C4F04C14B89DE467C76D2445053D5E4@MOU1WNEXMB01.vcorp.ad.vrsn.com> Subject: Re: [idn] homograph attacks Date: Thu, 17 Feb 2005 08:18:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just addressing a *very small* corner of this subject. "tedd" wrote: > Let's see, if I understand the solution, we use Cyan for ASCII and > Yellow for Cyrillic, and... -- hey just how many scripts are there > and how many colors are available? You know, a single domain name > might take on the look of one of my granddaughter's fruit-loop > bracelets. So, I'm not sure how that would work. Isn't that exactly the sort of visual cue you might want for an unexpected mixed-script name? Legitimate domain names probably will not have more than two Froot Loop flavors, except for Japanese which might have three. The rest of tedd's message left me with sort of a vague feeling that he disagrees with Paul. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Thu Feb 17 11:24:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15726 for ; Thu, 17 Feb 2005 11:24:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1oOI-000KAO-Tl for idn-data@psg.com; Thu, 17 Feb 2005 16:20:34 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1oOH-000KA2-Ob for idn@ops.ietf.org; Thu, 17 Feb 2005 16:20:33 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HGKLuq370114; Thu, 17 Feb 2005 11:20:21 -0500 Message-ID: <4214C445.9070106@vanderpoel.org> Date: Thu, 17 Feb 2005 08:20:21 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Tan CC: Michel Suignard , =?ISO-8859-1?Q?=22M?= =?ISO-8859-1?Q?artin_v=2E_L=F6wis=22?= , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> In-Reply-To: <4214ABF5.3080700@dready.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit William Tan wrote: > For a gTLD, the language tag comes in handy, so we > could apply different language tables to IDNs according to their > intended language. This is not really in the spirit of DNS itself, though. Before IDN was invented, people registered domain names that weren't in any language. For example, the name "microsoft" was not a word in any language when it was first introduced. So it is not really fair to the IDN registrants to require them to state what language or set of languages their domain name is intended to be in, since DNS has not previously imposed such a restriction, and a lot of domain names have already been registered under this relaxed convention. Erik From owner-idn@ops.ietf.org Thu Feb 17 11:41:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19181 for ; Thu, 17 Feb 2005 11:41:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1oe8-000NLT-Rv for idn-data@psg.com; Thu, 17 Feb 2005 16:36:56 +0000 Received: from [68.168.78.199] (helo=mta9.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1oe6-000NIt-Lv for idn@ops.ietf.org; Thu, 17 Feb 2005 16:36:54 +0000 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050217163653.QBRF23282.mta9.adelphia.net@DEWELL>; Thu, 17 Feb 2005 11:36:53 -0500 Message-ID: <005301c5150e$d6820da0$030aa8c0@DEWELL> From: "Doug Ewell" To: "Erik van der Poel" , "William Tan" Cc: "Michel Suignard" , "=?utf-8?Q?Martin_v._L=C3=B6wis?=" , "Kane, Pat" , , , "tedd" , , References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> Subject: Re: [idn] homograph attacks Date: Thu, 17 Feb 2005 08:36:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: >> For a gTLD, the language tag comes in handy, so we >> could apply different language tables to IDNs according to their >> intended language. > > This is not really in the spirit of DNS itself, though. Before IDN was > invented, people registered domain names that weren't in any language. > For example, the name "microsoft" was not a word in any language when > it was first introduced. I hope Erik is able to get this message across, because I haven't, despite many attempts. For each of the following domain names, determine the "intended language": * google * altavista * yahoo * m-w * taco (this one may surprise you) -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Thu Feb 17 11:42:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19381 for ; Thu, 17 Feb 2005 11:42:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1ogO-000Nnf-0K for idn-data@psg.com; Thu, 17 Feb 2005 16:39:16 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1ogM-000NnH-KI for idn@ops.ietf.org; Thu, 17 Feb 2005 16:39:14 +0000 Received: (qmail 23755 invoked from network); 17 Feb 2005 16:39:13 -0000 Received: from unknown (HELO [80.185.158.173]) (544451@[80.185.158.173]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2005 16:39:13 -0000 Message-ID: <4214C8AF.3070708@v.loewis.de> Date: Thu, 17 Feb 2005 17:39:11 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: "JFC (Jefsey) Morfin" , "Kane, Pat" , idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> <4213BDB5.5070700@v.loewis.de> <6.0.0.20.2.20050217090918.0360fda0@localhost> In-Reply-To: <6.0.0.20.2.20050217090918.0360fda0@localhost> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Duerst wrote: > >I don't see how this is relevant for this discussion. If the .com > >registrar decides to use a subset of 639 only, I consider this a valid > >choice. No need to register any language tag with IANA; all tags > >you ever want to use are already there. > > Not exactly correct. For cases like Serbian, Azerbaijani, Tajik, > which can be written with different scripts, you need more than > ISO 639. Please read my statement again. *If* the registrar decides to use a subset of 639 only, *then* all tags you ever want to use are already there. Now, the question is how the registrar deals with 639 languages that use multiple scripts. There are two obvious options: 1. all characters in any of the scripts of the language can be allowed in a domain label (allowing for unintended homographic labels) 2. the characters of the language are separated into disjoint scripts, and each label registered for a language is required to fall into one script. There are other options as well, of course: the registrar could try to block labels in other scripts than the registered one, if they are transliterations of each other. For example, for Tajik, it might be sensible to block a Latin label if the equivalent Cyrillic one has been registered. Regards, Martin From owner-idn@ops.ietf.org Thu Feb 17 11:43:45 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19774 for ; Thu, 17 Feb 2005 11:43:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1ohl-000O0G-CU for idn-data@psg.com; Thu, 17 Feb 2005 16:40:41 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1ohk-000Nzv-Cf for idn@ops.ietf.org; Thu, 17 Feb 2005 16:40:40 +0000 Received: from [10.20.30.249] (dsl2-63-249-109-246.cruzio.com [63.249.109.246]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HGeciS067963 for ; Thu, 17 Feb 2005 08:40:39 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050217095832.GD12777~@nicemice.net> References: <20050217095832.GD12777~@nicemice.net> Date: Thu, 17 Feb 2005 08:39:52 -0800 To: IETF idn working group From: Paul Hoffman Subject: Re: [idn] who should be doing IDN filtering Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 9:58 AM +0000 2/17/05, Adam M. Costello wrote: >I think registries should be doing filtering, but I don't think browsers >should depend on it, because it's already too late, as the paypal >example proves. I think browsers (and in general, applications that >receive domain names from untrusted sources and display them to the user >as IDNs) ought to provide a second line of defense by trying to expose >suspicious domain names. I fully agree with Adam here. If there is no way to enforce registries doing the right thing (and ICANN has shown no ability to enforce nearly anything), then relying on them for security is silly. This is particularly true if some registries pay more attention to their customers who want to pay for mixed-script domain names than they pay to ICANN. > > ...assuming we can make the language tag available via some dns tricks or >> some API... > >I don't see that happening. The IDN working group decided quite >deliberately that domain names would not contain any meta-info like >language tags; they're just text strings. Right. If you want to re-engineer the IDN bits-on-the-wire protocol in ways that were considered and rejected, feel free to submit a new Internet Draft and see if there is community interest. >Still, I expect that some not-terribly-complex heuristics, based only >on the bare character strings, could go a long way toward exposing >suspicious domain names. Reducing phishing is sufficient because we can never eliminate it. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 17 11:46:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20540 for ; Thu, 17 Feb 2005 11:46:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1ojq-000Ody-ST for idn-data@psg.com; Thu, 17 Feb 2005 16:42:50 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1ojp-000Odg-BW for idn@ops.ietf.org; Thu, 17 Feb 2005 16:42:49 +0000 Received: (qmail 5135 invoked from network); 17 Feb 2005 16:42:48 -0000 Received: from unknown (HELO [80.185.158.173]) (544451@[80.185.158.173]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2005 16:42:48 -0000 Message-ID: <4214C986.4020801@v.loewis.de> Date: Thu, 17 Feb 2005 17:42:46 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: Martin Duerst , Michel Suignard , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <4214BF99.9050401@vanderpoel.org> In-Reply-To: <4214BF99.9050401@vanderpoel.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > StringPrep and NamePrep are great, but I wonder if it might be good to > take their ideas one step further to solve the IDN spoofing problem. > I.e. to "normalize" the homographs by mapping the similar-looking > characters to "base" characters. Only by means of blocking registration. A registration can be blocked not only because it violates static rules, but also because it is (or could be) a homograph for a different, already registered, label. This is indeed the case already in .COM for Chinese labels: registration of a single label blocks an entire family of labels - not necessarily homograph ones, but labels that Chinese readers would consider "same". Regards, Martin From owner-idn@ops.ietf.org Thu Feb 17 11:47:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20602 for ; Thu, 17 Feb 2005 11:47:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1okJ-000OlJ-AF for idn-data@psg.com; Thu, 17 Feb 2005 16:43:19 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1okH-000Okt-Lq for idn@ops.ietf.org; Thu, 17 Feb 2005 16:43:17 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HGgEHb173210; Thu, 17 Feb 2005 11:42:15 -0500 Message-ID: <4214C965.2060503@vanderpoel.org> Date: Thu, 17 Feb 2005 08:42:13 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell CC: William Tan , Michel Suignard , =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <005301c5150e$d6820da0$030aa8c0@DEWELL> In-Reply-To: <005301c5150e$d6820da0$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug Ewell wrote: > * google > * altavista > * yahoo > * m-w > * taco (this one may surprise you) I have another one to add to the list: kazaa. Erik From owner-idn@ops.ietf.org Thu Feb 17 11:50:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21334 for ; Thu, 17 Feb 2005 11:50:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1oo5-000Pe8-Dr for idn-data@psg.com; Thu, 17 Feb 2005 16:47:13 +0000 Received: from [129.171.187.81] (helo=osaka.law.miami.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D1ony-000Pa2-8v for idn@ops.ietf.org; Thu, 17 Feb 2005 16:47:10 +0000 Received: (qmail 21103 invoked by uid 500); 17 Feb 2005 17:53:23 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Feb 2005 17:53:23 -0000 Date: Thu, 17 Feb 2005 12:53:23 -0500 (EST) From: "Michael Froomkin - U.Miami School of Law" X-X-Sender: froomkin@osaka Reply-To: froomkin@law.tm To: Paul Hoffman cc: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering In-Reply-To: Message-ID: References: <20050217095832.GD12777~@nicemice.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Assuming we can't cut ICANN out of the picture, isn't one solution to lobby ICANN to allow for new TLDs with policies that forbid misleading IDNs and let the marketplace sort it out? Maybe the IETF could issue a statement of some sort on the security implications of failing to allow such TLDs into the marketplace? On Thu, 17 Feb 2005, Paul Hoffman wrote: > At 9:58 AM +0000 2/17/05, Adam M. Costello wrote: >> I think registries should be doing filtering, but I don't think browsers >> should depend on it, because it's already too late, as the paypal >> example proves. I think browsers (and in general, applications that >> receive domain names from untrusted sources and display them to the user >> as IDNs) ought to provide a second line of defense by trying to expose >> suspicious domain names. > > I fully agree with Adam here. If there is no way to enforce registries doing > the right thing (and ICANN has shown no ability to enforce nearly anything), > then relying on them for security is silly. This is particularly true if some > registries pay more attention to their customers who want to pay for > mixed-script domain names than they pay to ICANN. > >> > ...assuming we can make the language tag available via some dns tricks >> or >>> some API... >> >> I don't see that happening. The IDN working group decided quite >> deliberately that domain names would not contain any meta-info like >> language tags; they're just text strings. > > Right. If you want to re-engineer the IDN bits-on-the-wire protocol in ways > that were considered and rejected, feel free to submit a new Internet Draft > and see if there is community interest. > >> Still, I expect that some not-terribly-complex heuristics, based only >> on the bare character strings, could go a long way toward exposing >> suspicious domain names. > > Reducing phishing is sufficient because we can never eliminate it. > > --Paul Hoffman, Director > --Internet Mail Consortium > -- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's cool here.<-- From owner-idn@ops.ietf.org Thu Feb 17 11:53:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22147 for ; Thu, 17 Feb 2005 11:53:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1opj-00006L-FT for idn-data@psg.com; Thu, 17 Feb 2005 16:48:55 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1opi-00004b-30 for idn@ops.ietf.org; Thu, 17 Feb 2005 16:48:54 +0000 Received: (qmail 6490 invoked from network); 17 Feb 2005 16:48:52 -0000 Received: from unknown (HELO [80.185.158.173]) (544451@[80.185.158.173]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2005 16:48:52 -0000 Message-ID: <4214CAF3.4000502@v.loewis.de> Date: Thu, 17 Feb 2005 17:48:51 +0100 From: =?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell CC: Erik van der Poel , William Tan , Michel Suignard , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <005301c5150e$d6820da0$030aa8c0@DEWELL> In-Reply-To: <005301c5150e$d6820da0$030aa8c0@DEWELL> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug Ewell wrote: > For each of the following domain names, determine the "intended > language": > > * google > * altavista > * yahoo > * m-w > * taco (this one may surprise you) English. Etymology does not matter as much as scripts in use, for the application under discussion (DNS). Regards, Martin From owner-idn@ops.ietf.org Thu Feb 17 12:34:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01206 for ; Thu, 17 Feb 2005 12:34:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1pSQ-0008sR-5l for idn-data@psg.com; Thu, 17 Feb 2005 17:28:54 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1pSM-0008s7-Vn for idn@ops.ietf.org; Thu, 17 Feb 2005 17:28:51 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HHSSpY129138; Thu, 17 Feb 2005 12:28:33 -0500 Message-ID: <4214D43C.4060007@vanderpoel.org> Date: Thu, 17 Feb 2005 09:28:28 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= CC: Martin Duerst , Michel Suignard , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <4214BF99.9050401@vanderpoel.org> <4214C986.4020801@v.loewis.de> In-Reply-To: <4214C986.4020801@v.loewis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin v. Lwis wrote: > Erik van der Poel wrote: >> StringPrep and NamePrep are great, but I wonder if it might be good to >> take their ideas one step further to solve the IDN spoofing problem. >> I.e. to "normalize" the homographs by mapping the similar-looking >> characters to "base" characters. > > Only by means of blocking registration. A registration can be blocked > not only because it violates static rules, but also because it is > (or could be) a homograph for a different, already registered, label. I think it would be good to consider mapping homographs in the application too. For example, what if a user finds a domain name (or URI) in a magazine and then wants to type that into a Web browser's URI field? The most natural keyboard input language to choose is the user's (main) language. If one of the characters in the domain name is a homograph, then the user might type the "wrong" character, i.e. the wrong character code. She might type Cyrillic small 'a' instead of Latin small 'a'. Wouldn't it then be the responsibility of the browser to map the "wrong" character code to the right one before sending it to a DNS server? Otherwise, DNS would not be able to find the right domain name. Erik From owner-idn@ops.ietf.org Thu Feb 17 12:44:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03641 for ; Thu, 17 Feb 2005 12:44:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1pdX-000BsF-MY for idn-data@psg.com; Thu, 17 Feb 2005 17:40:23 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1pdU-000Brc-6k for idn@ops.ietf.org; Thu, 17 Feb 2005 17:40:20 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D1pdM-0005I8-9t; Thu, 17 Feb 2005 12:40:12 -0500 Date: Thu, 17 Feb 2005 12:40:12 -0500 From: John C Klensin To: froomkin@law.tm, Paul Hoffman cc: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering Message-ID: In-Reply-To: References: <20050217095832.GD12777~@nicemice.net> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 17 February, 2005 12:53 -0500 "Michael Froomkin - U.Miami School of Law" wrote: > Assuming we can't cut ICANN out of the picture, isn't one > solution to lobby ICANN to allow for new TLDs with policies > that forbid misleading IDNs and let the marketplace sort it > out? Michael, "Misleading?" Why should IDNs be any different from ASCII-only labels? "M1CR0S0FT" would certainly be a "misleading" label from the point of view of the obvious company, but the community concluded, long ago, that problem should be dealt with by UDRP procedures or court action, not having some registry make up rules about what can't be registered based on what someone else thinks is "misleading". For the special case of mixed-script labels, ICANN already has guidelines in place that requires gTLDs who choose to register IDNs to limit any given label to a single "language" or small set of languages. Those guidelines are, IMO, badly written and ambiguous and need fixing, but, as far as I know, all of gTLDs except two are conforming to those guidelines and, in particular, not permitting registrations of strings for which they don't have established language tables. The registry for the other two has apparently decided, partially for historical reasons, to go ahead and register almost anything that doesn't match a language for which they already have tables... a topic that has been discussed on this list already. The ccTLDs which have decided to deploy IDNs and who are not bound by those guidelines, have, by and large, adopted registry restriction rules that are intended to prevent mixed-script and other types of IDN-baesd misleading names when feasible. Some of them are based on "characters in use in our territory" and "names we need to be able to represent in order to assure fairness" rules, rather than strict language or script rules, but I suggest they are still within the general intent of preventing misleading mixed-script labels when possible. While policies differ, most of the ccTLDs, and an even larger majority of those operated to support DNS use in the relevant country, are consistent with the general spirit of the ICANN guidelines. Some of us continue to believe, I hope consistently, that conformance based on consensus and conclusions that it is the Right Thing to Do is much better than trying to devise an enforcement regime. I know you didn't suggest an enforcement regime, but others in this discussion have come pretty close. And, for prohibitions on registration of mixed-script misleading names, the worldwide conformance level, among TLDs that have deployed IDNs, to the general principle is fairly high. As far as the marketplace sorting this out, I suggest that the marketplace has already spoken, without any requirement to make up new TLDs to seek a stronger message. We have TLDs (country code and generic) who prohibit IDN registrations. We have TLDs (again, both groups) who permit IDN registrations only if languages are identified and script rules carefully adhered to. And we have TLDs who permit registration of almost anything permitted by IDNA, either explicitly or through some loophole. What I haven't seen, before or after this latest phishing-possibility demonstration, is a single instance of an advertisement or press release that says "you should register in our domain rather than theirs because our permitted-label rules are more restrictive and hence will give you and your users better assurances that they aren't being phished". Nor have we seen any symptoms of registrations migrating spontaneously among domains to reflect those concerns. If the marketplace has any intent of speaking to this issue --or "sorting things out"-- it is doing so in a whisper. I am a little depressed by that. I'd be much happier to see "our domain is safer than their domain" ads and positive responses to them, just as I would have been happy to see "register in our domain because we promise to never try to divert the typing mistakes of your users to your competitors" a year or so ago. But they don't happen. And, using the second case as an example, there is zero evidence that it has had any marketplace effect on registrations. The marketplace for registrations just doesn't seem to care, and we don't need more TLDs to tell us that. > Maybe the IETF could issue a statement of some sort on the > security implications of failing to allow such TLDs into the > marketplace? For the mixed-script case and some related ones, such TLDs are already in the marketplace and are actually the large majority of TLDs. There is a reason why that paypal example didn't show up in AERO, BIZ, CH, CN, DE, INFO, INT, JP, ORG, SE, TW, and a host of others -- it could not have been registered, either because the registry prohibits mixed-script registrations or because it is going slowly about IDN deployment, wanting others to get more experience first. So what would you like the IETF to say, exactly? "Domains that are being cautious about registrations should advertise the fact better"? Not exactly an IETF-type statement. "Guidelines that prevent obvious abuses are good"? The IETF has already said essentially that -- see the "IESG Statement" on IDNs -- and most of the TLD registries are doing it as they deploy IDNs. Or perhaps "200 plus domains are already proceeding safely in this area so security requires that we add a few more who will too"? Doesn't pass the laugh test, at least from where I sit. best, john From owner-idn@ops.ietf.org Thu Feb 17 12:50:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04997 for ; Thu, 17 Feb 2005 12:50:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1pk0-000DTK-3N for idn-data@psg.com; Thu, 17 Feb 2005 17:47:04 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1pjy-000DQA-SG for idn@ops.ietf.org; Thu, 17 Feb 2005 17:47:03 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HHkopY246156; Thu, 17 Feb 2005 12:46:51 -0500 Message-ID: <4214D88A.9000602@vanderpoel.org> Date: Thu, 17 Feb 2005 09:46:50 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Seng CC: ericj@shmoo.com, Michel Suignard , William Tan , idn@ops.ietf.org, tedd , dam@icann.org, "Kane, Pat" , =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= Subject: Re: [idn] homograph attacks References: <4212EF44.4040208@v.loewis.de> <421348F8.9060406@dready.org> <4213B916.8030108@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This does not make sense to me. As the title "Guidelines" suggests, they are merely guidelines for the registries to follow. They are not bound to those rules. Just because ICANN cannot force the registries to follow this guideline does not mean you should just throw the baby out with the bath water and omit a guideline regarding missing character inclusion tables. In networking, it is often better to be conservative. ICANN ought to know this. Also, it would be really nice at this point to hear from, say, VeriSign, that they are seriously considering this issue. We haven't heard from them yet, but they are on this mailing list. Erik James Seng wrote: > I think this suggestion was discussed in the IDN Committee that made the > proposed IDN Guideline but was shot down eventually for being too > restrictive to registries. > > On 17-Feb-05, at AM 05:20, Erik van der Poel wrote: >> >> It seems to me that a registry should not allow the registration of an >> IDN domain name under a particular language if that registry does not >> have a table for that language. From owner-idn@ops.ietf.org Thu Feb 17 13:58:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21111 for ; Thu, 17 Feb 2005 13:58:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1qly-0002yZ-IZ for idn-data@psg.com; Thu, 17 Feb 2005 18:53:10 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1qlt-0002y1-Hk for idn@ops.ietf.org; Thu, 17 Feb 2005 18:53:05 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HIquHb181750; Thu, 17 Feb 2005 13:53:00 -0500 Message-ID: <4214E807.2050802@vanderpoel.org> Date: Thu, 17 Feb 2005 10:52:55 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering References: <20050217095832.GD12777~@nicemice.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > If there is no way to enforce registries > doing the right thing (and ICANN has shown no ability to enforce nearly > anything), then relying on them for security is silly. This is > particularly true if some registries pay more attention to their > customers who want to pay for mixed-script domain names than they pay > to ICANN. Well, it may be that security is not just a technical issue but also, importantly, an economics issue: http://www.cl.cam.ac.uk/users/rja14/econsec.html However, based on private email with a fairly high-ranked individual at VeriSign, I am willing to give them the benefit of the doubt for a while. If they soon state on this mailing list that they intend to put some solution in place to combat the IDN spoofing problem, and then they back up their words with real actions, we're all set (at least for .com :-) >>> ...assuming we can make the language tag available via some dns >>> tricks or some API... >> >> I don't see that happening. The IDN working group decided quite >> deliberately that domain names would not contain any meta-info like >> language tags; they're just text strings. > > Right. If you want to re-engineer the IDN bits-on-the-wire protocol in > ways that were considered and rejected, feel free to submit a new > Internet Draft and see if there is community interest. First, I cannot speak for Eric here, but it seems to me that "DNS tricks" could include having a (new?) DNS record for the language(s). This would not embed the language tag in the domain label itself. The language tag could be looked up in DNS. (However, I don't like this whole language business anyway, as I indicated in other emails.) Second, with all due respect, Paul, Adam et al, stringprep and nameprep are 2 amazing pieces of work, but I feel they did not go far enough. I think it is probably worth exploring whether we might map homographs to "base" characters in a new "prep", perhaps another profile of stringprep, to combat the IDN spoofing problem. Third, there seems to be some resistance to continuing IDN work in the IETF space. So, an Internet Draft may not be appropriate. Michel has indicated that the Unicode Consortium is working on the homograph problem, so maybe we can place our bets there. Alternatively, if some registries (e.g. CJK) wish to have their own rules (i.e. RFC 3743 "JET"), then they can of course do so. I certainly do not want to have a balkanized net, but the degree of balkanization is what matters. I.e. if we only have 2 methods (CJK vs the rest), that's better than having numerous methods. Erik From owner-idn@ops.ietf.org Thu Feb 17 14:17:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23427 for ; Thu, 17 Feb 2005 14:17:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1r6N-0007kP-57 for idn-data@psg.com; Thu, 17 Feb 2005 19:14:15 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1r6L-0007kC-Tc for idn@ops.ietf.org; Thu, 17 Feb 2005 19:14:14 +0000 Received: (qmail 24420 invoked from network); 17 Feb 2005 19:14:13 -0000 Received: from unknown (HELO [80.185.158.173]) (544451@[80.185.158.173]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Feb 2005 19:14:13 -0000 Message-ID: <4214ED02.6000700@v.loewis.de> Date: Thu, 17 Feb 2005 20:14:10 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: Martin Duerst , Michel Suignard , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <4214BF99.9050401@vanderpoel.org> <4214C986.4020801@v.loewis.de> <4214D43C.4060007@vanderpoel.org> In-Reply-To: <4214D43C.4060007@vanderpoel.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > I think it would be good to consider mapping homographs in the > application too. I strongly disagree. First of all, the algorithm used in IDN*A* is already defined, changing it in any way or form will take decades, and likely not happen in our lifetime. > For example, what if a user finds a domain name (or > URI) in a magazine and then wants to type that into a Web browser's URI > field? The most natural keyboard input language to choose is the user's > (main) language. Wrong. The most natural keyboard input in this case is the apparent script of the label. The user should see the script from reading it - in some cases, even just from hearing it spoken. > If one of the characters in the domain name is a > homograph, then the user might type the "wrong" character, i.e. the > wrong character code. She might type Cyrillic small 'a' instead of Latin > small 'a'. By the same reasoning, you might want to map "mikrosovt.com" to "microsoft.com", because the sound of them is the same. > Wouldn't it then be the responsibility of the browser to map the "wrong" > character code to the right one before sending it to a DNS server? Not it all. It is the responsibility of the "system" (including browser and DNS server) to report an error that the domain cannot be found if it is spelled incorrectly. > Otherwise, DNS would not be able to find the right domain name. And that would be a good thing. Regards, Martin From owner-idn@ops.ietf.org Thu Feb 17 14:20:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23818 for ; Thu, 17 Feb 2005 14:20:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1r95-0008a1-Qa for idn-data@psg.com; Thu, 17 Feb 2005 19:17:03 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1r94-0008Zk-PZ for idn@ops.ietf.org; Thu, 17 Feb 2005 19:17:02 +0000 Received: from [10.20.30.249] (dsl2-63-249-109-246.cruzio.com [63.249.109.246]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJGtEs083245; Thu, 17 Feb 2005 11:17:01 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4214E807.2050802@vanderpoel.org> References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> Date: Thu, 17 Feb 2005 11:16:50 -0800 To: Erik van der Poel From: Paul Hoffman Subject: Re: [idn] who should be doing IDN filtering Cc: IETF idn working group Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 10:52 AM -0800 2/17/05, Erik van der Poel wrote: >>>>...assuming we can make the language tag available via some dns >>>>tricks or some API... >>> >>>I don't see that happening. The IDN working group decided quite >>>deliberately that domain names would not contain any meta-info like >>>language tags; they're just text strings. >> >>Right. If you want to re-engineer the IDN bits-on-the-wire protocol >>in ways that were considered and rejected, feel free to submit a >>new Internet Draft and see if there is community interest. > >First, I cannot speak for Eric here, but it seems to me that "DNS >tricks" could include having a (new?) DNS record for the >language(s). This would not embed the language tag in the domain >label itself. The language tag could be looked up in DNS. (However, >I don't like this whole language business anyway, as I indicated in >other emails.) I will say it again: put together a fully-formed proposal. Suggesting anything that requires understand of the DNS beyond simple A records needs and Internet Draft or at least a stable web page. Few people on this mailing list (myself included) are facile with alternate DNS records and the like. >Second, with all due respect, Paul, Adam et al, stringprep and >nameprep are 2 amazing pieces of work, but I feel they did not go >far enough. I think it is probably worth exploring whether we might >map homographs to "base" characters in a new "prep", perhaps another >profile of stringprep, to combat the IDN spoofing problem. The IDN WG did explore that, in depth; it's all in the archives. You may disagree with the conclusion, but please don't minimize the difficult decision-making that went into the protocol design and development. >Third, there seems to be some resistance to continuing IDN work in >the IETF space. Correct. Without some indication of what the work is, how it relates to current protocols, and who will do it, there is resistance. If those three are made clear, the IETF could be much more interested. The same is true for any standards organization. > So, an Internet Draft may not be appropriate. Internet Drafts are always appropriate, even if the work is being done somewhere else. They give a single place to look for the latest version. Yes, they have formatting and can't-always-publish issues, but they usually work well. > Michel has indicated that the Unicode Consortium is working on the >homograph problem, so maybe we can place our bets there. They are working on specifying the problem and listing some proposed solutions. They are not working on protocol changes. >Alternatively, if some registries (e.g. CJK) wish to have their own >rules (i.e. RFC 3743 "JET"), then they can of course do so. I >certainly do not want to have a balkanized net, but the degree of >balkanization is what matters. I.e. if we only have 2 methods (CJK >vs the rest), that's better than having numerous methods. Many people spent a lot of work trying to get coordination and/or cooperation for creating those lists. So far, the results have been less than stellar. The cultural imperatives and political exigencies make that work very, very difficult despite all the good effort. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 17 14:54:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26997 for ; Thu, 17 Feb 2005 14:54:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1rfa-000Ftf-Dz for idn-data@psg.com; Thu, 17 Feb 2005 19:50:38 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1rfX-000FtD-RG for idn@ops.ietf.org; Thu, 17 Feb 2005 19:50:36 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D1rfQ-0006Md-Mk; Thu, 17 Feb 2005 14:50:28 -0500 Date: Thu, 17 Feb 2005 14:50:17 -0500 From: John C Klensin To: Paul Hoffman , Erik van der Poel cc: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering Message-ID: In-Reply-To: References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 17 February, 2005 11:16 -0800 Paul Hoffman wrote: >> Alternatively, if some registries (e.g. CJK) wish to have >> their own rules (i.e. RFC 3743 "JET"), then they can of >> course do so. I certainly do not want to have a balkanized >> net, but the degree of balkanization is what matters. I.e. >> if we only have 2 methods (CJK vs the rest), that's better >> than having numerous methods. > > Many people spent a lot of work trying to get coordination > and/or cooperation for creating those lists. So far, the > results have been less than stellar. The cultural imperatives > and political exigencies make that work very, very difficult > despite all the good effort. Erik, Let me agree with Paul here (!), especially about the cultural imperatives and political expediencies. But I think your comment about "numerous methods" deserves some additional response. Let me try to put the JET work, draft-klensin-reg-guidelines, the ICANN guidelines, and a few other registration-side efforts in perspective. Registries have always (since long before IDNs and, for the old host tables, even before the DNS) been able to say "there are names that we will not permit to be registered here" and/or "there are entities we will not permit to register here" and/or "that entity can register, but only with one of these names". Beyond enforcement of the "hostname" (or "LDH") rule --neither of which is "English" but which is, itself, a registration restriction, there has been no uniformity among domains about what those rules are and how vigorously they are enforced. We've seen rules about length that are more restrictive than the DNS limit, rules about national presence, rules about registration only of names that appear in national business registers, rules about prohibited "nasty" words, and so on for a very long list. That isn't just about TLDs: I've got biases about names in jck.com, and I enforce them... and so do a rather large fraction of the enterprise and other domain administrators in the world whose domains consist of labels for more than a couple of hosts or functions. None of these rules or conventions causes any interoperability (or balkanization) issues at all: a resolver either finds the name or doesn't, and is indifferent to whether a name that is not found isn't there because no one wanted to register it or because they were prohibited from doing so. We would have interoperability issues if someone tried to change the resolution rules themselves: a local (and different) version of the IDNA tables that would map a UTF-8-encoded Unicode string to a different punycode string than is called for by the IDNA and nameprep specs would be very bad news indeed. So would installing a DNS server that would use a set of lookup and matching rules different from those required by 1034/1035. But people rarely propose such things and, so far, we have been fairly successful at talking them out of it when they do... precisely because such actions would balkanize the network. So, in general, having different sets of registry restriction rules in different registries, even unique rules for each registry, are not a problem. Having individual applications programs, such as browsers, guess what those rules are for a given domain is, by contrast, a nightmare. While warning the user when certain types of anomalies are detected makes a lot of sense, any sort of "bad name" restriction on a name that is IDNA-conformant would be really bad news, going far beyond the messes I tried to warn about in RFC 3696. There are two groups of folks for whom different restrictions in different registries are a problem. They involve registrants who want to register the same name in many domains and the registrars who need to deal with them (and with those domains). For the former, the fact that a name may be acceptable in some domains and not others is tough luck. It has always been tough luck: IDNs may expand the number of possible reasons for rejection, but they don't introduce any new problem. For the registrars, one level of service involves trying to understand what all the rules are for any domain they support. That is tough, but not impossible. Another level involves just sending a proposed name in and seeing if it is accepted. They are, for most domains, in a very competitive environment; the marketplace will presumably sort out the best combination of service levels and pricing. The one piece of that issue that is an IETF story is that we should try to design registrar-registry communications protocols to deliver good information back to the registrar as to why a particular proposed name is being rejected. My impression is that we are doing that reasonably well but that we should keep looking for ways to improve things while keeping them general. But, again, no interoperability or balkanization problems here unless someone starts making changes to the resolution or matching protocols or models. john From owner-idn@ops.ietf.org Thu Feb 17 16:48:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09557 for ; Thu, 17 Feb 2005 16:48:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1tOZ-000EYS-DU for idn-data@psg.com; Thu, 17 Feb 2005 21:41:11 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1tOY-000EY9-6v for idn@ops.ietf.org; Thu, 17 Feb 2005 21:41:10 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1HLetuq364190; Thu, 17 Feb 2005 16:40:59 -0500 Message-ID: <42150F66.4070900@vanderpoel.org> Date: Thu, 17 Feb 2005 13:40:54 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: Paul Hoffman , IETF idn working group Subject: Re: [idn] who should be doing IDN filtering References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > > None of these rules or conventions causes any interoperability > (or balkanization) issues at all: a resolver either finds the > name or doesn't, and is indifferent to whether a name that is > not found isn't there because no one wanted to register it or > because they were prohibited from doing so. Yes, but as a browser developer, I *would* care about whether a user was able to easily type in a domain name and go where s/he wanted to go. In the presence of these homograph problems, a browser developer might even want to retry DNS lookups with different character codes until it succeeded. We can't just foist these solvable problems on the end-user. > We would have interoperability issues if someone tried to change > the resolution rules themselves: a local (and different) version > of the IDNA tables that would map a UTF-8-encoded Unicode string > to a different punycode string than is called for by the IDNA > and nameprep specs would be very bad news indeed. You could use a prefix other than xn-- to migrate from the old to the new. I jotted down a few quick ideas here: http://lists.w3.org/Archives/Public/www-international/2005JanMar/0101.html However, if I can't get support from the major organizations such as Microsoft, VeriSign and the Unicode Consortium (either because too many xn-- names have already been registered and the migration would not be practical or for some other reason), then I might just give up on this idea. But I'm willing to explore it some more. > Having individual applications > programs, such as browsers, guess what those rules are for a > given domain is, by contrast, a nightmare. As a browser developer, I would not try to "guess" what those rules are. I would read them and try to implement them correctly. > any sort of "bad name" restriction on a name that is > IDNA-conformant would be really bad news, going far beyond the > messes I tried to warn about in RFC 3696. Gotta go right now. I'll read that later. Erik From owner-idn@ops.ietf.org Thu Feb 17 20:11:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05303 for ; Thu, 17 Feb 2005 20:11:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1wag-000AUB-UX for idn-data@psg.com; Fri, 18 Feb 2005 01:05:54 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1waf-000ATp-RK for idn@ops.ietf.org; Fri, 18 Feb 2005 01:05:54 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1I15POB163216; Thu, 17 Feb 2005 20:05:30 -0500 Message-ID: <42153F55.2080501@vanderpoel.org> Date: Thu, 17 Feb 2005 17:05:25 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= CC: Martin Duerst , Michel Suignard , William Tan , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org Subject: Re: [idn] homograph attacks References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <4214BF99.9050401@vanderpoel.org> <4214C986.4020801@v.loewis.de> <4214D43C.4060007@vanderpoel.org> <4214ED02.6000700@v.loewis.de> In-Reply-To: <4214ED02.6000700@v.loewis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin v. Lwis wrote: > The most natural keyboard input in this case is the apparent > script of the label. The user should see the script from reading > it OK, I see. Thanks for taking the time to respond. Erik From owner-idn@ops.ietf.org Thu Feb 17 22:14:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17129 for ; Thu, 17 Feb 2005 22:14:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1yUw-000EtB-Cb for idn-data@psg.com; Fri, 18 Feb 2005 03:08:06 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1yUu-000Esq-RP for idn@ops.ietf.org; Fri, 18 Feb 2005 03:08:05 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1I37xHb110572; Thu, 17 Feb 2005 22:07:59 -0500 Message-ID: <42155C0E.7050000@vanderpoel.org> Date: Thu, 17 Feb 2005 19:07:58 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: IETF idn working group Subject: Re: [idn] who should be doing IDN filtering References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>>>> ...assuming we can make the language tag available via some dns >>>>> tricks or some API... >>>> >>>> I don't see that happening. The IDN working group decided quite >>>> deliberately that domain names would not contain any meta-info like >>>> language tags; they're just text strings. >>> >>> Right. If you want to re-engineer the IDN bits-on-the-wire protocol >>> in ways that were considered and rejected, feel free to submit a new >>> Internet Draft and see if there is community interest. >> >> First, I cannot speak for Eric here, but it seems to me that "DNS >> tricks" could include having a (new?) DNS record for the language(s). >> This would not embed the language tag in the domain label itself. The >> language tag could be looked up in DNS. (However, I don't like this >> whole language business anyway, as I indicated in other emails.) > > I will say it again: put together a fully-formed proposal. Suggesting > anything that requires understand of the DNS beyond simple A records > needs and Internet Draft or at least a stable web page. Few people on > this mailing list (myself included) are facile with alternate DNS > records and the like. Actually, I'm not interested in such a DNS record. I was merely trying to point out that Eric's original phrase "dns tricks" could be interpreted differently (i.e. different from Adam's and your interpretation). Maybe Eric could clarify his original email (if he wishes to do so). >> Second, with all due respect, Paul, Adam et al, stringprep and >> nameprep are 2 amazing pieces of work, but I feel they did not go far >> enough. I think it is probably worth exploring whether we might map >> homographs to "base" characters in a new "prep", perhaps another >> profile of stringprep, to combat the IDN spoofing problem. > > The IDN WG did explore that, in depth; it's all in the archives. You may > disagree with the conclusion, but please don't minimize the difficult > decision-making that went into the protocol design and development. It sounds like I upset you (and/or other people), and I'm sorry. >> Third, there seems to be some resistance to continuing IDN work in the >> IETF space. > > Correct. Without some indication of what the work is, how it relates to > current protocols, and who will do it, there is resistance. If those > three are made clear, the IETF could be much more interested. The same > is true for any standards organization. When I first read this a few hours ago, I thought you were slamming the door shut on me, but on closer reading, it seems that that is not the case. >> Alternatively, if some registries (e.g. CJK) wish to have their own >> rules (i.e. RFC 3743 "JET"), then they can of course do so. I >> certainly do not want to have a balkanized net, but the degree of >> balkanization is what matters. I.e. if we only have 2 methods (CJK vs >> the rest), that's better than having numerous methods. > > Many people spent a lot of work trying to get coordination and/or > cooperation for creating those lists. So far, the results have been less > than stellar. The cultural imperatives and political exigencies make > that work very, very difficult despite all the good effort. Here again I must apologize to all the parties concerned. My comments were insensitive, and I hope not to repeat this mistake. Erik From owner-idn@ops.ietf.org Thu Feb 17 22:32:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18419 for ; Thu, 17 Feb 2005 22:32:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1yox-000KAy-2R for idn-data@psg.com; Fri, 18 Feb 2005 03:28:47 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1yow-000KAd-5t for idn@ops.ietf.org; Fri, 18 Feb 2005 03:28:46 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 5B1814F227; Thu, 17 Feb 2005 22:28:41 -0500 (EST) Message-Id: <6.0.0.20.2.20050218113553.08077390@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Feb 2005 11:40:01 +0900 To: Erik van der Poel , William Tan From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: Michel Suignard , =?ISO-2022-JP?B?Ik1hcnRpbiB2LiBMGyRCi1gbKEJpcyI=?= , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu In-Reply-To: <4214C445.9070106@vanderpoel.org> References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01:20 05/02/18, Erik van der Poel wrote: >William Tan wrote: >So it is not really fair to the IDN registrants to require them to state what language or set of languages their domain name is intended to be in, since DNS has not previously imposed such a restriction, and a lot of domain names have already been registered under this relaxed convention. Very much agreed. Except for registries with very special policies (such as the blocking used by some East Asian registries), the language association doesn't make too much sense. Immagine that a gTLD registry had a few hundred language tables, and immagine that a registrant wanted to register a particular sequence of characters. It would be very easy for a registrar to set up a service that figured out a language (don't care which) that worked, and register the name with that language. Regards, Martin. From owner-idn@ops.ietf.org Thu Feb 17 22:33:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18437 for ; Thu, 17 Feb 2005 22:33:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D1yor-000K9d-Qt for idn-data@psg.com; Fri, 18 Feb 2005 03:28:41 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D1yoq-000K9Q-Qw for idn@ops.ietf.org; Fri, 18 Feb 2005 03:28:41 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 3C4E24F19F; Thu, 17 Feb 2005 22:28:38 -0500 (EST) Message-Id: <6.0.0.20.2.20050218085508.0807a9f0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Feb 2005 11:52:43 +0900 To: Erik van der Poel , John C Klensin From: Martin Duerst Subject: Re: [idn] who should be doing IDN filtering Cc: Paul Hoffman , IETF idn working group In-Reply-To: <42150F66.4070900@vanderpoel.org> References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> <42150F66.4070900@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello Eric, At 06:40 05/02/18, Erik van der Poel wrote: >Yes, but as a browser developer, I *would* care about whether a user was able to easily type in a domain name and go where s/he wanted to go. In the presence of these homograph problems, a browser developer might even want to retry DNS lookups with different character codes until it succeeded. We can't just foist these solvable problems on the end-user. As a browser developer, you don't even have to care too much about ease of typing, above and beyond making sure that the user can use the input facilities provided by the OS and Windowing system,... in the usual way. The rest will be taken care by registrants, they'll figure out sooner or later what names are easy to type and what names are not easy to type. It has worked quite well for the ASCII-only DNS. >You could use a prefix other than xn-- to migrate from the old to the new. I jotted down a few quick ideas here: > >http://lists.w3.org/Archives/Public/www-international/2005JanMar/0101.html > >However, if I can't get support from the major organizations such as Microsoft, VeriSign and the Unicode Consortium (either because too many xn-- names have already been registered and the migration would not be practical or for some other reason), then I might just give up on this idea. But I'm willing to explore it some more. [rethorical question:] Are we also going to deal with those cases in US-ASCII that can be confusing now? Later, Martin v. Loevis wrote: >The most natural keyboard input in this case is the apparent >script of the label. The user should see the script from reading >it Yes. And some labels where the script isn't clear enough might not get registered by honest folks because they want users to understand how to type things, rather than to worry what script to use. An alternative may of course be registering in both scripts. [the number of cases that this applies are probably not large, I'm mainly thinking about short words or company names/acronyms in Russian and similar places] Regards, Martin. From owner-idn@ops.ietf.org Fri Feb 18 00:59:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00836 for ; Fri, 18 Feb 2005 00:59:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D215p-0003cL-Gr for idn-data@psg.com; Fri, 18 Feb 2005 05:54:21 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D215o-0003c7-ER for idn@ops.ietf.org; Fri, 18 Feb 2005 05:54:20 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id E3FB14EFFD; Fri, 18 Feb 2005 00:54:18 -0500 (EST) Message-Id: <6.0.0.20.2.20050218082023.03685a70@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Feb 2005 14:21:29 +0900 To: James Seng From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: idn@ops.ietf.org In-Reply-To: References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <621f441a8986e71ed205761e0a6e7df1@seng.cc> <6.0.0.20.2.20050217213605.06d1c3d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello James, Many thanks for your private answer. I'd preferred to have this discussion in some public forum, so please feel free to forward this to one of the lists where I'm involved. At 02:53 05/02/18, James Seng wrote: >when we do idn, we talk about unicode and scripts. afterall, unicode is a script based encoding so it is silly to think in language. Very good point. >but when you deal with end-users, lay-person who wants their idn, they thinking of names. they want names in their own languages. script? what's the different. They want the names in their own characters. Some, maybe quite a lot, of users may think about it in terms of language, but there is no need to stress the language aspect more than necessary. Also, if the average user gets that policy, but Verisign doesn't, that's much more damaging than the other way round. >that's the gap between the two. that's why in rfc3743, we talk about how to do chinese idn, japanese idn and korean idn and not han ideograph idn. For rfc3743, that's fine, because that's dealing with language and using language to address problems. Or actually, to be more precise, it's not fine, because the main concern of rfc3743 isn't maybe so much necessarily language as different ways to write the same language. Simplified and traditional Chinese are not two different languages, at least as I understand. Another problem is that in different parts of the world, the issues are diffenent. Switzerland is a good example, they didn't publish a German table, a French table, and so on, for very good reasons. It shouldn't look like they violate the ICANN policy, but at the moment, it does look like they violate the policy because of the way the policy is written. If that's by design, it's bad design. I'm not asking to remove all instances of 'language' from that policy, but having 'language' 19 times and 'script' 0 times in that document gives completely the wrong impression. Regards, Martin. >james > >On 17-Feb-05, at PM 08:39, Martin Duerst wrote: > >> Hello James, >> >> If using 'language' only, and never mentioning 'script', >> is by design, then would you mind pointing me to that >> design, or explaining it to me? >> >> Regards, Martin. >> >> >> At 19:05 05/02/17, James Seng wrote: >> >the choice of words of using language (instead of script) in ICANN community is by design. >> > >> >james >> > >> >On 17-Feb-05, at PM 04:55, Martin Duerst wrote: >> > >> >> At 14:06 05/02/17, Erik van der Poel wrote: >> >> >Michel Suignard wrote: >> >> >> It is much more challenging for a worlwide TLD such as .com to >> >> >> establish registration rules. Typically script is a much better >> >> >> selector than language to establish those tables and associated >> >> >> rules. >> >> > >> >> >"Typically"? You make it sound like you've "been there, done that". :-) >> >> > >> >> >Seriously, would you please elaborate on your ideas for .com? I would really like to know what you have in mind, specifically, to combat the homograph problem. >> >> >> >> Hello Eric, >> >> >> >> I can't answer fro Michel. But I just had a look at the ICANN guidelines, >> >> and they use the word 'language' 19 times (hope I counted correctly), >> >> and the word 'script' not a single time. >> >> >> >> However, there are at least as much 'script' aspects as there are >> >> 'language' aspects in the current problem, and if you look at actual >> >> implementation in ccTLD registries that have deployed IDNs, it's >> >> also quite a bit about 'script'. As an example, .ch has published >> >> a single table although they are very clearly working with three >> >> or four languages. >> >> >> >> Too much emphasis on 'language' rather than 'script' also has lead >> >> to strange claims such as that creating IDN TLDs is impossible >> >> because we cannot create 6000 versions of .com. Again, looking >> >> at this as a script problem is much more appropriate, after >> >> all, neither "com" nor any ccTLD nor most of the gTLDs are >> >> associated with any single language. >> >> >> >> Regards, Martin. >> >> >> > >> > From owner-idn@ops.ietf.org Fri Feb 18 00:59:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00870 for ; Fri, 18 Feb 2005 00:59:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D215s-0003cs-8M for idn-data@psg.com; Fri, 18 Feb 2005 05:54:24 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D215r-0003ce-Bc for idn@ops.ietf.org; Fri, 18 Feb 2005 05:54:23 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 045284F22D; Fri, 18 Feb 2005 00:54:20 -0500 (EST) Message-Id: <6.0.0.20.2.20050218114103.07454200@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Fri, 18 Feb 2005 14:53:30 +0900 To: =?ISO-2022-JP?B?Ik1hcnRpbiB2LiBMGyRCi1gbKEJpcyI=?= From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: "JFC (Jefsey) Morfin" , "Kane, Pat" , idn@ops.ietf.org In-Reply-To: <4214C8AF.3070708@v.loewis.de> References: <6.1.2.0.2.20050216143507.030d1cd0@mail.jefsey.com> <4213BDB5.5070700@v.loewis.de> <6.0.0.20.2.20050217090918.0360fda0@localhost> <4214C8AF.3070708@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 01:39 05/02/18, Martin v. L$BX(Bis wrote: >Martin Duerst wrote: >> >I don't see how this is relevant for this discussion. If the .com >> >registrar decides to use a subset of 639 only, I consider this a valid >> >choice. No need to register any language tag with IANA; all tags >> >you ever want to use are already there. >> Not exactly correct. For cases like Serbian, Azerbaijani, Tajik, >> which can be written with different scripts, you need more than >> ISO 639. > >Please read my statement again. *If* the registrar decides to use >a subset of 639 only, *then* all tags you ever want to use are >already there. Sorry, but that reading of the sentence was too trivial for me to consider it. >Now, the question is how the registrar deals with 639 languages >that use multiple scripts. There are two obvious options: >1. all characters in any of the scripts of the language can be > allowed in a domain label (allowing for unintended homographic > labels) >2. the characters of the language are separated into disjoint > scripts, and each label registered for a language is required > to fall into one script. > >There are other options as well, of course: the registrar could >try to block labels in other scripts than the registered one, >if they are transliterations of each other. For example, for >Tajik, it might be sensible to block a Latin label if the >equivalent Cyrillic one has been registered. Yes, that's more or less the choices they have. (1) is the dangerous one, (2) is the easy one, and your transliteration example may be easy or hard depending on the language. Regards, Martin. From owner-idn@ops.ietf.org Fri Feb 18 03:27:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04549 for ; Fri, 18 Feb 2005 03:27:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D23O4-000E7h-Aj for idn-data@psg.com; Fri, 18 Feb 2005 08:21:20 +0000 Received: from [80.67.18.14] (helo=smtprelay02.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D23O2-000E6g-C1 for idn@ops.ietf.org; Fri, 18 Feb 2005 08:21:18 +0000 Received: (qmail 22835 invoked from network); 18 Feb 2005 08:21:11 -0000 Received: from unknown (HELO [80.185.145.46]) (544451@[80.185.145.46]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Feb 2005 08:21:11 -0000 Message-ID: <4215A572.3050903@v.loewis.de> Date: Fri, 18 Feb 2005 09:21:06 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> In-Reply-To: <6.0.0.20.2.20050218113553.08077390@localhost> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Martin Duerst wrote: > Very much agreed. Except for registries with very special > policies (such as the blocking used by some East Asian > registries), the language association doesn't make too > much sense. > > Immagine that a gTLD registry had a few hundred language tables, > and immagine that a registrant wanted to register a particular > sequence of characters. It would be very easy for a registrar > to set up a service that figured out a language (don't care > which) that worked, and register the name with that language. However, as the East Asian languages might cause blocking, every .COM user is required to provide a language tag. So in that sense, every gTLD will have very special policies. Regards, Martin From owner-idn@ops.ietf.org Fri Feb 18 06:43:54 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21351 for ; Fri, 18 Feb 2005 06:43:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D26SI-0007hO-0w for idn-data@psg.com; Fri, 18 Feb 2005 11:37:54 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D26Rz-0007g0-Re for idn@ops.ietf.org; Fri, 18 Feb 2005 11:37:36 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IBbPuq035830; Fri, 18 Feb 2005 06:37:30 -0500 Message-ID: <4215D375.3080206@vanderpoel.org> Date: Fri, 18 Feb 2005 03:37:25 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= CC: Martin Duerst , idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> <4215A572.3050903@v.loewis.de> In-Reply-To: <4215A572.3050903@v.loewis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin v. Lwis wrote: > Martin Duerst wrote: >> Very much agreed. Except for registries with very special >> policies (such as the blocking used by some East Asian >> registries), the language association doesn't make too >> much sense. > > However, as the East Asian languages might cause blocking, > every .COM user is required to provide a language tag. So > in that sense, every gTLD will have very special policies. The .com and .net domains are operated by VeriSign: http://icann.org/faq/#regrules VeriSign appears to have adopted the Chinese blocking: http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_002087.html Do you know whether any of the other gTLDs have adopted the Chinese blocking? Also, does any registry have blocking for any languages other than Chinese? Thanks, Erik From owner-idn@ops.ietf.org Fri Feb 18 08:48:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02526 for ; Fri, 18 Feb 2005 08:48:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D28OH-0009Q1-A3 for idn-data@psg.com; Fri, 18 Feb 2005 13:41:53 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D28OB-0009Ox-Vy for idn@ops.ietf.org; Fri, 18 Feb 2005 13:41:48 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IDfjuq428776; Fri, 18 Feb 2005 08:41:46 -0500 Message-ID: <4215F099.9020002@vanderpoel.org> Date: Fri, 18 Feb 2005 05:41:45 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: unicode@unicode.org, idn@ops.ietf.org Subject: [idn] IDN spoofing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, This email is being sent to both the Unicode and IDN mailing lists. I'm wondering how we can move forward with the IDN spoofing issue. Let me take a stab at it. Regarding the proposal to unify (or map) all the homographs, Doug Ewell wrote a humorous email illustrating how difficult such an effort would be: http://ops.ietf.org/lists/idn/idn.2002/msg00498.html John Klensin says that a "one label, one language" rule has been suggested to combat look-alike confusion. See section 1.5.1 in: http://www.ietf.org/internet-drafts/draft-klensin-reg-guidelines-06.txt Indeed, this label-based idea makes sense because DNS is administratively divided into labels. For example, the .com operator might be able to impose some restrictions on the 2nd level domain label, but if someone registers foo.com, then it's up to them to decide what will be allowed at the 3rd level (e.g. bar.foo.com). No? Recent discussion on the IDN mailing list has suggested that we might want to think more in terms of *script* than language. However, I note that there is a very diverse history of mixing scripts: http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_mixing.html But do we really need to allow for such rich script mixing in DNS? Some of the script mixing described in the document above is scholarly transliteration or "one-offs". So, instead, I propose that we start thinking of a "one label, one writing system" rule. The Unicode book defines "writing system" as "a set of rules for using one or more scripts to write a particular language". This makes a lot of sense for some of the ccTLDs. For example, the .jp domain could choose to allow the Japanese writing system in the 2nd level domain label. But what can we do about .com? It's clearly a worldwide TLD now. It should probably allow multiple writing systems. Perhaps the .com operator could specify that 2nd level domain labels must stick to one writing system, and that that writing system must be indicated in the RRP (Registry Registrar Protocol) in order to validate the 2nd level name against the table of characters allowed in that writing system. This would probably require a (new?) set of names for writing systems, somewhat similar to the language tags of ISO 639. Some people might point out that it is unfair to impose a writing system rule on domain labels since DNS has not had such restrictions in the past. Or has it? The DNS spec itself may allow various octet values, but the infrastructure and conventions appear to be restricted to some of the ASCII characters, which I guess you could just call the English writing system, no? Also, I'm guessing that any "one label, one writing system" rule cannot really be mandated, since TLD operators have historically been free to do whatever they want, to make as much money as they want. So this rule would just be a guideline (Klensin's document is titled "Suggested Practices ...") and the TLD operators could follow it, if they wish to combat the IDN spoofing problem more than they wish to make money (in the short term :-) Erik From owner-idn@ops.ietf.org Fri Feb 18 09:42:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07666 for ; Fri, 18 Feb 2005 09:42:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29G6-000Mmq-KM for idn-data@psg.com; Fri, 18 Feb 2005 14:37:30 +0000 Received: from [61.197.89.106] (helo=atreuscorp.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29Fg-000MkL-Kf for idn@ops.ietf.org; Fri, 18 Feb 2005 14:37:04 +0000 Received: from edmontr3 ([172.16.0.235]) by atreuscorp.com (8.9.3/8.9.3) with SMTP id BAA28917; Sat, 19 Feb 2005 01:19:26 +0900 Message-ID: <00b401c515c7$457f6820$eb0010ac@edmontr3> From: "Edmon Chung" To: "Erik van der Poel" , , References: <4215F099.9020002@vanderpoel.org> Subject: Re: [idn] IDN spoofing Date: Fri, 18 Feb 2005 09:35:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,MIME_BASE64_BLANKS, MIME_BASE64_TEXT,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVyaWsgdmFuIGRlciBQb2Vs IiA8ZXJpa0B2YW5kZXJwb2VsLm9yZz4NCj4gU28sIGluc3RlYWQsIEkgcHJvcG9zZSB0aGF0IHdl IHN0YXJ0IHRoaW5raW5nIG9mIGEgIm9uZSBsYWJlbCwgb25lIA0KPiB3cml0aW5nIHN5c3RlbSIg cnVsZS4gVGhlIFVuaWNvZGUgYm9vayBkZWZpbmVzICJ3cml0aW5nIHN5c3RlbSIgYXMgImEgDQo+ IHNldCBvZiBydWxlcyBmb3IgdXNpbmcgb25lIG9yIG1vcmUgc2NyaXB0cyB0byB3cml0ZSBhIHBh cnRpY3VsYXIgbGFuZ3VhZ2UiLg0KDQpUaGlzIGlzIGFuIGludGVyc3RpbmcgaWRlYS4gIEJhc2Vk IG9uIHRoZSBVbmljb2RlIGJvb2sgdGhvdWdoLCB0aGVyZSBhcmUgNiBkZWZpbmVkICJ3cml0aW5n IHN5c3RlbXMiDQotIEFscGhhYmV0cyAoZS5nLiBMYXRpbiwgR3JlZWssIEN5cmlsbGljLCBBcm1l bmlhbiwgZXRjLikNCi0gQWJqYWRzIChlLmcuIEhlYnJldywgQXJhYmljLCBTeXJpYWMpDQotIEFi dWdpZGFzIChlLmcuIERldmFuYWdhcmksIEJlbmdhbGksIEd1cm11a2hpLCBHdWphcmF0aSwgZXRj LikNCi0gTG9nb3N5bGxhYmFyaWVzIChlLmcuIEhhbikNCi0gU2ltcGxlIFN5bGxhYmFyaWVzIChl LmcuIENoZXJva2VlLCBIaXJhZ2FuYSwgS2F0YWthbmEsIEJvcG9tb2ZvLCBldGMuKQ0KLSBGZWF0 dXJhbCBTeWxsYWJhcmllcyAoZS5nLiBFdGhpb3BpYywgQ2FuYWRpYW4gQWJvcmlnaW5hbCBTeWxs YWJpY3MsIEhhbmd1bCkNCg0KQW5kIHVuZGVyIHRoZSA2IHdyaXRpbmcgc3lzdGVtcyBhcmUgZGlm ZmVyZW50ICJzY3JpcHRzIi4gIEl0IGlzIG5vdCBkaWZmaWN1bHQsIEkgc3VwcG9zZSwgdG8gdHJ5 IHRvIGltYWdpbmUgImZpdHRpbmciIHRoZSBwaHJhc2UgaW50byBhICJsYW5ndWFnZSIgY29udGV4 dCAoaS5lLiBhcyB3aGF0IHlvdSBoYXZlIGRlc2NyaWJlZCBhcyBhICJKYXBhbmVzZSB3cml0aW5n IHN5c3RlbSIpLCBidXQgSSBkbyBub3QgaGF2ZSBlbm91Z2ggZXhwZXJ0aXNlIHRvIHNheSB3aGV0 aGVyIHRoYXQgaXMgYSBnb29kIGlkZWEgb3Igd2hldGhlciBpdCB3b3VsZCBpbnZpdGUgb3RoZXIg Y29uZnVzaW9ucyBhbmQgb2JqZWN0aW9ucy4NCg0KUmF0aGVyIHRoYW4gdHJ5aW5nIHRvICJmaXQi IGFuIGV4aXN0aW5nIHBocmFzZSBpbnRvIHRoZSBjb250ZXh0IG9mIElETiwgcGVyaGFwcyBpdCBt YXkgYmUgYmV0dGVyIHRvIGp1c3QgaW52ZW50IGEgY29udmVudGlvbiB0byBkZXNjcmliZSB3aGF0 IGlzIGFjdHVhbGx5IGhhcHBlbmluZyBhbmQgcGxhdXNpYmxlIGdpdmVuIHByZWNpc2VseSB0aGUg RE5TIGNvbnRleHQuDQoNClRoYXQgaXMsIHJhdGhlciB0aGFuIHRyeWluZyB0byB1c2UgdGhlIHdv cmRzICJsYW5ndWFnZSIgb3IgIndyaXRpbmcgc3lzdGVtIiBvciAic2NyaXB0IiB3aGljaCBpbnZp dGVzIGNvbnRlbnRpb24sIHdoeSBub3QganVzdCBzYXkgdGhhdCBlYWNoIHJlZ2lzdGVyZWQgSURO IExhYmVsIHNob3VsZCBoYXZlIGFuIGFzc29jaWF0ZWQgIklETi1UYWciLiAgQW5kIGFuICJJRE4t VGFnIiBpcyBkZWZpbmVkIGJ5IGEgZG9tYWluIHJlZ2lzdHJ5IGFuZCBlbmNvbXBhc3NlcyBhIHBv bGljeSBwcm9maWxlIHRoYXQgaXMgZGV2ZWxvcGVkIGJ5IGEgbG9jYWwgLyBsaW5ndXNpdGljIGF1 dGhvcml0eSB3aXRoIHJ1bGVzIHJlbGV2YW50IGZvciBJRE4gdXNlLiAgVGhpcyBjb3VsZCBpbmNs dWRlIDMgZ2VuZXJhbCB0eXBlcyBvZiB0aGluZ3M6DQoxLiB0aGUgY29sbGVjdGlvbi9saXN0IG9m IHZhbGlkIGNoYXJhY3RlcnMvY29kZXBvaW50czsNCjIuIHNvbWUgY29udGV4dHVhbCBydWxlcyAo aWYgYXBwbGljYWJsZSk7IGFuZCwNCjMuIGNvbnNpZGVyYXRpb25zIGZvciB2YXJpYW50IHByZXBh cmF0aW9ucy9yZXNlcnZhdGlvbnMgKGlmIGFwcGxpY2FibGUpLg0KKG1heWJlIG1vcmUgdGhhbiAz IHdvdWxkIGJlIGFwcHJvcHJpYXRlLCBJIGFtIGp1c3Qgc3VnZ2VzdGluZyB0aGVzZSBhcyBhIHN0 YXJ0ZXIpDQoNClRvZGF5LCBmb3IgZXhhbXBsZSwgdGhlIC5KUCByZWdpc3RyeSBoYXMgY3JlYXRl ZCBpdHMgSmFwYW5lc2UgcG9saWN5IHByb2ZpbGUgd2l0aCBhIGxpc3Qgb2YgdmFsaWQgY2hhcmFj dGVycyAod2hpY2ggaW5jbHVkZXMga2FuamksIHRoZSBrYW5hJ3MgYW5kIExESCkgd2l0aCBhIGNv dXBsZSBvZiBjb250ZXh0dWFsIHJ1bGVzIChtYXggbGVuZ3RoIG9mIGRvbWFpbiBpcyAxNSBuYXRp dmUgY2hhcmFjdGVycyBhbmQgc29tZSBkZWZpbmVkIHByZS1tYXBwaW5nIGNoYXJhY3RlcnMpLiAg VGhlIC5DTiBhbmQgLlRXIHJlZ2lzdHJpZXMgam9pbmVkIGZvcmNlcyB0aHJvdWdoIHRoZSBDRE5D IHRvIGRldmVsb3AgdGhlIENoaW5lc2UgcG9saWN5IHByb2ZpbGUgd2l0aCBhIGxpc3Qgb2YgdmFs aWQgY2hhcmFjdGVycyAod2hpY2ggaW5jbHVkZXMgU2ltcGxpZmllZCBhbmQgVHJhZGl0aW9uYWwg Q2hpbmVzZSBjaGFyYWN0ZXJzIGFzIHdlbGwgYXMgTERIKSBhbmQgY29uc2lkZXJhdGlvbnMgZm9y IHZhcmlhbnQgbWFwcGluZ3MuDQoNCk5vdGUgdGhhdCBib3RoIHRoZXNlICJEb21haW4tTGFuZ2F1 Z2UtUG9saWNpZXMiIGluIGZhY3QgaW5jbHVkZSBtdWx0aXBsZSAid3JpdGluZyBzeXN0ZW1zIiB3 aXRoaW4gb25lIHByb2ZpbGUuICBCb3RoIGFsc28gaW5jbHVkZWQgbXVsdGlwbGUgInNjcmlwdHMi IGFuZCBldmVuIGFyZ3VhYmx5IG11bHRpcGxlICJsYW5ndWFnZXMiLg0KDQpBcyB3ZSBjb250aW51 ZSB0byB3b3JrIG9uIGltcGxlbWVudGF0aW9uIG9mIElETiwgSSBoYXZlIGZvdW5kIHRoYXQgaXQg aXMgaGFyZCBhbmQgb2Z0ZW4gY3JlYXRlcyBjb25mdXNpb24gd2hlbiB1c2luZyBvdmVybHkgZ2Vu ZXJpYyB3b3JkcyBzdWNoIGFzICJsYW5ndWFnZSIgYW5kICJzY3JpcHQiIGJlY2F1c2UgdGhleSBn ZW5lcmFsbHkgY29tZSB3aXRoIGEgbG90IG9mIGJhZ2dhZ2UuICBJbiBvcmRlciB0byBjbGFyaWZ5 IGRpc2N1c3Npb25zIGFuZCB0cnkgdG8gYXZvaWQgY29udm9sdXRlZCBkZWJhdGVzIHdoaWNoIG1h eSBiZSBpbnRlcmVzdGluZyBidXkgdWx0aW1hdGVseSBjb25mdXNpbmcgZm9yIGxpbmd1c3RzIGFu ZCB0ZWNobm9sb2dpc3RzIGFsaWtlLCBpdCBzZWVtcyB0aGF0IGludmVudGluZyBhIGZldyBwaHJh c2VzIHRvIGdpdmUgaXQgYSBjbGVhciAiSUROIiBjb250ZXh0IHdvdWxkIGJlIHVzZWZ1bC4NCg0K SnVzdCBzb21lIHRob3VnaHRzLi4uDQoNCkVkbW9uDQo= From owner-idn@ops.ietf.org Fri Feb 18 10:08:42 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12183 for ; Fri, 18 Feb 2005 10:08:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29eq-00034S-W4 for idn-data@psg.com; Fri, 18 Feb 2005 15:03:05 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29en-0002wK-ES for idn@ops.ietf.org; Fri, 18 Feb 2005 15:03:01 +0000 Received: from lns-p19-1-idf-82-251-140-32.adsl.proxad.net ([82.251.140.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D29ei-0004pZ-7U; Fri, 18 Feb 2005 07:02:56 -0800 Message-Id: <6.1.2.0.2.20050218131146.047ec4c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Feb 2005 13:16:49 +0100 To: Erik van der Poel , "Martin v. Lwis" From: "JFC (Jefsey) Morfin" Subject: Re: [idn] homograph attacks Cc: Martin Duerst , idn@ops.ietf.org In-Reply-To: <4215D375.3080206@vanderpoel.org> References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> <4215A572.3050903@v.loewis.de> <4215D375.3080206@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit At 12:37 18/02/2005, Erik van der Poel wrote: >Martin v. Lwis wrote: >>Martin Duerst wrote: >>>Very much agreed. Except for registries with very special >>>policies (such as the blocking used by some East Asian >>>registries), the language association doesn't make too >>>much sense. >>However, as the East Asian languages might cause blocking, >>every .COM user is required to provide a language tag. So >>in that sense, every gTLD will have very special policies. > >The .com and .net domains are operated by VeriSign: I understand from sales and renewals that the registrants also have adopted a Chinese blocking. I suggest you also go and visit the CNNIC site when you consider Chinese issues. jfc >http://icann.org/faq/#regrules >VeriSign appears to have adopted the Chinese blocking: >http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/idn-standards/idn-character-variants/page_002087.html > >Do you know whether any of the other gTLDs have adopted the Chinese blocking? >Also, does any registry have blocking for any languages other than Chinese? >Thanks, > >Erik From owner-idn@ops.ietf.org Fri Feb 18 10:08:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12234 for ; Fri, 18 Feb 2005 10:08:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29f2-00038E-D2 for idn-data@psg.com; Fri, 18 Feb 2005 15:03:16 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29ej-0002vo-7s for idn@ops.ietf.org; Fri, 18 Feb 2005 15:02:57 +0000 Received: from lns-p19-1-idf-82-251-140-32.adsl.proxad.net ([82.251.140.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D29eg-0004pZ-H2; Fri, 18 Feb 2005 07:02:55 -0800 Message-Id: <6.1.2.0.2.20050218124945.047eace0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Feb 2005 13:11:16 +0100 To: Martin Duerst , James Seng From: "JFC (Jefsey) Morfin" Subject: Re: [idn] homograph attacks Cc: idn@ops.ietf.org In-Reply-To: <6.0.0.20.2.20050218082023.03685a70@localhost> References: <42142666.6080005@vanderpoel.org> <6.0.0.20.2.20050217174850.06842c80@localhost> <621f441a8986e71ed205761e0a6e7df1@seng.cc> <6.0.0.20.2.20050217213605.06d1c3d0@localhost> <6.0.0.20.2.20050218082023.03685a70@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk could we for once call a cat a cat? As noted in an earlier mail, we are neither speaking of language, script, countries: we are speaking of tables, and therefore of IDN tabtags. Whatever the reason a sovereign ccTLD Manager has to enter a code into a table, the code is in the table. So please stop arguing on the possible reasons, etc. A computer only considers the bits you put into a format, not your reasons. There are three technical layers involved (internationalization, multilingualization and vernacularization) plus ccTLD's usual societal, economical and political considerations as in every other internet governance issue. If you want to advize them, just fine. But IETF is only concerned by the provision of the tools they needs. Today the IDNA solution is not addressing their needs, but it is here. No other solution will be provided by the IETF, however some refinements can be brought, at least through RFC for information to avoid a total fragmentation of the Internet between Lagacy and NGN. Among them: 1. a BCP commenting the RFC 3490 introduction to permit ITLDs (not the best and correct solution, but the only one permitted in this DNS current incoherence). 2. a better doctrine concerning the DNS virtual zones management to take into account tabtags in the NIC organization, since they were not permitted to be real zones. 3. a better relation between tables and lingual and vernacular aspects, with probably more general tabtags (ex. an extended European Latin table for all the characters European people understand as different). The rest will be most probably addressed as usual by an open grassroots process, a "Language P2P like" process, part of the necessary technology evolution. Outside of the IETF virtual and of the W3C private worlds. The only result of all this will have been another 10 years wasted. jfc At 06:21 18/02/2005, Martin Duerst wrote: >Hello James, > >Many thanks for your private answer. I'd preferred to have this >discussion in some public forum, so please feel free to forward >this to one of the lists where I'm involved. > >At 02:53 05/02/18, James Seng wrote: > >when we do idn, we talk about unicode and scripts. afterall, unicode is > a script based encoding so it is silly to think in language. > >Very good point. > > >but when you deal with end-users, lay-person who wants their idn, they > thinking of names. they want names in their own languages. script? what's > the different. > >They want the names in their own characters. Some, maybe quite >a lot, of users may think about it in terms of language, but >there is no need to stress the language aspect more than >necessary. > >Also, if the average user gets that policy, but Verisign doesn't, >that's much more damaging than the other way round. > > > >that's the gap between the two. that's why in rfc3743, we talk about how > to do chinese idn, japanese idn and korean idn and not han ideograph idn. > >For rfc3743, that's fine, because that's dealing with language and >using language to address problems. Or actually, to be more precise, >it's not fine, because the main concern of rfc3743 isn't maybe >so much necessarily language as different ways to write the same >language. Simplified and traditional Chinese are not two different >languages, at least as I understand. > >Another problem is that in different parts of the world, the issues >are diffenent. Switzerland is a good example, they didn't publish a >German table, a French table, and so on, for very good reasons. >It shouldn't look like they violate the ICANN policy, but at >the moment, it does look like they violate the policy because of >the way the policy is written. If that's by design, it's bad >design. > >I'm not asking to remove all instances of 'language' from that >policy, but having 'language' 19 times and 'script' 0 times >in that document gives completely the wrong impression. > >Regards, Martin. > > >james > > > >On 17-Feb-05, at PM 08:39, Martin Duerst wrote: > > > >> Hello James, > >> > >> If using 'language' only, and never mentioning 'script', > >> is by design, then would you mind pointing me to that > >> design, or explaining it to me? > >> > >> Regards, Martin. > >> > >> > >> At 19:05 05/02/17, James Seng wrote: > >> >the choice of words of using language (instead of script) in ICANN > community is by design. > >> > > >> >james > >> > > >> >On 17-Feb-05, at PM 04:55, Martin Duerst wrote: > >> > > >> >> At 14:06 05/02/17, Erik van der Poel wrote: > >> >> >Michel Suignard wrote: > >> >> >> It is much more challenging for a worlwide TLD such as .com to > >> >> >> establish registration rules. Typically script is a much better > >> >> >> selector than language to establish those tables and associated > >> >> >> rules. > >> >> > > >> >> >"Typically"? You make it sound like you've "been there, done > that". :-) > >> >> > > >> >> >Seriously, would you please elaborate on your ideas for .com? I > would really like to know what you have in mind, specifically, to combat > the homograph problem. > >> >> > >> >> Hello Eric, > >> >> > >> >> I can't answer fro Michel. But I just had a look at the ICANN > guidelines, > >> >> and they use the word 'language' 19 times (hope I counted correctly), > >> >> and the word 'script' not a single time. > >> >> > >> >> However, there are at least as much 'script' aspects as there are > >> >> 'language' aspects in the current problem, and if you look at actual > >> >> implementation in ccTLD registries that have deployed IDNs, it's > >> >> also quite a bit about 'script'. As an example, .ch has published > >> >> a single table although they are very clearly working with three > >> >> or four languages. > >> >> > >> >> Too much emphasis on 'language' rather than 'script' also has lead > >> >> to strange claims such as that creating IDN TLDs is impossible > >> >> because we cannot create 6000 versions of .com. Again, looking > >> >> at this as a script problem is much more appropriate, after > >> >> all, neither "com" nor any ccTLD nor most of the gTLDs are > >> >> associated with any single language. > >> >> > >> >> Regards, Martin. > >> >> > >> > > >> > > > > From owner-idn@ops.ietf.org Fri Feb 18 10:09:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12333 for ; Fri, 18 Feb 2005 10:09:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29fG-0003I9-5k for idn-data@psg.com; Fri, 18 Feb 2005 15:03:30 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29ex-00037k-UI for idn@ops.ietf.org; Fri, 18 Feb 2005 15:03:12 +0000 Received: from lns-p19-1-idf-82-251-140-32.adsl.proxad.net ([82.251.140.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D29ej-0004pZ-Od; Fri, 18 Feb 2005 07:02:58 -0800 Message-Id: <6.1.2.0.2.20050218131813.047e9a30@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Feb 2005 13:19:59 +0100 To: Martin Duerst , Erik van der Poel , John C Klensin From: "JFC (Jefsey) Morfin" Subject: Re: [idn] who should be doing IDN filtering Cc: Paul Hoffman , IETF idn working group In-Reply-To: <6.0.0.20.2.20050218085508.0807a9f0@localhost> References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> <42150F66.4070900@vanderpoel.org> <6.0.0.20.2.20050218085508.0807a9f0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:52 18/02/2005, Martin Duerst wrote: >The rest will be taken care by registrants, they'll figure out >sooner or later what names are easy to type and what names are >not easy to type. It has worked quite well for the ASCII-only >DNS. Welcome to "phish and click" !!! From owner-idn@ops.ietf.org Fri Feb 18 10:09:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12579 for ; Fri, 18 Feb 2005 10:09:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29ih-0004M1-HV for idn-data@psg.com; Fri, 18 Feb 2005 15:07:03 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29iV-0004En-OR for idn@ops.ietf.org; Fri, 18 Feb 2005 15:06:51 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D29iN-000FMA-4i; Fri, 18 Feb 2005 10:06:43 -0500 Date: Fri, 18 Feb 2005 10:06:43 -0500 From: John C Klensin To: "JFC (Jefsey) Morfin" , Martin Duerst , Erik van der Poel cc: Paul Hoffman , IETF idn working group Subject: Re: [idn] who should be doing IDN filtering Message-ID: <0E47BD7E821EF3B12828C6CF@scan.jck.com> In-Reply-To: <6.1.2.0.2.20050218131813.047e9a30@mail.jefsey.com> References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> <42150F66.4070900@vanderpoel.org> <6.0.0.20.2.20050218085508.0807a9f0@localhost> <6.1.2.0.2.20050218131813.047e9a30@mail.jefsey.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Friday, 18 February, 2005 13:19 +0100 "JFC (Jefsey) Morfin" wrote: > At 03:52 18/02/2005, Martin Duerst wrote: >> The rest will be taken care by registrants, they'll figure out >> sooner or later what names are easy to type and what names are >> not easy to type. It has worked quite well for the ASCII-only >> DNS. > > Welcome to "phish and click" !!! Which, as Martin points out, has worked quite well for the ASCII-only DNS. john From owner-idn@ops.ietf.org Fri Feb 18 10:22:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15160 for ; Fri, 18 Feb 2005 10:22:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29sb-0007Bv-LY for idn-data@psg.com; Fri, 18 Feb 2005 15:17:17 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D29sP-00079J-Ms for idn@ops.ietf.org; Fri, 18 Feb 2005 15:17:06 +0000 Received: (qmail 87553 invoked by uid 0); 18 Feb 2005 23:20:08 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 11.041074 secs); 18 Feb 2005 15:20:07 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 11.041074 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 18 Feb 2005 23:19:44 +0800 Message-ID: <421606AC.1090709@dready.org> Date: Sat, 19 Feb 2005 02:15:56 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Duerst CC: Erik van der Poel , Michel Suignard , Martin Loewis , "Kane, Pat" , idn@ops.ietf.org, ericj@shmoo.com, tedd , dam@icann.org, roozbeh@sharif.edu Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> In-Reply-To: <6.0.0.20.2.20050218113553.08077390@localhost> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Martin et al, Martin Duerst wrote: > Very much agreed. Except for registries with very special > policies (such as the blocking used by some East Asian > registries), the language association doesn't make too > much sense. Indeed, for registries that wish to support CJK languages by following RFC3743, it makes sense to find out the intended language of a label in order to decide whether to apply traditional/simplified Chinese bundling. Take for example a label that contains only Han characters. When used in a Japanese context, there probably wouldn't be any variant that the registrant would care about. But when the same label is used in a Chinese context, assuming that it does mean something, the registrant might want both the traditional and simplified variants of the label. Quoting John in draft-klensin-reg-guidelines: ...and with different geographical and political locations and languages having requirements for different collections of characters, the optimal registration restrictions became, not a global matter, but ones that were different in different areas and, hence, in different DNS zones. It is my belief that CJK is not the only "problematic" or special cases. As languages are being researched on in terms of their implications in IDN, more language-dependent rules may need to be accommodated. > > Immagine that a gTLD registry had a few hundred language tables, > and immagine that a registrant wanted to register a particular > sequence of characters. It would be very easy for a registrar > to set up a service that figured out a language (don't care > which) that worked, and register the name with that language. There is nothing wrong with this approach, technically. The language tag is, the way I see it, simply a hint and is more an administrative piece of information rather than concerning the operations of the DNS. It is used only at registration time, to allow the registry to make certain decisions and apply rules to it. If we could drop the word "language" and simply stick with "tag", then that tag could be a script, subset of a script, or simply a list of characters, labeled by a suitable term such as "Characters used in Germany", "Nordic languages", or "List of allowable characters for Japanese". Take the .PL IDN program for example, as long as the desired label contains only characters from one of the allowable tables, the registration will go through. The tables are named "Latin set", "Cyrillic set", "Greek set", etc. They could jolly well launch Chinese and introduce a rule that says, if your label fits into the Chinese table, we will reserve any variants of it as well. One could see that as associating an IDN with a table, and the table may be a single language, or may represent several languages. IMO, whether it is "language association" or "table association", they are one and the same concept. Regards, wil. From owner-idn@ops.ietf.org Fri Feb 18 10:27:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15711 for ; Fri, 18 Feb 2005 10:27:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D29yS-0008hl-PB for idn-data@psg.com; Fri, 18 Feb 2005 15:23:20 +0000 Received: from [129.171.187.81] (helo=osaka.law.miami.edu) by psg.com with smtp (Exim 4.44 (FreeBSD)) id 1D29y1-0008Vl-5j for idn@ops.ietf.org; Fri, 18 Feb 2005 15:22:53 +0000 Received: (qmail 30952 invoked by uid 500); 18 Feb 2005 16:29:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2005 16:29:18 -0000 Date: Fri, 18 Feb 2005 11:29:18 -0500 (EST) From: "Michael Froomkin - U.Miami School of Law" X-X-Sender: froomkin@osaka Reply-To: froomkin@law.tm To: John C Klensin cc: Paul Hoffman , IETF idn working group Subject: Re: [idn] who should be doing IDN filtering In-Reply-To: Message-ID: References: <20050217095832.GD12777~@nicemice.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Thank you for the thoughtful comments. I'm going to cherry pick and just respond to the assertions I think are most germane to my original comment. (There's lots of other interesting issues, but not for here and now.) 1. I'm glad you recognize I am not advocating an enforcement regime. And I like consensus when we can get it. But I also don't mind market-based regimes with clear disclosure and labelling; in a managed space with artificial scarcity like the TLD-space, one way to get that is to increase supply. I recognize that some people are nervous about that, but it doesn't seem to dennigrate those concerns to also note that there can be advantages. 2. I do, however, disgree with the assertion that the gTLD space we have, or even the gTLD + ccTLD space, is a well-functioning competitive market at the registry level for reasons including first-mover advantages, locking, arbitrary semantic choices imposed by the regulator (ICANN) and so on. I could go on, or cite academic papers, but I know that you and the others who care have heard the arguments. I thus also think that in this environment there is little one can infer by registration patterns, which are driven by other things. 3. If we want or hope for innovative marketing or differentiation of gTLDs, the most likely way to get them is to create new ones. The IETF, and if memory serves you prominently among its active members, has expressed scepticism about this idea on many occasions. 4. The idea for an informational RFC in this area is no odder than, say, RFC 3675 (which is not intended as a comment on the merits of that document, but just a comment about its scope as it relates to the scope of this idea)...or even, dare I say it, RFC 3071. 5. I agree there would be a substantial drafting challenge to be overcome. On Thu, 17 Feb 2005, John C Klensin wrote: > > > --On Thursday, 17 February, 2005 12:53 -0500 "Michael Froomkin - > U.Miami School of Law" wrote: > >> Assuming we can't cut ICANN out of the picture, isn't one >> solution to lobby ICANN to allow for new TLDs with policies >> that forbid misleading IDNs and let the marketplace sort it >> out? > > Michael, > > "Misleading?" Why should IDNs be any different from ASCII-only > labels? "M1CR0S0FT" would certainly be a "misleading" label > from the point of view of the obvious company, but the community > concluded, long ago, that problem should be dealt with by UDRP > procedures or court action, not having some registry make up > rules about what can't be registered based on what someone else > thinks is "misleading". > > For the special case of mixed-script labels, ICANN already has > guidelines in place that requires gTLDs who choose to register > IDNs to limit any given label to a single "language" or small > set of languages. Those guidelines are, IMO, badly written and > ambiguous and need fixing, but, as far as I know, all of gTLDs > except two are conforming to those guidelines and, in > particular, not permitting registrations of strings for which > they don't have established language tables. The registry for > the other two has apparently decided, partially for historical > reasons, to go ahead and register almost anything that doesn't > match a language for which they already have tables... a topic > that has been discussed on this list already. > > The ccTLDs which have decided to deploy IDNs and who are not > bound by those guidelines, have, by and large, adopted registry > restriction rules that are intended to prevent mixed-script and > other types of IDN-baesd misleading names when feasible. Some > of them are based on "characters in use in our territory" and > "names we need to be able to represent in order to assure > fairness" rules, rather than strict language or script rules, > but I suggest they are still within the general intent of > preventing misleading mixed-script labels when possible. While > policies differ, most of the ccTLDs, and an even larger majority > of those operated to support DNS use in the relevant country, > are consistent with the general spirit of the ICANN guidelines. > > Some of us continue to believe, I hope consistently, that > conformance based on consensus and conclusions that it is the > Right Thing to Do is much better than trying to devise an > enforcement regime. I know you didn't suggest an enforcement > regime, but others in this discussion have come pretty close. > And, for prohibitions on registration of mixed-script misleading > names, the worldwide conformance level, among TLDs that have > deployed IDNs, to the general principle is fairly high. > > As far as the marketplace sorting this out, I suggest that the > marketplace has already spoken, without any requirement to make > up new TLDs to seek a stronger message. We have TLDs (country > code and generic) who prohibit IDN registrations. We have TLDs > (again, both groups) who permit IDN registrations only if > languages are identified and script rules carefully adhered to. > And we have TLDs who permit registration of almost anything > permitted by IDNA, either explicitly or through some loophole. > What I haven't seen, before or after this latest > phishing-possibility demonstration, is a single instance of an > advertisement or press release that says "you should register in > our domain rather than theirs because our permitted-label rules > are more restrictive and hence will give you and your users > better assurances that they aren't being phished". Nor have we > seen any symptoms of registrations migrating spontaneously among > domains to reflect those concerns. If the marketplace has any > intent of speaking to this issue --or "sorting things out"-- it > is doing so in a whisper. > > I am a little depressed by that. I'd be much happier to see > "our domain is safer than their domain" ads and positive > responses to them, just as I would have been happy to see > "register in our domain because we promise to never try to > divert the typing mistakes of your users to your competitors" a > year or so ago. But they don't happen. And, using the second > case as an example, there is zero evidence that it has had any > marketplace effect on registrations. The marketplace for > registrations just doesn't seem to care, and we don't need more > TLDs to tell us that. > >> Maybe the IETF could issue a statement of some sort on the >> security implications of failing to allow such TLDs into the >> marketplace? > > For the mixed-script case and some related ones, such TLDs are > already in the marketplace and are actually the large majority > of TLDs. There is a reason why that paypal example didn't show > up in AERO, BIZ, CH, CN, DE, INFO, INT, JP, ORG, SE, TW, and a > host of others -- it could not have been registered, either > because the registry prohibits mixed-script registrations or > because it is going slowly about IDN deployment, wanting others > to get more experience first. > > So what would you like the IETF to say, exactly? "Domains that > are being cautious about registrations should advertise the fact > better"? Not exactly an IETF-type statement. "Guidelines that > prevent obvious abuses are good"? The IETF has already said > essentially that -- see the "IESG Statement" on IDNs -- and most > of the TLD registries are doing it as they deploy IDNs. Or > perhaps "200 plus domains are already proceeding safely in this > area so security requires that we add a few more who will too"? > Doesn't pass the laugh test, at least from where I sit. > > best, > john > -- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin | Professor of Law | froomkin@law.tm U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm -->It's cool here.<-- From owner-idn@ops.ietf.org Fri Feb 18 10:33:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16264 for ; Fri, 18 Feb 2005 10:33:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2A3v-0009xH-5n for idn-data@psg.com; Fri, 18 Feb 2005 15:28:59 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2A3n-0009wZ-Pk for idn@ops.ietf.org; Fri, 18 Feb 2005 15:28:52 +0000 Received: (qmail 89067 invoked by uid 0); 18 Feb 2005 23:31:54 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 3.819762 secs); 18 Feb 2005 15:31:54 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 3.819762 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 18 Feb 2005 23:31:49 +0800 Message-ID: <42160986.60700@dready.org> Date: Sat, 19 Feb 2005 02:28:06 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , Martin Duerst , idn@ops.ietf.org Subject: Re: [idn] homograph attacks References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> <4215A572.3050903@v.loewis.de> <4215D375.3080206@vanderpoel.org> In-Reply-To: <4215D375.3080206@vanderpoel.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, > Do you know whether any of the other gTLDs have adopted the Chinese > blocking? > AFAIK, CNNIC and TWNIC are the only two that do Chinese bundling. But their activation policy differs from Verisign's. > Also, does any registry have blocking for any languages other than > Chinese? > Check out the Persian IDN testbed project at IRNIC. They have a bundling policy. There may be other registries out there implementing bundling that I'm not aware of. Regards, wil. From owner-idn@ops.ietf.org Fri Feb 18 10:53:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21369 for ; Fri, 18 Feb 2005 10:53:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2ANA-000EOe-2E for idn-data@psg.com; Fri, 18 Feb 2005 15:48:52 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2AMq-000EHg-Ur for idn@ops.ietf.org; Fri, 18 Feb 2005 15:48:33 +0000 Received: (qmail 90680 invoked by uid 0); 18 Feb 2005 23:51:35 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.065741 secs); 18 Feb 2005 15:51:35 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.065741 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 18 Feb 2005 23:51:25 +0800 Message-ID: <42160E1E.30600@dready.org> Date: Sat, 19 Feb 2005 02:47:42 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> In-Reply-To: <4215F099.9020002@vanderpoel.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, > But what can we do about .com? It's not about what we can do about it, but what Verisign wants. If Verisign wanted to strictly adhere to ICANN's IDN guidelines, it would've dropped support for languages for which they have no table, and Eric wouldn't have been able to register that twisted paypal.com. And if Verisign, in light of this homograph attack advisory, decides to play it right from now on, I'd be pretty much contented. Sure, there are other TLDs who are still registering IDNs with liberal rules, maybe we can convince them to follow suit, maybe not. > It's clearly a worldwide TLD now. It should probably allow multiple > writing systems. Perhaps the .com operator could specify that 2nd > level domain labels must stick to one writing system, and that that > writing system must be indicated in the RRP (Registry Registrar > Protocol) in order to validate the 2nd level name against the table of > characters allowed in that writing system. This is already the case in Verisign's SRS where registrars are required to submit an ISO-639 language tag via RRP. > > This would probably require a (new?) set of names for writing systems, > somewhat similar to the language tags of ISO 639. > What nifty features would this bring, if the registry does not attach any rules to the writing systems, as is the case with language tags now. Regards, wil. From owner-idn@ops.ietf.org Fri Feb 18 10:57:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22851 for ; Fri, 18 Feb 2005 10:57:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2ASR-000FeO-12 for idn-data@psg.com; Fri, 18 Feb 2005 15:54:19 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2ASL-000FdE-RG for idn@ops.ietf.org; Fri, 18 Feb 2005 15:54:14 +0000 Received: from lns-p19-1-idf-82-251-140-32.adsl.proxad.net ([82.251.140.32] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D2ASI-0002vd-MP; Fri, 18 Feb 2005 07:54:11 -0800 Message-Id: <6.1.2.0.2.20050218161154.047ea770@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 18 Feb 2005 16:54:08 +0100 To: John C Klensin , Martin Duerst , Erik van der Poel From: "JFC (Jefsey) Morfin" Subject: Re: [idn] who should be doing IDN filtering Cc: Paul Hoffman , IETF idn working group In-Reply-To: <0E47BD7E821EF3B12828C6CF@scan.jck.com> References: <20050217095832.GD12777~@nicemice.net> <4214E807.2050802@vanderpoel.org> <42150F66.4070900@vanderpoel.org> <6.0.0.20.2.20050218085508.0807a9f0@localhost> <6.1.2.0.2.20050218131813.047e9a30@mail.jefsey.com> <0E47BD7E821EF3B12828C6CF@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 16:06 18/02/2005, John C Klensin wrote: >--On Friday, 18 February, 2005 13:19 +0100 "JFC (Jefsey) Morfin" > wrote: > > > At 03:52 18/02/2005, Martin Duerst wrote: > >> The rest will be taken care by registrants, they'll figure out > >> sooner or later what names are easy to type and what names are > >> not easy to type. It has worked quite well for the ASCII-only > >> DNS. > > > > Welcome to "phish and click" !!! > >Which, as Martin points out, has worked quite well for the >ASCII-only DNS. And will work much better for IDNA which offers far more phishing and tricks opportunities. Welcome to the IETF understanding of internationalization/multiligualization/vernacularization !!! And you are the one who understand it the best.... Never asked: did you work with Doug Engelbart too? jfc PS. By the way where did you take that IDNA was not using an ASCII-only DNS? That international/multilingual/vernacular layers are much simpler when using ASCII domain name does not imply that they do not exist and that you are permitted layer violations. Or may be you mean that a far better way was to respect the DNS basic rules, not to introduce as left to right contradicting hierachy (IDN/DN) and management mess? IMHO we do not need to worry: this is what a grassroots process is going to impose on the long/medium?/short?? range if they want to avoid a balkanization of the root. Let get real. I do prefer "name.tag--eu.ch" being read "name.ech" by my browser/userbox tables than a multilingual root being linked to the NTIA root through an "*" entry. Do you know what is the size of a virus table maintained every morning on my PC when compared with a TLD language transcoding table? 260 TLDs, possibly 500 scripts = 2000 ITLDs for a 10 chars entry average: 20000 chars.Good ASN.1 may reduce it. Compressed probably 10 K. I am sure every PAD Administrators will include it and the root file for free in their delivery. Sent as patches it probably takes 100 bytes a day. From owner-idn@ops.ietf.org Fri Feb 18 13:26:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17930 for ; Fri, 18 Feb 2005 13:26:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2Ci8-000Oa3-BB for idn-data@psg.com; Fri, 18 Feb 2005 18:18:40 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2Ci7-000OZl-1V for idn@ops.ietf.org; Fri, 18 Feb 2005 18:18:39 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IIIXuq345642; Fri, 18 Feb 2005 13:18:33 -0500 Message-ID: <42163178.70608@vanderpoel.org> Date: Fri, 18 Feb 2005 10:18:32 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Tan CC: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> <42160E1E.30600@dready.org> In-Reply-To: <42160E1E.30600@dready.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Perhaps the .com operator could specify that 2nd >> level domain labels must stick to one writing system, and that that >> writing system must be indicated in the RRP (Registry Registrar >> Protocol) in order to validate the 2nd level name against the table of >> characters allowed in that writing system. > > This is already the case in Verisign's SRS where registrars are required > to submit an ISO-639 language tag via RRP. I feel that it may be worth exploring whether we can come up with a distinct (from 639) set of names that more accurately matches the model I'm thinking of. See below. >> This would probably require a (new?) set of names for writing systems, >> somewhat similar to the language tags of ISO 639. >> > What nifty features would this bring, if the registry does not attach > any rules to the writing systems, as is the case with language tags now. Well, perhaps the tag passed in RRP would not simply identify a table of characters that are used in a writing system. Perhaps the tag would name a set of rules for a domain label, that includes having to use a table of characters. This set of rules could, for example, include a rule that states whether and how Latin characters are allowed in a Cyrillic label such as the XML-ccccccc.com example mentioned earlier on the Unicode mailing list. (Here, the "ccccccc" are all Cyrillic characters.) As was mentioned on the Unicode mailing list, the hyphen '-' could be used to separate the Latin from the Cyrillic. The Russian TLD .ru might want to have such a set of rules. (They probably already have some rules; I certainly am not trying to force them to adopt this proposal; it is merely an example.) To continue this example, the .com registry might then wish to reduce confusion by adopting the same set of rules for Russian registrations under .com. This way, a registrant is confronted with a unified model and set of rules, whether they wish to register only under .ru or also under .com. Of course, under this proposal, the guideline would no longer be called "one label, one writing system" because my proposed sets of rules would not really be exactly the same as "writing systems" as defined in the Unicode book. So we might have to come up with a different term for these sets of rules. How about "label rules"? Erik From owner-idn@ops.ietf.org Fri Feb 18 14:09:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25984 for ; Fri, 18 Feb 2005 14:09:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2DSC-0009yO-Mc for idn-data@psg.com; Fri, 18 Feb 2005 19:06:16 +0000 Received: from [213.237.47.228] (helo=rap.rap.dk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2DS9-0009xM-8E for idn@ops.ietf.org; Fri, 18 Feb 2005 19:06:13 +0000 Received: by rap.rap.dk (Postfix, from userid 500) id 8748AE5BB; Fri, 18 Feb 2005 20:06:13 +0100 (CET) Date: Fri, 18 Feb 2005 20:06:12 +0100 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: Erik van der Poel Cc: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing Message-ID: <20050218190612.GE27445@rap.rap.dk> References: <4215F099.9020002@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4215F099.9020002@vanderpoel.org> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On Fri, Feb 18, 2005 at 05:41:45AM -0800, Erik van der Poel wrote: > So, instead, I propose that we start thinking of a "one label, one > writing system" rule. The Unicode book defines "writing system" as "a > set of rules for using one or more scripts to write a particular language". I think we should only try to address the DNS spoofing problem, while allowing as much of business to be able to market themselves in an adequate way. Why not allow Japanese characters in the Danish ccTLD? I had a japanese restaurant on the opposite corner of my road, and I have a Chinese restaurant just on the corner of the other end of my road. Both were advertising ther foreign name on the street facade, and on their bills and visit cards. If a company is marketing themselves in a script foreign to the country they are located, why should we not allow it on the internet. The internet should follow modern business practices. Of cause we should minimize the risks for internet users of being mislead. This could be done by equializing similar characters, like Latin, Cyrillic and greek A, 0 and O, 1 and 1 etc, so that no visual misleading should be possible. Best regards Keld From owner-idn@ops.ietf.org Fri Feb 18 14:49:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02571 for ; Fri, 18 Feb 2005 14:49:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2E3W-000IhG-KO for idn-data@psg.com; Fri, 18 Feb 2005 19:44:50 +0000 Received: from [80.67.18.13] (helo=smtprelay01.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2E3R-000Igy-T1 for idn@ops.ietf.org; Fri, 18 Feb 2005 19:44:46 +0000 Received: (qmail 10492 invoked from network); 18 Feb 2005 19:44:39 -0000 Received: from unknown (HELO [80.185.150.200]) (544451@[80.185.150.200]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 18 Feb 2005 19:44:39 -0000 Message-ID: <421645A4.6030302@v.loewis.de> Date: Fri, 18 Feb 2005 20:44:36 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> <42160E1E.30600@dready.org> <42163178.70608@vanderpoel.org> In-Reply-To: <42163178.70608@vanderpoel.org> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > So we might have to come up with a different term for these sets of > rules. How about "label rules"? I'm convinced that terminology is of least concern. No matter what your terminology is (language tags, script tags, or DNS label tags), it *is* a lot of work to come up with reasonable rules to simultaneously allow registration of "valid" labels, yet rejecting spoofing registrations. And the hard work is *not* in finding algorithms - the hard work is in coming up with the data that drive the tables. In that sense, Verisign's approach for .com is just right: we will not create our own tables, we will use whatever tables national bodies, (or perhaps the Unicode consortium), provide us. Each registrant needs to identify which table a certain registration is meant to comply with; it just happens that ISO 639 codes are used to identify the tables (but Roman numerals would work just as well if the tables are published). As I said before, it is reasonable to err on the side of caution in creating these tables (something that Verisign unfortunately does not agree with); it will always be possible to extend the tables later. So, to help the process, creation of tables for the various user groups is necessary. Regards, Martin From owner-idn@ops.ietf.org Fri Feb 18 15:16:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07365 for ; Fri, 18 Feb 2005 15:16:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2EV7-000PZn-Vx for idn-data@psg.com; Fri, 18 Feb 2005 20:13:21 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2EV3-000PZ8-1A for idn@ops.ietf.org; Fri, 18 Feb 2005 20:13:17 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D2EUy-000HU9-Sl; Fri, 18 Feb 2005 15:13:12 -0500 Date: Fri, 18 Feb 2005 15:13:04 -0500 From: John C Klensin To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= , Erik van der Poel cc: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing Message-ID: In-Reply-To: <20050218190612.GE27445@rap.rap.dk> References: <4215F099.9020002@vanderpoel.org> <20050218190612.GE27445@rap.rap.dk> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable --On Friday, 18 February, 2005 20:06 +0100 Keld J=F8rn Simonsen wrote: >... > Of cause we should minimize the risks for internet users of > being mislead. This could be done by equializing similar > characters, like Latin, Cyrillic and greek A, 0 and O, 1 and 1 > etc, so that no visual misleading should be possible. Keld, for better or worse, a decision was made to not try to do this in IDNA. At least one of the reasons is that the definition of "similar" is much in the mind of the beholder. The decision to treat 0 and O, 1 and l, as separate was made 20 (or, by a different line of reasoning, more like 34) years ago and is irreversible at this point. =20 For the more general case, U+0E02, U+0E03, U+0EA1 could all be construed by someone who doesn't know which scripts they came from as font variation on either U+0C35 or U+0055, so it isn't at all clear how one would adopt general "equalizing" rules, even if they were wanted. The good news is that, should a registry decide to use them, the "variant" model of RFC 3743 could be easily adapted to prevent labels that would equivalent if these "equal in the mind of the registry" characters were from being registered. Personally, I find it rather attractive that the decision as to whether or not to do that, and which characters to consider too similar to permit labels built on them to be registered to different parties, can be made one registry at a time, with no need for global agreement about those visual perceptions. john From owner-idn@ops.ietf.org Fri Feb 18 17:16:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07677 for ; Fri, 18 Feb 2005 17:16:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2GKQ-0001O2-A5 for idn-data@psg.com; Fri, 18 Feb 2005 22:10:26 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2GK1-0001Cg-C3 for idn@ops.ietf.org; Fri, 18 Feb 2005 22:10:01 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IM9sHb146968; Fri, 18 Feb 2005 17:09:59 -0500 Message-ID: <421667B2.6020409@vanderpoel.org> Date: Fri, 18 Feb 2005 14:09:54 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= CC: idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> <42160E1E.30600@dready.org> <42163178.70608@vanderpoel.org> <421645A4.6030302@v.loewis.de> In-Reply-To: <421645A4.6030302@v.loewis.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Martin v. Lwis wrote: > Erik van der Poel wrote: >> So we might have to come up with a different term for these sets of >> rules. How about "label rules"? > > I'm convinced that terminology is of least concern. I think I disagree. The term "language" is well known to many people, and has quite a different meaning from "table of characters". On the other hand, if you use the term "label rules" and then explain what those rules are for a given TLD, then it should be quite clear to just about anybody. There are very few language tables registered in IANA's IDN registry, possibly because NICs like DE do not wish to specify a language or set of languages. :-) Well, maybe they have other good reasons to refrain from registering their table. The rest of your email was mainly about tables, leading me to suspect that you may have missed my main point, which is that a registry can impose *additional* rules, such as allowing both Latin and Cyrillic, as long as there is a hyphen between them. If you did not miss this point, I apologize. Erik From owner-idn@ops.ietf.org Fri Feb 18 17:28:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11954 for ; Fri, 18 Feb 2005 17:28:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2GYA-00049B-Cz for idn-data@psg.com; Fri, 18 Feb 2005 22:24:38 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2GY0-00048h-7Y for idn@ops.ietf.org; Fri, 18 Feb 2005 22:24:28 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IMOQHb093802; Fri, 18 Feb 2005 17:24:26 -0500 Message-ID: <42166B19.9020002@vanderpoel.org> Date: Fri, 18 Feb 2005 14:24:25 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= CC: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> <20050218190612.GE27445@rap.rap.dk> In-Reply-To: <20050218190612.GE27445@rap.rap.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Keld Jrn Simonsen wrote: > Why not allow Japanese characters in the Danish ccTLD? I did not mean to imply that the ccTLDs would only allow their "own" languages. The Danish TLD could decide to accept registrations using "label rule" tags defined by other TLDs or organizations or individuals. If .com is allowed to adopt .ru's label rules for Russian registrations, then .dk should also be allowed to adopt label rules specified by other people. Alternatively, the Danish label rules themselves could simply allow Japanese characters since they are unlikely to be confused with Latin characters anyway, but then you run the risk of confusing your registrants with rules for Japanese that are different from the rules for Japanese under .jp, so you may want to adopt .jp's rules. That's your choice, and it's good that you have that choice, no? Erik From owner-idn@ops.ietf.org Fri Feb 18 18:11:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17489 for ; Fri, 18 Feb 2005 18:11:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2HCL-000DnF-13 for idn-data@psg.com; Fri, 18 Feb 2005 23:06:09 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2HCK-000Dmt-68 for idn@ops.ietf.org; Fri, 18 Feb 2005 23:06:08 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1IN62Hb116262; Fri, 18 Feb 2005 18:06:06 -0500 Message-ID: <421674DA.4010308@vanderpoel.org> Date: Fri, 18 Feb 2005 15:06:02 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Edmon Chung CC: unicode@unicode.org, idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4215F099.9020002@vanderpoel.org> <00b401c515c7$457f6820$eb0010ac@edmontr3> In-Reply-To: <00b401c515c7$457f6820$eb0010ac@edmontr3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Edmon Chung wrote: > ...policy profile... Yeah, maybe the term "policy profile" or "profile" is better than "label rules". I agree with you that "language" comes with a lot of baggage. Erik From owner-idn@ops.ietf.org Fri Feb 18 20:33:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08190 for ; Fri, 18 Feb 2005 20:33:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2JOw-000JnQ-Ml for idn-data@psg.com; Sat, 19 Feb 2005 01:27:18 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2JOu-000JnB-GR for idn@ops.ietf.org; Sat, 19 Feb 2005 01:27:16 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1J1R8SJ208800; Fri, 18 Feb 2005 20:27:08 -0500 Message-ID: <421695EB.1040507@vanderpoel.org> Date: Fri, 18 Feb 2005 17:27:07 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkane@verisign.com, gkrall@verisign.com CC: unicode@unicode.org, idn@ops.ietf.org Subject: [idn] Re: IDN spoofing References: <4215F099.9020002@vanderpoel.org> In-Reply-To: <4215F099.9020002@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit VeriSign folks: I seem to have written something that might upset someone again. I am really sorry. You guys have done a lot of good work and put a lot of information on your Web site regarding IDN. A lot of it is educational in nature, and a lot of it seems to indicate that you have sound policies in place. http://verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html It was unfair of me to accuse you (and other TLD operators) of only wanting to make money (and not being interested in the phishing problem). I apologize, and hope that you will send comments to one or both of these mailing lists when you're ready. Respectfully, Erik I wrote: > Also, I'm guessing that any "one label, one writing system" rule cannot > really be mandated, since TLD operators have historically been free to > do whatever they want, to make as much money as they want. So this rule > would just be a guideline (Klensin's document is titled "Suggested > Practices ...") and the TLD operators could follow it, if they wish to > combat the IDN spoofing problem more than they wish to make money (in > the short term :-) From owner-idn@ops.ietf.org Fri Feb 18 22:09:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16306 for ; Fri, 18 Feb 2005 22:09:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2Ktb-000FoM-PK for idn-data@psg.com; Sat, 19 Feb 2005 03:03:03 +0000 Received: from [128.30.52.30] (helo=homer.w3.org) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2Kta-000Fo5-Lw for idn@ops.ietf.org; Sat, 19 Feb 2005 03:03:02 +0000 Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 209FD4F3B8; Fri, 18 Feb 2005 22:02:59 -0500 (EST) Message-Id: <6.0.0.20.2.20050219102924.083fc150@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Sat, 19 Feb 2005 10:32:47 +0900 To: William Tan , Erik van der Poel From: Martin Duerst Subject: Re: [idn] homograph attacks Cc: =?ISO-2022-JP?B?Ik1hcnRpbiB2LiBMGyRCi1gbKEJpcyI=?= , idn@ops.ietf.org In-Reply-To: <42160986.60700@dready.org> References: <4214ABF5.3080700@dready.org> <4214C445.9070106@vanderpoel.org> <6.0.0.20.2.20050218113553.08077390@localhost> <4215A572.3050903@v.loewis.de> <4215D375.3080206@vanderpoel.org> <42160986.60700@dready.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At 00:28 05/02/19, William Tan wrote: >Hi Erik, > >> Do you know whether any of the other gTLDs have adopted the Chinese blocking? >> >AFAIK, CNNIC and TWNIC are the only two that do Chinese bundling. But their activation policy differs from Verisign's. I'd also look at SGNIC (Singapore). >> Also, does any registry have blocking for any languages other than Chinese? >> >Check out the Persian IDN testbed project at IRNIC. They have a bundling policy. I looked at the presentation they gave at ICANN. With respect to bundling,..., they are doing the right thing, I think. Regards, Martin. From owner-idn@ops.ietf.org Sat Feb 19 01:01:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01899 for ; Sat, 19 Feb 2005 01:01:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2Na5-00022Q-RU for idn-data@psg.com; Sat, 19 Feb 2005 05:55:05 +0000 Received: from [68.168.78.44] (helo=mta13.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2Na3-00021M-Mw for idn@ops.ietf.org; Sat, 19 Feb 2005 05:55:03 +0000 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050219055458.CEWQ21629.mta13.adelphia.net@DEWELL>; Sat, 19 Feb 2005 00:54:58 -0500 Message-ID: <00a401c51647$7ca1e140$030aa8c0@DEWELL> From: "Doug Ewell" To: =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "Erik van der Poel" Cc: , References: <4215F099.9020002@vanderpoel.org> <20050218190612.GE27445@rap.rap.dk> Subject: Re: [idn] IDN spoofing Date: Fri, 18 Feb 2005 21:54:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Keld Jørn Simonsen wrote: > Of cause we should minimize the risks for internet users of being > mislead. This could be done by equializing similar characters, > like Latin, Cyrillic and greek A, 0 and O, 1 and 1 etc, so that no > visual misleading should be possible. OK, now fill in the "et cetera," now that you've got the obvious ones out of the way. As long as Erik has already mentioned it (thank you very much), see my post from 3 years ago to see how this task quickly goes from simple to tricky to impossible: http://ops.ietf.org/lists/idn/idn.2002/msg00498.html -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sat Feb 19 09:09:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05250 for ; Sat, 19 Feb 2005 09:09:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2VBS-000Bj3-Qd for idn-data@psg.com; Sat, 19 Feb 2005 14:02:10 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2VBO-000Bae-BD for idn@ops.ietf.org; Sat, 19 Feb 2005 14:02:06 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1JE20SJ099734; Sat, 19 Feb 2005 09:02:00 -0500 Message-ID: <421746D7.4070102@vanderpoel.org> Date: Sat, 19 Feb 2005 06:01:59 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org CC: dam@icann.org Subject: [idn] RRP and language tags Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Removing unicode@unicode.org and adding dam@icann.org] Yesterday, it seemed like some people agreed with me that, in the general case, the language tag being passed in the RRP protocol is not just naming a character table to filter against, but, more generally, a set of rules that the registry applies to determine registerability. Ignoring for now whether we can decide that there is consensus on this issue, I'd like to explore the issues some more, and ask a few questions, if that's OK. First, the language tag is just a name, so in some sense it does not really matter *what* it is naming, whether that be a human language, a registry's table of characters, or a registry's set of rules. But if we can show that ISO 639 is not an adequate namespace, then we may wish to consider a new namespace. One reason that 639 might not be adequate is that some languages are used in more than one part of the world, and that usage may differ enough from one community to another that we want to assign two separate codes instead of a single 639 code. A very common way to go about this is to simply add a country code (ISO 3166). However, currently it seems like the trend is to have a number of sets of rules, one at each NIC. The .jp registry has a table and some rules, the .de registry has a table, and so on. Some organizations appear to be working together to unify their methods. China and Taiwan come to mind. This trend might lead one to think that the RRP tag should not be a language, but simply the name of a NIC or TLD or pair of TLDs. But this might be too restrictive. What if some organization or individual comes up with a set of rules that is desirable for a number of reasons, such as the inclusion of a large number of characters? Some registries may wish to allow registrars (and by extension, registrants) to specify the use of such a set of rules. This would argue for maximum flexibility in the RRP tag namespace. I.e. it should not be limited to 639 or to 639+3166 or to ccTLD name. It could just be a separate namespace, possibly with an IANA registry, similar to the numerous other namespaces registered there. Charsets come to mind, but there are many others. Such a new namespace would even allow for private agreements, which usually have names that start with "x-" in other IANA namespaces. Any thoughts on these ideas? And now for the questions: Where is this RRP spec? Is it an RFC? Which RRP document specifies the language tag we have been talking about? Do all of the registries use RRP? If not, what do they use? And do they have language tags? Thanks, Erik From owner-idn@ops.ietf.org Sat Feb 19 10:02:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09460 for ; Sat, 19 Feb 2005 10:02:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2W3W-000OCn-7f for idn-data@psg.com; Sat, 19 Feb 2005 14:58:02 +0000 Received: from [61.197.89.106] (helo=atreuscorp.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2W3U-000OCO-20 for idn@ops.ietf.org; Sat, 19 Feb 2005 14:58:00 +0000 Received: from edmontr3 ([172.16.0.235]) by atreuscorp.com (8.9.3/8.9.3) with SMTP id BAA18295; Sun, 20 Feb 2005 01:40:38 +0900 Message-ID: <025a01c51693$5f1e9310$eb0010ac@edmontr3> From: "Edmon Chung" To: "Erik van der Poel" , Cc: "Tina Dam" References: <421746D7.4070102@vanderpoel.org> Subject: Re: [idn] RRP and language tags Date: Sat, 19 Feb 2005 09:57:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,MIME_BASE64_BLANKS, MIME_BASE64_TEXT,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVyaWsgdmFuIGRlciBQb2Vs IiA8ZXJpa0B2YW5kZXJwb2VsLm9yZz4NCj4gQW5kIG5vdyBmb3IgdGhlIHF1ZXN0aW9uczogV2hl cmUgaXMgdGhpcyBSUlAgc3BlYz8gSXMgaXQgYW4gUkZDPyBXaGljaCANCj4gUlJQIGRvY3VtZW50 IHNwZWNpZmllcyB0aGUgbGFuZ3VhZ2UgdGFnIHdlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0Pw0K DQpUaGVyZSBpcyBhbiBSRkMgZm9yIFJSUDogMzYzMiwgYnV0IEkgYmVsaWV2ZSBpdCBtYXkgbm90 IGJlIHRoZSBtb3N0IHVwZGF0ZWQgdmVyc2lvbiBkdWUgdG8gc29tZSBhZGRpdGlvbmFsIGZlYXR1 cmVzIHRoYXQgVmVyaVNpZ24gaGFzIGFkZGVkLiAgSG93ZXZlciwgSSB3b3VsZCBsZXQgU2NvdHQv UGF0IHNwZWFrIHRvIGl0IG1vcmUgZGVmaW5pdGl2ZWx5Lg0KDQo+IERvIGFsbCBvZiB0aGUgcmVn aXN0cmllcyB1c2UgUlJQPyBJZiBub3QsIHdoYXQgZG8gdGhleSB1c2U/IEFuZCBkbyB0aGV5IA0K PiBoYXZlIGxhbmd1YWdlIHRhZ3M/DQoNCkVQUCAoRXh0ZW5zaWJsZSBQcm92aXNpb25pbmcgUHJv dG9jb2wpIGlzIHRoZSBJQ0FOTiBwcmVmZXJyZWQgcHJvdG9jb2wgZ29pbmcgZm9yd2FyZCBJIHdv dWxkIHNheSwgYnV0IGFnYWluLCBJIHdvdWxkIHJlYWxseSBkZWZlciB0byBUaW5hIGZvciBtb3Jl IGF1dGhvcml0YXRpdmUgcG9zaXRpb24uDQoNClRoZXJlIHdhcyBhbiBJRE4tb3Zlci1FUFAgQk9G IGhlbGQgZWFybGllciBpbiB0aGUgbGFzdCBJRVRGIGFuZCB0aGVyZSB3ZXJlIHNvbWUgcHJlc2Vu dGF0aW9ucyBkb25lIGR1cmluZyB0aGUgQ2FwZXRvd24gSUNBTk4gaW4gRGVjIDIwMDQuICBDdXJy ZW50bHkgd2UgYXJlIHRyeWluZyB0byBzZXR1cCBhIG1haWxpbmdsaXN0IHRvIGZ1cnRoZXIgZGlz Y3VzcyB0aGUgbWF0dGVyIGluIGZhY3QsIGFuZCB0aGUgbWF0dGVyIGhhcyBiZWVuIGluaXRpYXRl ZCBhbmQgaXMgd2l0aCB0aGUgQXBwcyBhcmVhIGRpcmVjdG9yIFRlZCBIYXJkaWUgYXQgdGhlIG1v bWVudC4NCg0KUGVyc29uYWxseSwgSSB0aGluayB0aGlzIGlzIGRlZmluaXRlbHkgYW4gaXRlbSB0 aGF0IHdlIHNob3VsZCB3b3JrIG9uIGFuZCBwcm92aWRlIGEgc3RhbmRhcmRpemVkIGZyYW1ld29y ayBmb3IuICBJbiBmYWN0IGR1cmluZyB0aGUgSUNBTk4gbWVldGluZ3MsIHRoZSBwcmVzZW50YXRp b25zIGF0IGNjTlNPIGFuZCBhdCB0aGUgUmVnaXN0cmFyIENvbnN0aXR1ZW5jeSB5aWVsZGVkIGdv b2QgcmVzdWx0cyBhbmQgaW50ZXJlc3QuICBUaGUgY2NOU08gYWxzbyByZXBvcnRlZCBzdXBwb3J0 IGZvciBlZmZvcnRzIHRvIHN0YW5kYXJkaXplIHRoZSBFUFAgZXh0ZW5zaW9uIGFwcHJvYWNoIGZv ciBJRE4uDQoNCkVkbW9u From owner-idn@ops.ietf.org Sat Feb 19 11:33:53 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17478 for ; Sat, 19 Feb 2005 11:33:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2XUK-000JT8-Cy for idn-data@psg.com; Sat, 19 Feb 2005 16:29:48 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2XUG-000JSm-Os for idn@ops.ietf.org; Sat, 19 Feb 2005 16:29:45 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1JGTaHb192490; Sat, 19 Feb 2005 11:29:37 -0500 Message-ID: <42176970.3050704@vanderpoel.org> Date: Sat, 19 Feb 2005 08:29:36 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org CC: dam@icann.org Subject: [idn] upstream and downstream References: <421746D7.4070102@vanderpoel.org> In-Reply-To: <421746D7.4070102@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Regarding the IDN spoofing issue, I'd like to offer the following analysis, and hope that people will point out anything that's missing. For IDN names, there are 2 different times: 1. registration time 2. lookup time At each of these times, we start with textual symbols, give them codes (Unicodes), perform nameprep and encode into punycode. After a lookup, we might also display the name for the user. There are other details and various cases to consider, but this is the big picture. These are the basic stages that a name progresses through. Now, the IDN spoofing issue is one of look-alikes. We can attack this look-alike problem by focussing on an early stage, an intermediate stage or a late stage. The terms often used for stages that progress from one end to another are upstream and downstream. If we were to try to solve the look-alike problem all the way upstream, we would focus on Unicode. This character encoding gives distinct codes to textual symbols that look similar or are even identical, in both form and function. Michel even admitted that many of the Latin letters in the Cyrillic block were added only to keep people from having to switch scripts midstring. So these characters are identical in appearance and use. Ignoring for the moment whether this is realistic, one way to solve the look-alike problem is to have Unicode get rid of these look-alikes. In Unicode parlance, it would then become a glyph encoding, rather than a character encoding. Going further downstream, we have nameprep. This is another possible place to solve the look-alike problem. We could have a new version of nameprep that maps homographs to base characters. I.e. the look-alikes are folded. After this kind of nameprepping, we have characters that all look different. Again, no statement about whether such a change to the spec is realistic. This is just an analysis. Downstream some more, we have the rules applied by the registry. The .jp registry seems to be well aware of the look-alike problem, and they have strict rules, with a well-defined table of characters to filter the name through. If the name contains characters outside that table, that name is rejected. Going all the way downstream at lookup time, we have the string that is displayed to the user. Various people have been suggesting various ways to display the look-alikes so that the end-user will notice when something phishy is going on. This concludes my analysis. It is rough, of course, but this is intended to be the big picture, and I hope it's complete. If this big picture is not complete, please point out what's missing. Having concluded my analysis, I will now discuss which solutions are realistic. As far as I'm concerned, Unicode is an immovable object. There is probably zero chance that anybody could talk them into getting rid of look-alikes. So what about nameprep? Should nameprep have chosen Unicode or some other character encoding? This part of nameprep is probably unchangeable. I doubt we could get consensus on switching nameprep from Unicode to some other encoding. But what about the other parts of nameprep? Would it be possible to add another kind of mapping to it, namely from homographs to base characters? This would be a rather large change, and might even require a new prefix (i.e. something other than xn-- to allow migration). I don't really know whether this kind of change is realistic. Next we have the registries. Kudos to .jp and all the others that carefully avoid look-alikes. But what about .com? As it turns out, in their current set-up, when VeriSign does not have a table for the requested language, the registry allows *any* Unicode to be registered. This is particularly egregious. They ought to fix this part, at least. Is VeriSign an immovable object? I don't know. However, even if VeriSign were to have tables for all the languages, we would still have a look-alike problem. Consider a Russian name that consists entirely of Latin homographs. One solution is to make the language tag available to the application, possibly via a new DNS record. This is just an example, but the application could then put an icon of the Russian flag next to the domain name or URI. An American user *might* then realize that something phishy is going on. (Or they might not notice the icon, or ignore it.) The app could put up a dialog with a warning. It could do that the first time. But this is not a seamless user experience. Most app vendors aim for seamless. Or the app could have different colors for different Unicode scripts. Or different colors for different language tags. They would do something special for the color-blind. But, to me, all this just seems like we are foisting the problem on the end-user. Why oh why should they see any of this? Or we could use heuristics, as Adam suggested, to try to detect phishyness. We could simply display the raw Punycode when the name is determined to be phishy. Maybe it's just me, but this is not very satisfying. Can't we solve the problem upstream? Erik From owner-idn@ops.ietf.org Sat Feb 19 16:26:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09141 for ; Sat, 19 Feb 2005 16:26:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2c0e-0009dx-DO for idn-data@psg.com; Sat, 19 Feb 2005 21:19:28 +0000 Received: from [68.168.78.44] (helo=mta13.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2c0b-0009dh-3l for idn@ops.ietf.org; Sat, 19 Feb 2005 21:19:25 +0000 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050219211923.QBBE7979.mta13.adelphia.net@DEWELL>; Sat, 19 Feb 2005 16:19:23 -0500 Message-ID: <005301c516c8$7bfd5f40$030aa8c0@DEWELL> From: "Doug Ewell" To: , "Unicode Mailing List" Cc: "Hans Aberg" , =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "Erik van der Poel" References: Subject: Re: [idn] IDN spoofing Date: Sat, 19 Feb 2005 13:17:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hans Aberg wrote: >>> Of cause we should minimize the risks for internet users of being >>> mislead. This could be done by equializing similar characters, >>> like Latin, Cyrillic and greek A, 0 and O, 1 and 1 etc, so that no >>> visual misleading should be possible. >> >> OK, now fill in the "et cetera," now that you've got the obvious ones >> out of the way. >> >> As long as Erik has already mentioned it (thank you very much), see >> my post from 3 years ago to see how this task quickly goes from >> simple to tricky to impossible: >> >> http://ops.ietf.org/lists/idn/idn.2002/msg00498.html > > If one does it that way, one quickly gets into trouble. But one > defines a map, which merges some characters for separating IDN's, > while retaining the original Unicode character set on the user level > on the input. Take a character set C, which might be a subset of > Unicode, and send the Unicode characters (or a suitable subset > thereof) into the set of finite sequence of C. Two IDN's will be > declared equal if mapped to the same character sequence. This map is > only used define which IDN's are viewed as equal. But one is still > free to use whatever Unicode sequences one wants. The map is used to > define an equivalence relation on the set of Unicode character > sequences, but does not in itself affect which Unicode sequences which > are admissible. That isn't the point. It doesn't matter if the mapping takes place at the character-encoding level or at some other level. The problem of determining which pairs of characters are confusable and should be folded together, and which pairs aren't and shouldn't, still remains to be solved. The point is that there is a large set of "semi-confusable" characters, for which it simply cannot be said conclusively that they "look alike" or "don't look alike." It depends on font, size, medium (paper vs. screen), and sometimes context. This is one of those problems for which a partial solution simply isn't good enough. And for something like IDNs, once you have decided on a mapping, you can never, ever change it. Otherwise you will have a domain name available for registration by customer A today, but a similar one not available to customer B six months later (or vice versa, A can't get it but B can). Either way, you have a lawsuit. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sat Feb 19 16:40:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09990 for ; Sat, 19 Feb 2005 16:40:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2cDv-000CLw-Ho for idn-data@psg.com; Sat, 19 Feb 2005 21:33:11 +0000 Received: from [68.168.78.199] (helo=mta9.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2cDu-000CIk-D4 for idn@ops.ietf.org; Sat, 19 Feb 2005 21:33:10 +0000 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050219213309.QLWA19760.mta9.adelphia.net@DEWELL>; Sat, 19 Feb 2005 16:33:09 -0500 Message-ID: <005a01c516ca$65d219c0$030aa8c0@DEWELL> From: "Doug Ewell" To: , "Unicode Mailing List" Cc: , =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= , "Erik van der Poel" References: <20050219172516.43142.qmail@web90109.mail.scd.yahoo.com> Subject: Re: [idn] IDN spoofing Date: Sat, 19 Feb 2005 13:31:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Philippe Verdy wrote: > The bad thing about your argument is that you are trying to mix > uppercase and uppercase letters. But for IDN, only lowercase letters > are really made distinct and encodable, as uppercase letters are case > folded to lowercase. So let's just concentrate on the set of letters > that really are distinct in lowercase because this is the form where > DNS servers will make distinctions in ASCII letters. Fine, get rid of all the examples that involve uppercase. The problem is still there: iι pρ uυ vν wω yγ -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sat Feb 19 16:46:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10305 for ; Sat, 19 Feb 2005 16:46:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2cL5-000EN7-UF for idn-data@psg.com; Sat, 19 Feb 2005 21:40:35 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2cL3-000EMh-A3 for idn@ops.ietf.org; Sat, 19 Feb 2005 21:40:33 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2cL0-0001fa-00 for ; Sat, 19 Feb 2005 13:40:30 -0800 Date: Sat, 19 Feb 2005 21:40:29 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] upstream and downstream Message-ID: <20050219214029.GA5457~@nicemice.net> Reply-To: IETF idn working group References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42176970.3050704@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > For IDN names, there are 2 different times: > > 1. registration time > 2. lookup time > > At each of these times, we start with textual symbols, give them codes > (Unicodes), perform nameprep and encode into punycode. After a lookup, > we might also display the name for the user. Display time is independent of lookup time. For example, the domain names in the From: field of an incoming message is displayed, but not looked up. The mail application never looks up the name, even if a reply is sent; a separate application (the MTA) does that. In a browser, I might hover over a link before deciding whether to follow it, so that I can see the domain name. The domain name is not looked up at that point. We could consider advising all applications to start doing DNS lookups on such occasions, just to get extra meta-info (like language tags) to help display the name, but that seems too drastic, and there are still situations where it's nice to be able to use applications offline. > As far as I'm concerned, Unicode is an immovable object. There is > probably zero chance that anybody could talk them into getting rid of > look-alikes. Certainly. The upheaval would be tremendously prohibitive. > But what about the other parts of nameprep? Would it be possible > to add another kind of mapping to it, namely from homographs to > base characters? This would be a rather large change, and might > even require a new prefix (i.e. something other than xn-- to allow > migration). It would certainly need a new prefix. Also, names that get transported in ACE form and converted back to Unicode for display would probably take on a ransom-note appearance when single-script strings get nameprepped into mixed-script strings. > I don't really know whether this kind of change is realistic. I think not. > But, to me, all this just seems like we are foisting the problem on > the end-user. Why oh why should they see any of this? You might as well ask why they should see domain names at all. Maybe there's a way to abstract domain names out of the users' view altogether, but until then, if users are going to see domain names, they want to be able to tell whether the name they see is the name they think they see. > We could simply display the raw Punycode when the name is determined > to be phishy. Maybe it's just me, but this is not very satisfying. The name can be flagged by displaying the Punycode, or by using a bright color, or reverse video, or whatever. As someone already suggested, the ability to easily switch the display between the ACE and non-ACE forms would be helpful. > Can't we solve the problem upstream? We don't know how many misleading names have already been registered under .com and .net, so I don't see how we can completely solve the problem upstream. AMC From owner-idn@ops.ietf.org Sat Feb 19 17:24:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13570 for ; Sat, 19 Feb 2005 17:24:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2cuf-000Myg-D3 for idn-data@psg.com; Sat, 19 Feb 2005 22:17:21 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2cue-000MyT-HN for idn@ops.ietf.org; Sat, 19 Feb 2005 22:17:20 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2cud-0001r7-00 for ; Sat, 19 Feb 2005 14:17:19 -0800 Date: Sat, 19 Feb 2005 22:17:19 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: <20050219221719.GB5457~@nicemice.net> Reply-To: IETF idn working group Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Here's an idea for a quick-and-dirty enhancement to existing applications: Rather than disable IDNA entirely (which is quick but too dirty), or flag all IDNs (almost as quick but still too dirty), just flag all IDNs in .com and .net. This would be significantly less damaging to IDN deployment (which could proceed unhindered in the other TLDs, particularly the ccTLDs), but is still extremely simple and could be rolled out immediately while more sophisticated heuristics are developed. AMC From owner-idn@ops.ietf.org Sat Feb 19 17:28:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13935 for ; Sat, 19 Feb 2005 17:28:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2czN-000Nvb-Fy for idn-data@psg.com; Sat, 19 Feb 2005 22:22:13 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2czM-000NvN-4O for idn@ops.ietf.org; Sat, 19 Feb 2005 22:22:12 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1JMLipY231786; Sat, 19 Feb 2005 17:21:44 -0500 Message-ID: <4217BBF7.1080906@vanderpoel.org> Date: Sat, 19 Feb 2005 14:21:43 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell CC: idn@ops.ietf.org, Unicode Mailing List , Hans Aberg , =?UTF-8?B?S2VsZCBKw7hybiBTaW1vbnNlbg==?= Subject: Re: [idn] IDN spoofing References: <005301c516c8$7bfd5f40$030aa8c0@DEWELL> In-Reply-To: <005301c516c8$7bfd5f40$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug, I agree with a lot of what you are saying (particularly, the "semi-confusables"), but please allow me to counter you argument below, just for the sake of the argument. I am not saying that this is my "final" opinion. (People will have noticed that I change my opinion a lot. Sorry about that. :-) Doug Ewell wrote: > This is one of those problems for which > a partial solution simply isn't good enough. Maybe this is one of those problems for which *no* solution simply isn't good enough? I mean, I'll start with the Arial font found in Windows. Isn't it true that its cmap maps some characters to the same glyph index? And, even if someone tries to point out that Arial is a commercial product that someone may have been trying to get out the door quickly, thereby taking unjustified shortcuts, I'll point out that Michel Suignard himself (long-time Unicoder) already admitted that: # No languages used in the former soviet union should require a mix of # latin and cyrillic in a single dns label. # Unicode contains many latin homographs in the Cyrillic block exactly for # that reason, to avoid mixing the two scripts in a single word. It is # unfortunate that the exact visual match is now haunting us. However it # should not be used as a rationale to accept registration of mixed # Cyrillic/Latin labels by tld registries. This is from: ftp://ops.ietf.org/pub/lists/idn.current Am I now going to see some senior Unicoders try to backpedal on these comments? :-) I hope not. A couple of senior Unicoders have already indicated that they are seriously considering this homograph issue, and kudos to them! > And for something like IDNs, once you have decided on a mapping, you can > never, ever change it. Otherwise you will have a domain name available > for registration by customer A today, but a similar one not available to > customer B six months later (or vice versa, A can't get it but B can). > Either way, you have a lawsuit. And that's how it should be. PayPal should sue those that registered fake paypal.com names! :-) Well, PayPal will notice that some or all of them are just there to start this very discussion, and hopefully won't sue those poor engineers... More to the point, this ACE thing (ASCII Compatible Encoding) has a long history of incompatible prefixes. See section 5 of: http://ietf.org/rfc/rfc3490.txt As is the case in any network protocol migration endeavor, you may be able to take advantage of such incompatibilities to assist in (indeed, *allow*) migration. The critical thing is to have the systems support both the old and the new during the transition period. For example, a registry might support lookups from both old and new clients during the transition. But of course, it will be very difficult (if not impossible) to delete some of the names that are determined to be (deliberate or accidental) spoofs of other (hopefully legitimate) names. Some of these parties have the resources to sue each other, but others are just, say, individuals who happen to be caught in the crossfire. Is it fair to delete their registrations? And even if it is, will the registries even bother to go through all this work? Finally, am I answering my own questions? :-) Erik From owner-idn@ops.ietf.org Sat Feb 19 18:31:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19710 for ; Sat, 19 Feb 2005 18:31:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2dyY-000Coz-Kj for idn-data@psg.com; Sat, 19 Feb 2005 23:25:26 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2dyW-000CoT-In for idn@ops.ietf.org; Sat, 19 Feb 2005 23:25:24 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1JNPHSJ089012; Sat, 19 Feb 2005 18:25:18 -0500 Message-ID: <4217CADD.1010500@vanderpoel.org> Date: Sat, 19 Feb 2005 15:25:17 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <20050219221719.GB5457~@nicemice.net> In-Reply-To: <20050219221719.GB5457~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit These ideas have been considered by Mozilla: http://weblogs.mozillazine.org/gerv/archives/007556.html However, Mozilla's IDN market share may not be as big as the others', so its decision may not affect IDN deployment much. MSIE doesn't support IDN to begin with. There are some plug-ins for MSIE to support IDN, so their decision might have more effect than Mozilla's: http://support.microsoft.com/?kbid=842848 Let me point out that one of those plug-ins is made by VeriSign itself. Since VeriSign is such a big company, their IDN plug-in may have the largest market share. I haven't seen any numbers. But what will VeriSign decide to do in their plug-in in response to this IDN spoofing issue? I think I agree with you, however, that the more sophisticated heuristics can be developed later. Erik Adam M. Costello wrote: > Here's an idea for a quick-and-dirty enhancement to existing > applications: Rather than disable IDNA entirely (which is quick but > too dirty), or flag all IDNs (almost as quick but still too dirty), > just flag all IDNs in .com and .net. This would be significantly less > damaging to IDN deployment (which could proceed unhindered in the other > TLDs, particularly the ccTLDs), but is still extremely simple and could > be rolled out immediately while more sophisticated heuristics are > developed. From owner-idn@ops.ietf.org Sat Feb 19 18:39:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19950 for ; Sat, 19 Feb 2005 18:39:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2e6e-000EZF-Ta for idn-data@psg.com; Sat, 19 Feb 2005 23:33:48 +0000 Received: from [68.168.78.202] (helo=mta10.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2e6c-000EZ0-SV for idn@ops.ietf.org; Sat, 19 Feb 2005 23:33:46 +0000 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050219233345.WJPU5834.mta10.adelphia.net@DEWELL>; Sat, 19 Feb 2005 18:33:45 -0500 Message-ID: <007601c516db$386c55c0$030aa8c0@DEWELL> From: "Doug Ewell" To: "IETF idn working group" Cc: References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> Subject: Re: [idn] upstream and downstream Date: Sat, 19 Feb 2005 15:32:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > In a browser, I might hover over a link before deciding whether to > follow it, so that I can see the domain name. The domain name is not > looked up at that point. and later: >> We could simply display the raw Punycode when the name is determined >> to be phishy. Maybe it's just me, but this is not very satisfying. > > The name can be flagged by displaying the Punycode, or by using a > bright color, or reverse video, or whatever. As someone already > suggested, the ability to easily switch the display between the ACE > and non-ACE forms would be helpful. What about combining these two thoughts, and displaying the Punycode in a tooltip (or elsewhere) when the user hovers over the domain name? I realize that doesn't solve the problem for people who are *expecting* a URL with non-ASCII characters, but it's a start. It could be implemented immediately in any IDN-aware browser, with no architectural changes anywhere. Apologies if someone already proposed this in one of the 278,000 previous messages on this topic. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sat Feb 19 18:51:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20886 for ; Sat, 19 Feb 2005 18:51:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2eGk-000H4F-Fu for idn-data@psg.com; Sat, 19 Feb 2005 23:44:14 +0000 Received: from [68.168.78.205] (helo=mta11.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2eGj-000H40-JN for idn@ops.ietf.org; Sat, 19 Feb 2005 23:44:13 +0000 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050219234412.RAIY23187.mta11.adelphia.net@DEWELL>; Sat, 19 Feb 2005 18:44:12 -0500 Message-ID: <007b01c516dc$ac3b22a0$030aa8c0@DEWELL> From: "Doug Ewell" To: "Unicode Mailing List" , Cc: "Erik van der Poel" , "Hans Aberg" , =?utf-8?Q?Keld_J=C3=B8rn_Simonsen?= References: <005301c516c8$7bfd5f40$030aa8c0@DEWELL> <4217BBF7.1080906@vanderpoel.org> Subject: Re: [idn] IDN spoofing Date: Sat, 19 Feb 2005 15:42:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: >> This is one of those problems for which >> a partial solution simply isn't good enough. > > Maybe this is one of those problems for which *no* solution simply > isn't good enough? Maybe. > I mean, I'll start with the Arial font found in Windows. Isn't it true > that its cmap maps some characters to the same glyph index? I wouldn't know. Maybe one of the font guys does. > ... I'll point out that Michel Suignard himself > (long-time Unicoder) already admitted that: > ... > # Unicode contains many latin homographs in the Cyrillic block exactly > # for that reason, to avoid mixing the two scripts in a single word... > ... > Am I now going to see some senior Unicoders try to backpedal on these > comments? :-) I doubt it. Having Cyrillic text be all-Cyrillic and not Cyrillic-mixed-with-Latin is a good thing. Being able to surf to the Web site you expect and not to some spoofed variant is also a good thing. Reconciling these two is not necessarily an easy thing. > Well, PayPal will notice that some or all of them are just there to > start this very discussion, and hopefully won't sue those poor > engineers... Some PayPal people (say that five times fast) will probably resent the fact that PayPal was chosen as an example. Others, probably more astute, will see it as a testament to their high profile and success. > Finally, am I answering my own questions? :-) Maybe, but at least they're being asked. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sat Feb 19 19:14:00 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22318 for ; Sat, 19 Feb 2005 19:14:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2edk-000Ncv-PW for idn-data@psg.com; Sun, 20 Feb 2005 00:08:00 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2edj-000Nc2-Bz for idn@ops.ietf.org; Sun, 20 Feb 2005 00:07:59 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1K07sHb186616; Sat, 19 Feb 2005 19:07:55 -0500 Message-ID: <4217D4DA.4000908@vanderpoel.org> Date: Sat, 19 Feb 2005 16:07:54 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> In-Reply-To: <20050219214029.GA5457~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > Display time is independent of lookup time. Good point. I did consider that, but I deliberately left it out of my "big picture". Perhaps I should have included it... > Also, names that get transported > in ACE form and converted back to Unicode for display would probably > take on a ransom-note appearance when single-script strings get > nameprepped into mixed-script strings. Over the years, the fonts seem to have grown, to include more and more of Unicode. A long time ago, in X Windows, it would definitely have looked like a ransom note. But these days, in Windows and even X Windows with larger fonts, it looks a lot better. So good, in fact, that it's hard to tell the difference between the homographs. (I was the chief architect of the multilingual font engines for the Windows and Unix versions of Mozilla. This is one area I'm really familiar with.) Re: nameprep spec change: >>I don't really know whether this kind of change is realistic. > > I think not. Would you care to elaborate? > You might as well ask why they should see domain names at all. > Maybe there's a way to abstract domain names out of the users' view > altogether, but until then, if users are going to see domain names, they > want to be able to tell whether the name they see is the name they think > they see. But then don't you think it's at least a little unfortunate that (a) Unicode chose to include duplicates and/or (b) nameprep chose to use Unicode? Previously, users only had to squint at ASCII 1 vs l. Now, with IDN, it has been taken to a whole different level. They have to endure colored letters that look identical but have been colored to indicate that their character codes are different. Most users don't even understand what character codes are. So I still feel that it's unfortunate that we now end up having to confuse users. Of course, it's not clear that there will be very many of these phishing attempts, in which case the user will almost never see these colors. We may be blowing this issue out of proportion. Real phishers may find other, more devious ways to fool the user. >>Can't we solve the problem upstream? > > We don't know how many misleading names have already been registered > under .com and .net, so I don't see how we can completely solve the > problem upstream. Actually, I've been thinking that one could write a program that determines which pairs of Unicode characters have been assigned the same glyph index in TrueType fonts on Windows. A registry could then check all the IDNs in their set to see which ones contain only ASCII homographs and ASCIIs. If there are only a few misleading names, they might be able to delete them by contacting their owners, etc. If there are many, well, I don't know. But one thing these registries could do now or quite soon is to install some heuristic filters to try to stem the influx of bogosities. One can only hope... Erik From owner-idn@ops.ietf.org Sat Feb 19 19:26:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22886 for ; Sat, 19 Feb 2005 19:26:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2erp-0001HL-0z for idn-data@psg.com; Sun, 20 Feb 2005 00:22:33 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2erm-0001Fv-OU for idn@ops.ietf.org; Sun, 20 Feb 2005 00:22:31 +0000 Received: (qmail 89931 invoked by uid 0); 20 Feb 2005 08:25:34 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.060648 secs); 20 Feb 2005 00:25:34 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.060648 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 20 Feb 2005 08:25:28 +0800 Message-ID: <4217D839.7040502@dready.org> Date: Sun, 20 Feb 2005 11:22:17 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <20050219221719.GB5457~@nicemice.net> In-Reply-To: <20050219221719.GB5457~@nicemice.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This sounds like a fairly good idea, but some "commercial" ccTLDs are actually very liberal in their IDN implementations as well. An example would be nic.tm, which permits any Unicode character allowed by IDNA. There are others, but I can't remember. wil. Adam M. Costello wrote: >Here's an idea for a quick-and-dirty enhancement to existing >applications: Rather than disable IDNA entirely (which is quick but >too dirty), or flag all IDNs (almost as quick but still too dirty), >just flag all IDNs in .com and .net. This would be significantly less >damaging to IDN deployment (which could proceed unhindered in the other >TLDs, particularly the ccTLDs), but is still extremely simple and could >be rolled out immediately while more sophisticated heuristics are >developed. > >AMC > > > > From owner-idn@ops.ietf.org Sat Feb 19 23:32:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07190 for ; Sat, 19 Feb 2005 23:32:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2iav-0005Gj-DR for idn-data@psg.com; Sun, 20 Feb 2005 04:21:21 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2iau-0005GX-7i for idn@ops.ietf.org; Sun, 20 Feb 2005 04:21:20 +0000 Received: from lns-p19-1-idf-82-251-85-156.adsl.proxad.net ([82.251.85.156] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D2ias-0006gO-Ny for idn@ops.ietf.org; Sat, 19 Feb 2005 20:21:19 -0800 Message-Id: <6.1.2.0.2.20050220023803.039482a0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 20 Feb 2005 05:21:14 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] upstream and downstream Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On 17:29 19/02/2005, Erik van der Poel said: >For IDN names, there are 2 different times: >1. registration time >2. lookup time You do not quote the two most important ones: 0. standardization 3. the user click. The standardization will most probably adapt through a grassroots process. The problem today is not what the users read, but the difference between what the users do and what they believe they do when they click. As I told you in a more detailed comment, you will no change the Unicode system for the reasons Doug Ewell explained. But you can conceive a namemap function which will transcode the characters of the URL that the user clicks into the characters he thinks he clicks/he wants to click. Obviously you can run the function twice (the first time to indicate where a change would occur if clicked). 1. there is no problem then to signal that a character has been changed, or to have a choice if there are several possibilities 2. if the correction works and reaches paypal, there is no problem. Otherwise it will not work. So the security is protected. This permits the user to decide of his own security. This is an anti-virus, an antispam approach. jfc From owner-idn@ops.ietf.org Sun Feb 20 00:34:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10741 for ; Sun, 20 Feb 2005 00:34:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2jdJ-000L5E-A6 for idn-data@psg.com; Sun, 20 Feb 2005 05:27:53 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2jdH-000L51-RZ for idn@ops.ietf.org; Sun, 20 Feb 2005 05:27:52 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1K5RoJR030493 for ; Sun, 20 Feb 2005 14:27:50 +0900 Message-ID: <42181FD5.3070608@lsb.org> Date: Sun, 20 Feb 2005 14:27:49 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] space-like unicode char Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_05, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You can paste this html/javascript codelet to an html file in your webserver and see in your MSIE brower. You will see "www.microsoft.com" isolated in the addressbar from the "mozilla.org" domain suffix. Fortunately, you will see blank space (no phishing page) if you have recent IE patch. This won't work in firefox 1.x which strips off those special chars for unknow reasons before sending to the address bar. U+1160 is a space-like char and even stringprep/nameprep does not filter it out because the char is not for punctuational purpose. U+1160 is just one example, and i guess there may be many alternatives that can be used as blank char alternatives. U+1160 in the above example is placed in the 3rd level domain name label, over which .org registry cannot impose any regulations. Soobok Lee From owner-idn@ops.ietf.org Sun Feb 20 01:15:14 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13170 for ; Sun, 20 Feb 2005 01:15:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2kGJ-0005Mw-NY for idn-data@psg.com; Sun, 20 Feb 2005 06:08:11 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2kGI-0005Mh-OC for idn@ops.ietf.org; Sun, 20 Feb 2005 06:08:10 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1K688JR003494; Sun, 20 Feb 2005 15:08:09 +0900 Message-ID: <42182948.1070403@lsb.org> Date: Sun, 20 Feb 2005 15:08:08 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soobok Lee CC: idn@ops.ietf.org Subject: Re: [idn] space-like unicode char References: <42181FD5.3070608@lsb.org> In-Reply-To: <42181FD5.3070608@lsb.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_05, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit For those who do not have a webserver: plz copy this url into your MSIE addressbar . javascript:void(window.open(unescape("http://www.microsoft.com%u2044%u1160%u1160.uni.cc/"),"_self")) You will see an error page if you have recent MSIE patch. Soobok Soobok Lee wrote: > You can paste this html/javascript codelet to an html file in your > webserver and see in your MSIE brower. > You will see "www.microsoft.com" isolated in the addressbar from the > "mozilla.org" domain suffix. > Fortunately, you will see blank space (no phishing page) if you have > recent IE patch. > This won't work in firefox 1.x which strips off those special chars > for unknow reasons before sending to > the address bar. > > > > U+1160 is a space-like char and even stringprep/nameprep does not > filter it out because > the char is not for punctuational purpose. > U+1160 is just one example, and i guess there may be many alternatives > that can be > used as blank char alternatives. > > U+1160 in the above example is placed in the 3rd level domain name label, > over which .org registry cannot impose any regulations. > > Soobok Lee From owner-idn@ops.ietf.org Sun Feb 20 01:26:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13735 for ; Sun, 20 Feb 2005 01:26:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2kTw-0008wp-MQ for idn-data@psg.com; Sun, 20 Feb 2005 06:22:16 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2kTu-0008pt-Eh for idn@ops.ietf.org; Sun, 20 Feb 2005 06:22:14 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1K6MCJR005207; Sun, 20 Feb 2005 15:22:12 +0900 Message-ID: <42182C94.8090909@lsb.org> Date: Sun, 20 Feb 2005 15:22:12 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soobok Lee CC: idn@ops.ietf.org Subject: Re: [idn] space-like unicode char References: <42181FD5.3070608@lsb.org> <42182948.1070403@lsb.org> In-Reply-To: <42182948.1070403@lsb.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The real problem comes when "com.%1160%1160*" is punycoded into "xn--blah". ( You can increase the number of "%1160"s until 63-char limit is reached) "www.microsoft.xn--blah.uni.cc" is decoded and displayed in the native form on the MSIE/i-Nav or Firefox 1.x. what would you see on the address bar and in the webpage? The legitimate ASCII url http://www.microsoft.xn--blah.uni.cc would succeed to be resolved and deliver the phishing page, while the end user see "www.microsoft.com" isolated in the beginning part of the address bar. the end user may not see "uni.cc" part if the frame width of the MSIE window instance is narrow enough to hide ".uni.cc" . Soobok Soobok Lee wrote: >For those who do not have a webserver: plz copy this url into your MSIE >addressbar . > >javascript:void(window.open(unescape("http://www.microsoft.com%u2044%u1160%u1160.uni.cc/"),"_self")) > >You will see an error page if you have recent MSIE patch. > >Soobok > >Soobok Lee wrote: > > > >>You can paste this html/javascript codelet to an html file in your >>webserver and see in your MSIE brower. >>You will see "www.microsoft.com" isolated in the addressbar from the >>"mozilla.org" domain suffix. >>Fortunately, you will see blank space (no phishing page) if you have >>recent IE patch. >>This won't work in firefox 1.x which strips off those special chars >>for unknow reasons before sending to >>the address bar. >> >> >> >>U+1160 is a space-like char and even stringprep/nameprep does not >>filter it out because >>the char is not for punctuational purpose. >>U+1160 is just one example, and i guess there may be many alternatives >>that can be >>used as blank char alternatives. >> >>U+1160 in the above example is placed in the 3rd level domain name label, >>over which .org registry cannot impose any regulations. >> >>Soobok Lee >> >> > > > > > From owner-idn@ops.ietf.org Sun Feb 20 05:12:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19209 for ; Sun, 20 Feb 2005 05:12:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2nw3-000AGH-6a for idn-data@psg.com; Sun, 20 Feb 2005 10:03:31 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2nw1-000AFg-90 for idn@ops.ietf.org; Sun, 20 Feb 2005 10:03:29 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2nw0-0004Zl-00 for ; Sun, 20 Feb 2005 02:03:28 -0800 Date: Sun, 20 Feb 2005 10:03:28 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: <20050220100328.GA14603~@nicemice.net> Reply-To: IETF idn working group References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217D839.7040502@dready.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk William Tan wrote: > some "commercial" ccTLDs are actually very liberal in their IDN > implementations as well. An example would be nic.tm, which permits > any Unicode character allowed by IDNA. Yes, and I supposed they should be added to the blacklist as they are discovered, but I think getting the Verisign TLDs (.com and .net) into the blacklist will accomplish most of the benefit to be had from this approach. It's not like the phishers can move all their attacks to .tm after they get shut out of .com and .net, because there aren't nearly as many targets in .tm. How many users have sensitive trust relationships with sites in .tm (and .nu, etc)? AMC From owner-idn@ops.ietf.org Sun Feb 20 06:15:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23442 for ; Sun, 20 Feb 2005 06:15:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2owm-000PZ9-FD for idn-data@psg.com; Sun, 20 Feb 2005 11:08:20 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2owk-000PYq-Hr for idn@ops.ietf.org; Sun, 20 Feb 2005 11:08:18 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2owk-0004rp-00 for ; Sun, 20 Feb 2005 03:08:18 -0800 Date: Sun, 20 Feb 2005 11:08:17 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050220110817.GD14603~@nicemice.net> Reply-To: IETF idn working group References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4217D4DA.4000908@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > > > I don't really know whether this kind of change is realistic. > > > > I think not. > > Would you care to elaborate? Partly because of the ransom-note problem, partly because of the deployment problem (new ACE prefix), but even if we dismiss those, there's still the problem of characters that are supposed to use different glyphs that are only slightly different and therefore easily confusable. So we'd be paying a fairly high cost (changing Nameprep) in return for a disappointing benefit. > don't you think it's at least a little unfortunate that (a) Unicode > chose to include duplicates and/or (b) nameprep chose to use Unicode? See Doug Ewell's post about how there's no good place to draw the line for what counts as a "duplicate". I don't think a different string preparation or a different universal character set could have made the situation a lot better in this regard; the scripts and characters themselves (independent of any encoding) have too many shades of similarity and distinction. We can't limit ourselves to a set of clearly distinguishable characters (some registries can, but a browser can't), so we need to resort to other approaches, like looking at the combinations of characters. AMC From owner-idn@ops.ietf.org Sun Feb 20 06:31:12 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24348 for ; Sun, 20 Feb 2005 06:31:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2pEm-0003t7-58 for idn-data@psg.com; Sun, 20 Feb 2005 11:26:56 +0000 Received: from [203.117.75.21] (helo=red-aura.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2pEj-0003st-RO for idn@ops.ietf.org; Sun, 20 Feb 2005 11:26:54 +0000 Received: (qmail 50190 invoked from network); 20 Feb 2005 11:29:57 -0000 Received: from dhcp-apricot-77-249.kyoto.apricot.net (HELO ?202.13.77.249?) (jseng@202.13.77.249) by red-aura.com with RC4-SHA encrypted SMTP; 20 Feb 2005 11:29:57 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF idn working group From: James Seng Subject: [idn] Fwd: Slash-like mark problem Date: Sun, 20 Feb 2005 19:26:55 +0800 X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit try again. Begin forwarded message: > From: James Seng > Date: 20 Feb 2005 PM 06:08:39 > To: IETF idn working group > Subject: Fwd: Slash-like mark problem > > this was demostrated to me just now. basically, the problem is U+2215, > a slash-like mathematical symbol. > > this problem will not be solved even by registration policy because it > can be done on 3rd or 4th level. > > james > > Begin forwarded message: > >> From: Yoshiro YONEYA >> Date: 20 Feb 2005 PM 05:51:47 >> To: james@seng.cc >> Subject: Slash-like mark problem >> >> Slash-like >> >> http://bugbug.cocolog-nifty.com∕info.nekodama.com/icons/ >> nekodama64b.gif >> >> http://member.wide.ad.jp/~fujiwara/test.html > From owner-idn@ops.ietf.org Sun Feb 20 06:35:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24714 for ; Sun, 20 Feb 2005 06:35:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2pJt-00057U-1S for idn-data@psg.com; Sun, 20 Feb 2005 11:32:13 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2pJr-000577-7L for idn@ops.ietf.org; Sun, 20 Feb 2005 11:32:11 +0000 Received: (qmail 50967 invoked by uid 0); 20 Feb 2005 19:35:14 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.114928 secs); 20 Feb 2005 11:35:14 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.114928 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 20 Feb 2005 19:35:13 +0800 Message-ID: <4218752F.5020806@dready.org> Date: Sun, 20 Feb 2005 22:31:59 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> In-Reply-To: <20050220100328.GA14603~@nicemice.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >Yes, and I supposed they should be added to the blacklist as they are >discovered, but I think getting the Verisign TLDs (.com and .net) into >the blacklist will accomplish most of the benefit to be had from this >approach. It's not like the phishers can move all their attacks to .tm >after they get shut out of .com and .net, because there aren't nearly as >many targets in .tm. How many users have sensitive trust relationships >with sites in .tm (and .nu, etc)? > > True. If Verisign drops support for languages for which they have no tables, and deal with the potential phishing attempts already in the registry, their TLD can then be removed from the blacklist. Likewise for whoever gets .net next. wil. From owner-idn@ops.ietf.org Sun Feb 20 06:56:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26114 for ; Sun, 20 Feb 2005 06:56:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2peX-000BTj-CK for idn-data@psg.com; Sun, 20 Feb 2005 11:53:33 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2peW-000BTS-2T for idn@ops.ietf.org; Sun, 20 Feb 2005 11:53:32 +0000 Received: (qmail 53357 invoked by uid 0); 20 Feb 2005 19:56:35 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.766735 secs); 20 Feb 2005 11:56:35 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.766735 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 20 Feb 2005 19:56:34 +0800 Message-ID: <42187A30.3060207@dready.org> Date: Sun, 20 Feb 2005 22:53:20 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Seng CC: IETF idn working group Subject: Re: [idn] Fwd: Slash-like mark problem References: <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> In-Reply-To: <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> >> this was demostrated to me just now. basically, the problem is >> U+2215, a slash-like mathematical symbol. > This makes a strong case for application-level filtering. AMC's blacklist will fail here, as any TLD can be used to exploit this. Apps will have to start detecting character properties such as symbol and punctuations (which I guess would be allowed by some TLD's IDN roll-out including VGRS's). wil. [gone phishing with U+2215] From owner-idn@ops.ietf.org Sun Feb 20 08:44:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03091 for ; Sun, 20 Feb 2005 08:44:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2rJp-000Cda-EV for idn-data@psg.com; Sun, 20 Feb 2005 13:40:17 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2rJn-000CYA-2n for idn@ops.ietf.org; Sun, 20 Feb 2005 13:40:15 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2rJm-0005Wx-00 for ; Sun, 20 Feb 2005 05:40:14 -0800 Date: Sun, 20 Feb 2005 13:40:14 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Fwd: Slash-like mark problem Message-ID: <20050220134014.GE14603~@nicemice.net> Reply-To: IETF idn working group References: <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> <42187A30.3060207@dready.org> <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42187A30.3060207@dready.org> <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk > http://bugbug.cocolog-nifty.com∕info.nekodama.com/icons/ > nekodama64b.gif > > http://member.wide.ad.jp/~fujiwara/test.html > > This makes a strong case for application-level filtering. AMC's > blacklist will fail here, as any TLD can be used to exploit this. Indeed. If only domain names were big-endian like newsgroup names, IP address literals, and pathnames, this wouldn't be a problem (and they'd sort better). I've always wondered why domain names were different. If only the IDN working group had chosen to distinguish internationalized host names (which would allow only certain Unicode categories) from internationalized domain names (which allow all visible characters) analogous to the distiction between traditional host names (which allow only ASCII letters, digits, and hyphen) and traditional domain names (which allow all ASCII characters)... (I regret having been unable to persude people on this point. If only I had forseen this slash-homograph attack, maybe that would have been persuasive, but back then people might still have believed that the registries could be counted on to take care of it. I think maybe I even believed it.) > Apps will have to start detecting character properties such as symbol > and punctuations Apparently so. Here is my straw man proposal from three years ago: ---quote--- The Unicode character database classifies each character as belonging to exactly one of the following broad classes: L: letter M: mark N: number P: punctuation S: symbol Z: separator C: other We can start by examining which of these classes of ASCII characters are allowed in ASCII host labels. L: 52 exist, all are allowed M: 0 exist N: 10 exist, all are allowed P: 23 exist, only hyphen-minus is allowed S: 9 exist, none are allowed Z: 1 exists, it is not allowed C: 33 exist, none are allowed We can trivially extend these results to form a simple rule covering the entire Unicode repertoire, except that we have no precedent for class M. Since characters in class M tend to be things like diacritics, they should be allowed. So the proposed rule is: All characters in classes L (letter), M (mark), and N (number) are allowed, and U+002D (hyphen-minus) is also allowed. Everything else is forbidden. Notice that there is no conflict with Nameprep, because Nameprep does not prohibit any characters in classes L, M, or N. If we were to adopt this definition of internationalized host name, it would best be understood as an amendment of ToASCII step 3 (which checks host name restrictions if applicable), tightening substep 3a from: (a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. to: (a) Verify that the sequence contains only host code points; that is, U+002D (hyphen-minus) and code points classified as L (letter), M (mark), or N (number). See appendix ? for an enumeration of host code points. Or maybe the enumeration would go in Nameprep, or in a separate document that defines internationalized host names. ---unquote--- AMC From owner-idn@ops.ietf.org Sun Feb 20 09:14:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04666 for ; Sun, 20 Feb 2005 09:14:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2rm4-000L2M-6l for idn-data@psg.com; Sun, 20 Feb 2005 14:09:28 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2rm3-000L27-CW for idn@ops.ietf.org; Sun, 20 Feb 2005 14:09:27 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D2rm2-0005gQ-00 for ; Sun, 20 Feb 2005 06:09:26 -0800 Date: Sun, 20 Feb 2005 14:09:26 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] Fwd: Slash-like mark problem Message-ID: <20050220140926.GA21531~@nicemice.net> Reply-To: IETF idn working group References: <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> <42187A30.3060207@dready.org> <990a895c69218e44e321a0bd88dc8ea1@pobox.org.sg> <20050220134014.GE14603~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050220134014.GE14603~@nicemice.net> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk I wrote: > Here is my straw man proposal from three years ago: That proposal proposed to alter ToASCII back when it was still being developed. It's too late for that now. If this Unicode category filter is resurrected, it would have to be used differently than I originally envisioned. It would have to be used to deprecate, but not disqualify, some IDNs from use as host names, For example, we could say that domain names containing characters outside classes L, M, N, and hyphen-minus should not be used as host names (which implies that they should not be used in URIs, IRIs, and email addresses), but if they are used as host names, applications must honor them but should display them in ASCII form or in some sort of warning mode. AMC From owner-idn@ops.ietf.org Sun Feb 20 09:16:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04802 for ; Sun, 20 Feb 2005 09:16:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2rqM-000Lyi-03 for idn-data@psg.com; Sun, 20 Feb 2005 14:13:54 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2rqJ-000LyU-Rr for idn@ops.ietf.org; Sun, 20 Feb 2005 14:13:52 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KEDjSJ053760; Sun, 20 Feb 2005 09:13:46 -0500 Message-ID: <42189B19.2040403@vanderpoel.org> Date: Sun, 20 Feb 2005 06:13:45 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> In-Reply-To: <20050220100328.GA14603~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > Yes, and I supposed they should be added to the blacklist as they are > discovered, but I think getting the Verisign TLDs (.com and .net) into > the blacklist will accomplish most of the benefit to be had from this > approach. It's not like the phishers can move all their attacks to .tm > after they get shut out of .com and .net, because there aren't nearly as > many targets in .tm. How do you propose to shut the phishers out of .com when a popular IDN plug-in (i-Nav) for the most popular browser (Microsoft Internet Explorer) is made by *VeriSign*, the very company that controls the .com registry? http://www.idnnow.com/index.jsp Does VeriSign also sell domain names to end-users under .com? I mean, are they also a registrar, not just a registry? Besides, in networking, it's better to be conservative. You don't start with a short blacklist and then grow it when you find others. No, you start with a whitelist, and grow that. Erik From owner-idn@ops.ietf.org Sun Feb 20 09:27:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06051 for ; Sun, 20 Feb 2005 09:27:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2rz1-000OBF-Rk for idn-data@psg.com; Sun, 20 Feb 2005 14:22:51 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2ryz-000OAw-Rg for idn@ops.ietf.org; Sun, 20 Feb 2005 14:22:50 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KEMipY048586; Sun, 20 Feb 2005 09:22:45 -0500 Message-ID: <42189D34.6040204@vanderpoel.org> Date: Sun, 20 Feb 2005 06:22:44 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: [idn] nameprep References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> <42189B19.2040403@vanderpoel.org> In-Reply-To: <42189B19.2040403@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > Besides, in networking, it's better to be conservative. You don't start > with a short blacklist and then grow it when you find others. No, you > start with a whitelist, and grow that. One could even make an argument along these lines for nameprep. Perhaps nameprep should not have started with the *huge* Unicode character set, subsequently making a feeble attempt to reduce that set to a safe one. One could make the argument that the nameprep RFC does not adhere to the old rule: "Be liberal in what you accept, and conservative in what you send" This is from section 1.2.2 of RFC 1122, a key RFC also known as STD 3: http://ietf.org/rfc/rfc1122.txt I wonder if something like this would catch the attention of the IETF or even the IESG? Erik From owner-idn@ops.ietf.org Sun Feb 20 09:47:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07380 for ; Sun, 20 Feb 2005 09:47:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2sI2-0003EK-Oo for idn-data@psg.com; Sun, 20 Feb 2005 14:42:30 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2sI1-0003E6-LS for idn@ops.ietf.org; Sun, 20 Feb 2005 14:42:29 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KEgOHb112388; Sun, 20 Feb 2005 09:42:25 -0500 Message-ID: <4218A1D0.2040703@vanderpoel.org> Date: Sun, 20 Feb 2005 06:42:24 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> In-Reply-To: <20050220110817.GD14603~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > there's still the problem of characters that are supposed to use > different glyphs that are only slightly different and therefore easily > confusable. I agree that some of the Unicode characters are only slightly different and therefore easily confusable. But then, in the current climate, where phishing is becoming a larger problem and identity theft is growing fast, would you say that it is safe to use Unicode in *DNS*, one of the most important underpinnings, security-wise, of the Internet? Let's take an analogy. The P.O. Box system. Right now, it uses numbers like P.O. Box 3256. What would happen if the Postal Service decided to use Unicode, where some of the characters are only slightly different, and the postman inadvertently put some important mail into the wrong box, one that was registered by an evil person, using a name that was only slightly different from the PO box of some company? Wouldn't that company try to get the Postal Service to use a smaller set of symbols (say, digits) rather than this confusing Unicode? Maybe that company would even try to sue the Postal Service. Erik From owner-idn@ops.ietf.org Sun Feb 20 10:33:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11977 for ; Sun, 20 Feb 2005 10:33:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2t1P-000Fhz-6X for idn-data@psg.com; Sun, 20 Feb 2005 15:29:23 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2t1N-000Fhk-ND for idn@ops.ietf.org; Sun, 20 Feb 2005 15:29:22 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id j1KFTKdU091474; Sun, 20 Feb 2005 16:29:20 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> To: Erik van der Poel cc: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense In-reply-to: Your message of Sun, 20 Feb 2005 06:13:45 -0800. <42189B19.2040403@vanderpoel.org> Date: Sun, 20 Feb 2005 16:29:20 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Does VeriSign also sell domain names to end-users under .com? I mean, are they also a registrar, not just a registry? The registrar business was split off and later sold. As far as I know, it operates under the name ``network solutions''. jaap From owner-idn@ops.ietf.org Sun Feb 20 11:40:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17937 for ; Sun, 20 Feb 2005 11:40:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2u2Z-0006bF-Mi for idn-data@psg.com; Sun, 20 Feb 2005 16:34:39 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2u2Y-0006an-Iu for idn@ops.ietf.org; Sun, 20 Feb 2005 16:34:38 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KGYTSJ249854; Sun, 20 Feb 2005 11:34:29 -0500 Message-ID: <4218BC15.8060208@vanderpoel.org> Date: Sun, 20 Feb 2005 08:34:29 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jaap Akkerhuis CC: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> In-Reply-To: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Does VeriSign also sell domain names to end-users under .com? I mean, > are they also a registrar, not just a registry? > > The registrar business was split off and later sold. As far as I > know, it operates under the name ``network solutions''. I see. Thanks for the info. Does VeriSign have some other kind of financial incentive to increase the number of registrations under .com? On the other hand, if some actual IDN phishing starts to occur under .com, VeriSign might have to tighten up their policy. They might eventually lose money on any lawsuits that are filed. So, in the long term, this IDN spoofing might not be in their best interests. It's too bad they don't make any comments on this mailing list and take some kind of action, to put our minds at ease. Erik From owner-idn@ops.ietf.org Sun Feb 20 11:44:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18414 for ; Sun, 20 Feb 2005 11:44:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2u9k-0008Xe-Sq for idn-data@psg.com; Sun, 20 Feb 2005 16:42:04 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2u9j-0008XO-SQ for idn@ops.ietf.org; Sun, 20 Feb 2005 16:42:04 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1KGg1JR007015; Mon, 21 Feb 2005 01:42:02 +0900 Message-ID: <4218BDD8.8040805@lsb.org> Date: Mon, 21 Feb 2005 01:42:00 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: IETF idn working group Subject: Re: [idn] nameprep References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> <42189B19.2040403@vanderpoel.org> <42189D34.6040204@vanderpoel.org> In-Reply-To: <42189D34.6040204@vanderpoel.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > Erik van der Poel wrote: > >> Besides, in networking, it's better to be conservative. You don't >> start with a short blacklist and then grow it when you find others. >> No, you start with a whitelist, and grow that. > > > One could even make an argument along these lines for nameprep. > Perhaps nameprep should not have started with the *huge* Unicode > character set, subsequently making a feeble attempt to reduce that set > to a safe one. > > One could make the argument that the nameprep RFC does not adhere to > the old rule: > > "Be liberal in what you accept, and conservative in what you send" > I like this "maxim" by late Jon Postel,too. nameprep versioning had been debated 3 years ago, but AFAIK it was dismissed. Let's assume nameprep1 and nameprep2 have its own supported unicode char set. of course, nameprep1 is subset of nameprep2. IDN2 contains new unicode char from nameprep2. Decode&Normalize&Verify2(Normalize&Verify&Encode1(IDN2)) would fail in the inner expression by the encoding party who uses nameprep1 , Decode&Normalize&Verify1(Normalize&Verify&Encode2(IDN2)) would fail in the outer expression by the decoding party whoi uses nameprep1, while Decode&Normalize&Verify2(Normalize&Verify&Encode1(IDN1)) would succeed by both parties, assuming two parties have different versions of namepreps.. nameprep versioning and applicaton-level filtering both fundamentally change how dns resolving works, by adding new *exception handlings* that did not exist with ASCII only DNS. that is, dns stability issues came out at that time. We should have to produce perfect nameprep/stirngprep at once and use forever without versioning, but unicode is not designed/not prepared for identifier use. I think that is the source of all these homograph problems. Please correct me if my memory about this topic is wrong, senior members. Soobok From owner-idn@ops.ietf.org Sun Feb 20 12:30:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21907 for ; Sun, 20 Feb 2005 12:30:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2upc-000H3M-FN for idn-data@psg.com; Sun, 20 Feb 2005 17:25:20 +0000 Received: from [68.168.78.44] (helo=mta13.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2upa-000Gyb-4E for idn@ops.ietf.org; Sun, 20 Feb 2005 17:25:18 +0000 Received: from DEWELL ([68.66.2.217]) by mta13.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050220172516.MABR25839.mta13.adelphia.net@DEWELL>; Sun, 20 Feb 2005 12:25:16 -0500 Message-ID: <002c01c51770$b0f74be0$030aa8c0@DEWELL> From: "Doug Ewell" To: "IETF idn working group" Cc: "Erik van der Poel" References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> Subject: Re: [idn] upstream and downstream Date: Sun, 20 Feb 2005 09:22:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > Let's take an analogy. The P.O. Box system. Right now, it uses numbers > like P.O. Box 3256. What would happen if the Postal Service decided to > use Unicode, where some of the characters are only slightly different, > and the postman inadvertently put some important mail into the wrong > box, one that was registered by an evil person, using a name that was > only slightly different from the PO box of some company? > > Wouldn't that company try to get the Postal Service to use a smaller > set of symbols (say, digits) rather than this confusing Unicode? Maybe > that company would even try to sue the Postal Service. Sadly, the Postal Service is fully capable of putting mail in the wrong box without the help of Unicode. Sorry. Anyway... The Postal Service probably would have instituted some type of subset of valid characters for use in P.O. box identifiers. (Or alternatively, they would have a blacklist of invalid characters.) At some point they would discover, or have pointed out to them, confusables that they hadn't thought of. They would probably then amend their list to exclude the newly discovered confusable. THEN, because they are the Postal Service and have complete authority over the entire system, they would be able to discontinue the use of the evil P.O. box and require the user to change its name, or change it for him, or refund his deposit. Meanwhile, the reason they switched to Unicode in the first place was precisely that they wanted to offer a wider variety of characters to their users, for whatever reason. Isn't that why domain names were internationalized? Isn't that the reason *anyone* switches to Unicode? They must have had some benefits in mind by adopting a larger repertoire. By switching away from "this confusing Unicode" they are giving up those perceived benefits. If you have an application that lends itself to a limited repertoire, like automobile license plates or P.O. box numbers or house numbers, use that limited repertoire. If you need a wider repertoire, you can use Unicode and you can *still* implement a subset. The problem, as always, is in determining what the subset should be. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Sun Feb 20 12:31:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21978 for ; Sun, 20 Feb 2005 12:31:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2upi-000H6D-HL for idn-data@psg.com; Sun, 20 Feb 2005 17:25:26 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2uph-000H5y-7k for idn@ops.ietf.org; Sun, 20 Feb 2005 17:25:25 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KHPNHb110122; Sun, 20 Feb 2005 12:25:23 -0500 Message-ID: <4218C803.3080003@vanderpoel.org> Date: Sun, 20 Feb 2005 09:25:23 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [Fwd: Re: [idn] IDN spoofing] Content-Type: multipart/mixed; boundary="------------080300020502080709010601" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080300020502080709010601 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit George gave me permission to forward his email to this list. Erik --------------080300020502080709010601 Content-Type: message/rfc822; name="Re: [idn] IDN spoofing" Content-Disposition: inline; filename="Re: [idn] IDN spoofing" X-Account-Key: account3 Received: from unicode.org (unicode.org [69.13.187.164]) by bravo.vanderpoel.org (8.13.0/8.13.0) with ESMTP id j1JIEERm011900 for ; Sat, 19 Feb 2005 10:14:15 -0800 (PST) Received: from sarasvati.unicode.org (localhost [127.0.0.1]) by unicode.org (8.12.11/8.12.11) with ESMTP id j1K1gw8T032391; Sat, 19 Feb 2005 19:42:58 -0600 Received: with ECARTIS (v1.0.0; list unicode); Sat, 19 Feb 2005 19:42:58 -0600 (CST) Received: from proxy.syd (comcen.comcen.com.au [203.23.236.66]) by unicode.org (8.12.11/8.12.11) with ESMTP id j1K1gr3M032373 for ; Sat, 19 Feb 2005 19:42:57 -0600 Received: from [192.168.0.2] (202-172-121-202.cpe.nsw-5.comcen.com.au [202.172.121.202]) by proxy.syd (8.11.6/8.11.6) with ESMTP id j1K1gpU40527; Sun, 20 Feb 2005 12:42:51 +1100 (EST) (envelope-from g.gerrity@gwg-associates.com.au) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=UTF-8; format=flowed Message-Id: <4aba7a4184c288476e81eadc047c15c8@gwg-associates.com.au> Cc: George W Gerrity From: George W Gerrity Subject: Re: [idn] IDN spoofing Date: Sun, 20 Feb 2005 12:42:46 +1100 To: List Unicode X-Mailer: Apple Mail (2.619.2) X-MIME-Autoconverted: from quoted-printable to 8bit by unicode.org id j1K1gr3M032373 X-archive-position: 18424 X-ecartis-version: Ecartis v1.0.0 Sender: unicode-bounce@unicode.org Errors-to: unicode-bounce@unicode.org X-original-sender: g.gerrity@gwg-associates.com.au Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-ID: X-List-ID: X-list: unicode Content-Transfer-Encoding: 8bit It has been stated quite clearly that the problem of spoofing TLD tags should not exist because the authority for a given TLD can (and should) accept only one coding for a TLD tag. However, where the TLD tag is a country code, second-level TLD tags can (and should) also be unique (eg, .co.uk, .net.au). I don't think that has been stated clearly before. For the second-level (or third-level where the top is a country code) domain tag, it should be the legal responsibility of the name authorities for the domain above to ensure that spoofed names cannot be registered (or if registered, all belong to one owner). In the Western world, if that is not already the case, then I'm sure that the first time a spoof of, say Coca-Cola (or Pepsi — let's be even-handed) is registered, then we can be certain that afterwards, the issuing authority will never do it again. In the case of countries whose law systems are still a bit wild and wooly (The former Soviet Union?), then I suspect that for the time being it will remain ‘Caveat Emptor’. In either case, a domain name holder should be able to license all spoofs for free, in order to limit its exposure to spoofing, whether or not there is adequate legal recourse. The point I'm making is that while the authorities for .com.au or .com.ru may do what they like, we can at least give them advice plus some tables that will detect many, if not most, spoofs. In the case where the authority allows (for whatever reason) a name with mixed orthographies, then clearly the first to apply whose signature is not a spoof for an (already well-established) trade-marked name or domain name, should get the license, and all other applicants with a similar name be refused. The name authority should be protected by the laws of the countries in which it operates from being sued for refusing to register confusable names. Thus, our rôle reduces to providing some automatic methods to help the authorities deal with the homograph problem, and we can quit discussing the question of how to enforce authorities to adopt sensible naming conventions: that ultimately belongs to the realm of law and regulation. George --------------080300020502080709010601-- From owner-idn@ops.ietf.org Sun Feb 20 12:51:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23470 for ; Sun, 20 Feb 2005 12:51:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2v7e-000LSD-2x for idn-data@psg.com; Sun, 20 Feb 2005 17:43:58 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2v7a-000LRs-Ms for idn@ops.ietf.org; Sun, 20 Feb 2005 17:43:54 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KHhpuq454198; Sun, 20 Feb 2005 12:43:52 -0500 Message-ID: <4218CC57.7010607@vanderpoel.org> Date: Sun, 20 Feb 2005 09:43:51 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ewell CC: IETF idn working group Subject: Re: [idn] upstream and downstream References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> In-Reply-To: <002c01c51770$b0f74be0$030aa8c0@DEWELL> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Doug Ewell wrote: > If you have an application that lends itself to a limited repertoire, > like automobile license plates or P.O. box numbers or house numbers, use > that limited repertoire. If you need a wider repertoire, you can use > Unicode and you can *still* implement a subset. The problem, as always, > is in determining what the subset should be. Well put, Doug. It is easy to see how stringprep and nameprep got to be the way they are. First, you want domain names in local languages. Second, you don't want to mess with the myriad charsets used around the world for something as central as DNS, so you choose the only real alternative, Unicode. Third, it is a lot of work to create a subset (and it's controversial), so you punt, and just publish the RFC anyway. Didn't some CEO say, "Does it compile? OK, ship it!" These comments are probably very upsetting to various people on this list. Sorry! All I'm pointing out is that it is easy to see how we ended up like this, human nature being the way it is. Moreover, it is grossly unfair for someone like me to come in so late and make all these comments, when I could have had my eyes on the ball at the critical time, instead of going off and working on something totally different all these years. Then again, I might have missed it too, or just gone along with the flow, even if I *was* here. It's really hard to focus on the critical issues when you have an open mailing list with all sorts of people bringing up all sorts of little examples from around the world. I looked at the archives of this mailing list, and there is a lot of noise. Erik From owner-idn@ops.ietf.org Sun Feb 20 13:03:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24499 for ; Sun, 20 Feb 2005 13:03:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2vLj-00008H-QI for idn-data@psg.com; Sun, 20 Feb 2005 17:58:31 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2vLh-00007K-JX for idn@ops.ietf.org; Sun, 20 Feb 2005 17:58:29 +0000 Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.73]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1KHwRxd012420 for ; Sun, 20 Feb 2005 12:58:28 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KHwPR5319674; Sun, 20 Feb 2005 12:58:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4218BC15.8060208@vanderpoel.org> References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> Date: Sun, 20 Feb 2005 12:58:25 -0500 To: idn@ops.ietf.org From: tedd Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Cc: Erik van der Poel Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk >On the other hand, if some actual IDN phishing starts to occur under >.com, VeriSign might have to tighten up their policy. They might >eventually lose money on any lawsuits that are filed. So, in the >long term, this IDN spoofing might not be in their best interests. > >It's too bad they don't make any comments on this mailing list and >take some kind of action, to put our minds at ease. > >Erik Erik: Well... the problem is not totally Versign's, is it? On one hand, the list wants to solve the homograph attack (glyph look-alike) problem, but on the other hand when confronted with a clear solution to a specific problem, the list ignores it. Case in point, the lower and upper case omega. Clearly the upper case omega would not be confused with any other glyph -- it's unique. However, the list mandates that all characters shall be lower case. As such, the lower case omega looks like a lower case "w" and thus presents a look-a-like problem. Now, I'm not in favor of allowing both upper and lower case characters for each glyph into the mix, BUT, I think it wise to look at one -- OR-- the other to see if a solution for each glyph presents itself. Is this not reasonable? As I understand it, this would only require a change in mapping. That should solve at least one "glyph look-alike" problem -- shouldn't it? tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Sun Feb 20 13:37:07 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27093 for ; Sun, 20 Feb 2005 13:37:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2vrk-0008nF-Dt for idn-data@psg.com; Sun, 20 Feb 2005 18:31:36 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2vrj-0008n0-Bt for idn@ops.ietf.org; Sun, 20 Feb 2005 18:31:35 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KIVMpY277510; Sun, 20 Feb 2005 13:31:30 -0500 Message-ID: <4218D779.9090503@vanderpoel.org> Date: Sun, 20 Feb 2005 10:31:21 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tedd CC: idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > Well... the problem is not totally Versign's, is it? I agree. Part of the problem is upstream from VeriSign. > Case in point, the lower and upper case omega. Clearly the upper case > omega would not be confused with any other glyph -- it's unique. That may be true, but would the users like to see an upper case omega in the middle of a name? Don't get me wrong -- I appreciate the example -- but there are pros and cons to everything. > As I understand it, this would only require a change in mapping. That > should solve at least one "glyph look-alike" problem -- shouldn't it? Wouldn't this require a new ACE prefix? Erik From owner-idn@ops.ietf.org Sun Feb 20 14:14:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00147 for ; Sun, 20 Feb 2005 14:14:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2wTJ-000IJ5-Tl for idn-data@psg.com; Sun, 20 Feb 2005 19:10:25 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2wTI-000IIn-05 for idn@ops.ietf.org; Sun, 20 Feb 2005 19:10:24 +0000 Received: from pimout7-ext.prodigy.net (pimout7-ext.prodigy.net [207.115.63.58]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1KJAMxd018076 for ; Sun, 20 Feb 2005 14:10:22 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KJADMk056242; Sun, 20 Feb 2005 14:10:22 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <4218D779.9090503@vanderpoel.org> References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <4218D779.9090503@vanderpoel.org> Date: Sun, 20 Feb 2005 14:10:12 -0500 To: idn@ops.ietf.org From: tedd Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Cc: Erik van der Poel Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk >tedd wrote: >>Case in point, the lower and upper case omega. Clearly the upper >>case omega would not be confused with any other glyph -- it's >>unique. Erik replied: >That may be true, but would the users like to see an upper case >omega in the middle of a name? Don't get me wrong -- I appreciate >the example -- but there are pros and cons to everything. That's a good point. But, given the "look-alike" problem, and comparing it to the possibility that an upper-case Omega may appear within a name, what's the "better" solution? You can't have both. I'm not arguing just for the Omega glyph (that's just an example), but rather I believe that there are more than a single glyph where its uppercase may present a better solution for a "look-alike" problem than it's lowercase counterpart. And, I am not proposing a mixed case solution for the IDN, but rather a single case for each code point. Granted, the vast majority of code points would remain lowercase, but a few uppercase exceptions may alleviate the "look-alike" problem. Just an idea. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Sun Feb 20 14:22:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00862 for ; Sun, 20 Feb 2005 14:22:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2wcT-000JTj-ER for idn-data@psg.com; Sun, 20 Feb 2005 19:19:53 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2wcS-000JRq-8Q for idn@ops.ietf.org; Sun, 20 Feb 2005 19:19:52 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KJJkSJ101328; Sun, 20 Feb 2005 14:19:46 -0500 Message-ID: <4218E2D2.1050203@vanderpoel.org> Date: Sun, 20 Feb 2005 11:19:46 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] what might happen References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <4218D779.9090503@vanderpoel.org> In-Reply-To: <4218D779.9090503@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I doubt that we will be able to totally solve the IDN phishing problem, just like we cannot totally solve the more general phishing problem. These phishers come up with new tricks all the time. I'm guessing that the IDN spoofing issue will be addressed (not solved) at several different levels, upstream and downstream. The Unicode Consortium has already stated that they are seriously considering the homograph issue, and we may eventually see tables and other info that others can use in heuristic filters, etc. It will be interesting to see what happens with the IDN-related RFCs when they advance to the next maturity level. I'm not even going to try to guess what might happen there. Many ccTLDs have already put filtering policies and deployments in place, and the other TLDs will probably start to filter, sooner or later. Security-conscious apps and plug-ins will also have a layer of protection, with UIs ranging from the seamless to the intrusive. I will remain on this list for the time being. Thanks everybody, Erik From owner-idn@ops.ietf.org Sun Feb 20 17:40:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17824 for ; Sun, 20 Feb 2005 17:40:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D2zf7-000Ktt-9n for idn-data@psg.com; Sun, 20 Feb 2005 22:34:49 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D2zf5-000Ktc-Qw for idn@ops.ietf.org; Sun, 20 Feb 2005 22:34:48 +0000 Received: (qmail 27014 invoked from network); 20 Feb 2005 22:34:45 -0000 Received: from unknown (HELO [80.185.154.185]) (544451@[80.185.154.185]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Feb 2005 22:34:45 -0000 Message-ID: <42191083.7040601@v.loewis.de> Date: Sun, 20 Feb 2005 23:34:43 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tedd CC: idn@ops.ietf.org, Erik van der Poel Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> In-Reply-To: X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > As I understand it, this would only require a change in mapping. That > should solve at least one "glyph look-alike" problem -- shouldn't it? Anything involving changes in the way IDNA works (through changing mappings, or restricting characters further on the client side) is not a solution, whatever the problem. Any such change will take ten years or more to implement. Regards, Martin From owner-idn@ops.ietf.org Sun Feb 20 18:32:57 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22861 for ; Sun, 20 Feb 2005 18:32:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D30UD-0001vs-Av for idn-data@psg.com; Sun, 20 Feb 2005 23:27:37 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D30UA-0001vS-Bz for idn@ops.ietf.org; Sun, 20 Feb 2005 23:27:34 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D30U9-0008Fp-00 for ; Sun, 20 Feb 2005 15:27:33 -0800 Date: Sun, 20 Feb 2005 23:27:33 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: <20050220232733.GA31308~@nicemice.net> Reply-To: IETF idn working group References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> <42189B19.2040403@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42189B19.2040403@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > How do you propose to shut the phishers out of .com when a popular > IDN plug-in (i-Nav) for the most popular browser (Microsoft Internet > Explorer) is made by *VeriSign*, the very company that controls the > .com registry? If i-Nav leaves its users exposed to phishing attacks, and the users are bothered by it, then I would expect them to switch to a different IDN plug-in. isc.org released an alpha3 version of such a plug-in a year ago, so maybe that could be whipped into shape quickly. > Besides, in networking, it's better to be conservative. You don't > start with a short blacklist and then grow it when you find others. > No, you start with a whitelist, and grow that. I agree, but in this case, we have already missed the start. If we introduce a whitelist now, after IDN deployment is already well underway, we are effectively punishing an unknown number of innocent early adopters, which seems like a betrayal. If we had forseen this problem, we could have set up the whitelist in the beginning, and registries & registrars would have known to get themselves added to the whitelist before making any promises to their customers. AMC From owner-idn@ops.ietf.org Sun Feb 20 18:46:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23829 for ; Sun, 20 Feb 2005 18:46:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D30j5-00044s-63 for idn-data@psg.com; Sun, 20 Feb 2005 23:42:59 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D30j3-00044U-Cp for idn@ops.ietf.org; Sun, 20 Feb 2005 23:42:57 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D30j2-0008LE-00 for ; Sun, 20 Feb 2005 15:42:56 -0800 Date: Sun, 20 Feb 2005 23:42:56 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050220234256.GB31308~@nicemice.net> Reply-To: IETF idn working group References: <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002c01c51770$b0f74be0$030aa8c0@DEWELL> <4218A1D0.2040703@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > But then, in the current climate, where phishing is becoming a larger > problem and identity theft is growing fast, would you say that it is > safe to use Unicode in *DNS*, one of the most important underpinnings, > security-wise, of the Internet? Doug Ewell wrote: > If you need a wider repertoire, you can use Unicode and you can > *still* implement a subset. The problem, as always, is in determining > what the subset should be. I'm with you both. I wanted the IDN working group to define a subset, but ultimately I was persuaded that it was not feasible for the IETF to reach consensus on such a subset, and that subsetting could and should be done on a per-registry basis, inside the registry rather than the applications. But the slash-homograph attack now makes that approach (in its pure form) appear hopeless. AMC From owner-idn@ops.ietf.org Sun Feb 20 19:03:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25508 for ; Sun, 20 Feb 2005 19:03:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D30zE-0006y5-1Q for idn-data@psg.com; Sun, 20 Feb 2005 23:59:40 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D30zD-0006xr-4z for idn@ops.ietf.org; Sun, 20 Feb 2005 23:59:39 +0000 Received: from lns-p19-8-idf-82-65-67-209.adsl.proxad.net ([82.65.67.209] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D30zC-0000uc-5X for idn@ops.ietf.org; Sun, 20 Feb 2005 15:59:38 -0800 Message-Id: <6.1.2.0.2.20050221004531.03926eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 21 Feb 2005 00:59:26 +0100 To: IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense In-Reply-To: <20050220232733.GA31308~@nicemice.net> References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> <42189B19.2040403@vanderpoel.org> <20050220232733.GA31308~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On 00:27 21/02/2005, Adam M. Costello said: >I agree, but in this case, we have already missed the start. If >we introduce a whitelist now, after IDN deployment is already well >underway, we are effectively punishing an unknown number of innocent >early adopters, which seems like a betrayal. If we had forseen this >problem, we could have set up the whitelist in the beginning, and >registries & registrars would have known to get themselves added to the >whitelist before making any promises to their customers. Dear Adam, we known the problem, as we known the TLD problem, as we known the babel-name problem, as we known the IDN zone DNS management complexity, as we known the 3+LD problem, as we known the Verisign/ccTLD attitude, as we known the lack of layered analysis, etc. (I mean at least people who dialogued with me in private when the wg-correct was calling me a dumb debile). Your punycode is a transcoding solution of interest. Tables are an attempt to fix part of the IDN problem, but it needs to be applied where it is useful and controlled by the user (in phishing: at printing and outbound nameprep). Take care. jfc PS. I fail to see what Registrars are to do with this? From owner-idn@ops.ietf.org Sun Feb 20 19:03:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25580 for ; Sun, 20 Feb 2005 19:03:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D30ze-00073K-Sh for idn-data@psg.com; Mon, 21 Feb 2005 00:00:06 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D30zV-00070E-M5 for idn@ops.ietf.org; Sun, 20 Feb 2005 23:59:57 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1KNxquq333424; Sun, 20 Feb 2005 18:59:53 -0500 Message-ID: <42192478.8040305@vanderpoel.org> Date: Sun, 20 Feb 2005 15:59:52 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <20050219221719.GB5457~@nicemice.net> <4217D839.7040502@dready.org> <20050220100328.GA14603~@nicemice.net> <42189B19.2040403@vanderpoel.org> <20050220232733.GA31308~@nicemice.net> In-Reply-To: <20050220232733.GA31308~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > If i-Nav leaves its users exposed to phishing attacks, and the users are > bothered by it, then I would expect them to switch to a different IDN > plug-in. Good point. Re: white list: > I agree, but in this case, we have already missed the start. mozilla.org has a pretty wide reach worldwide, partly due to the localization efforts. So maybe mozilla.org could get in touch with various people, either to get info, or to have them beta-test a version with a white list, etc. Erik From owner-idn@ops.ietf.org Sun Feb 20 19:04:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25643 for ; Sun, 20 Feb 2005 19:04:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D310w-0007Lg-Uv for idn-data@psg.com; Mon, 21 Feb 2005 00:01:26 +0000 Received: from [193.201.200.34] (helo=tuschin.blackcatnetworks.co.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D310v-0007Kz-SD for idn@ops.ietf.org; Mon, 21 Feb 2005 00:01:26 +0000 Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.100]) by tuschin.blackcatnetworks.co.uk with asmtp (Exim 3.35 #1 (Debian)) id 1D310q-0005Jm-00 for ; Mon, 21 Feb 2005 00:01:20 +0000 Message-ID: <4219249A.9060306@mozilla.org> Date: Mon, 21 Feb 2005 00:00:26 +0000 From: Gervase Markham Organization: mozilla.org User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> In-Reply-To: <20050220234256.GB31308~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > I'm with you both. I wanted the IDN working group to define a subset, > but ultimately I was persuaded that it was not feasible for the IETF to > reach consensus on such a subset, and that subsetting could and should > be done on a per-registry basis, inside the registry rather than the > applications. But the slash-homograph attack now makes that approach > (in its pure form) appear hopeless. Just to delurk for a moment... I'm currently kicking around ideas here at mozilla.org for dealing with this issue. We hope to be able to present a proposal soon. What someone posted a day ago about "/" homograph attacks has meant that one thing we plan to do is have a short number of characters which are completely forbidden in IDN domains at any level - in that, mozilla.org products would refuse to recognise IDNs containing them. My initial list includes the homographs of ":", ".", "/" and probably "\" too, plus all the space characters. Of course, there may be some good reason why this doesn't fly. Gerv P.S. Of course, the slash homograph attack wouldn't fool the Firefox SSL domain security indicator anyway, which would still display the entire domain, fake slashes and all. From owner-idn@ops.ietf.org Sun Feb 20 21:21:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07194 for ; Sun, 20 Feb 2005 21:21:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D338f-0001DZ-LG for idn-data@psg.com; Mon, 21 Feb 2005 02:17:33 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D338b-0001D3-TB for idn@ops.ietf.org; Mon, 21 Feb 2005 02:17:30 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D338P-000D1z-9A; Sun, 20 Feb 2005 21:17:17 -0500 Date: Sun, 20 Feb 2005 21:17:16 -0500 From: John C Klensin To: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , tedd cc: idn@ops.ietf.org, Erik van der Poel Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: In-Reply-To: <42191083.7040601@v.loewis.de> References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable --On Sunday, 20 February, 2005 23:34 +0100 "\"Martin v. = L=F6wis\"" wrote: > tedd wrote: >> As I understand it, this would only require a change in >> mapping. That should solve at least one "glyph look-alike" >> problem -- shouldn't it? >=20 > Anything involving changes in the way IDNA works (through > changing > mappings, or restricting characters further on the client > side) is > not a solution, whatever the problem. Any such change will > take ten > years or more to implement. Martin,=20 For a change, I don't share the pessimism on this. I think we should be very hesitant to make changes unless it is pretty clearly demonstrated that they are necessary, with a high threshold on such a demonstration. But it seems to me that: (i) A change that would largely impact what can be registered needs to be reflected and implemented only in 250-odd registries. The registry operators are mostly on their toes, communicate with each other, and many of them are pretty early in their implementation of IDNs and conservative about what they are permitting. Getting them to make changes is an entirely different sort of problem than, e.g., trying to change already-installed browsers or client plugins or getting people to upgrade them. (ii) The main things I've seen in observing and working with registries that I didn't understand well enough a couple of years ago to argue forcefully are things that we might be able to change because the impact of whether someone was running an old or new version would not be large. For example, IDNA makes some mappings that are dubious, not in the technical sense of whether the characters are equivalent, but in the human factors sense of whether treating them as equivalent leads to bad habits. To take a handy example from a Roman ("Latin")-based script, I now suspect that permitting all of those font-variant "mathematical" characters to map onto their lower-case ASCII equivalents is a bad idea, just because it encourages users to assume that, if something looks like a particular base character, it is that character. That, in turn, increases the perceptual window for these phishing attacks. If, instead, we had simply banned those characters, creating an error if someone tried to use one rather than a quiet mapping into something else, we might have been better off. So I now think we should have banned them when IDNA and nameprep were defined and think I could have made that case very strongly had I understood the issues the way I do now. Is it worth making that change today? I don't know. But I suggest that it would be possible to make it for two reasons: (a) such a change would not change the number of strings or characters that can be registered at all: only the base characters can actually appear in an IDNA string post the ToUnicode(ToASCII(char)) operation pair and (b) if I were a browser or other application producer, I'd be seriously considering warnings if any characters from those blocks appeared... something IDNA certainly does not prohibit. Changes that increased the number of registerable characters are problematic, but not that problematic if they don't pick up a character that now maps and make it "real" (which is the problem with deciding that upper case Omega is a good idea). Reducing the number of characters that can be registered --making a now-valid base character invalid-- would be a much harder problem. (iii) Finally, and most important, there are several areas in the world for which IDNA, as now defined, is equivalent to no progress on IDNs at all because they need characters that are not in Unicode 3.2. To accommodate them, we are going to need to upgrade to at least 4.0 and, in some cases, to sets of characters not yet fully defined. At some point, our upgrading the version of Unicode is going to be an absolute necessity. That requires changing the nameprep/stringprep tables and, no matter how painful we think that might be, we are going to need to figure out how to do it. --------------- Rather than start another note, an observation about the blacklist idea that doesn't seem to have been mentioned... Let me state this in personal terms: I don't like blacklists. The reasons aren't technical at least in the first instance, but a whole series of system behavior observations. For example: (1) It tends, in practice, to be much easier to get on them than off of them. One can certainly say "put .NET and .COM on the list, and, when Verisign changes its behavior, we will take them off". But that hides a whole set of issues, such as whether you believe them when they say their behavior has changed, whether the behavior has changed enough (unfortunately, this is really not a binary situation), and so on. (2) There is a protocol issue with how the blacklist is maintained. If it is part of the code of the relevant applications software, or a plug-in or add-on to it, we have to face the problem that the average end user doesn't upgrade things on the schedules we would like, resulting in a different "harder to get off than on" case. If the application is designed to automatically update itself from a common source on the network, we are suddenly faced with all of the problems caused by various people's ideas of security: authentication of the new tables, firewalls and system configurations that are hostile to that sort of upgrading, and so on. (3) As we have seen with spam, the existence of a blacklist mechanism, no matter how well conceived, is an invitation to abuse and/or claims that abuse is occurring. If we create a mechanism for putting up warnings about IDN use in particular domains, how long will it be before there are demands to put up warnings for domains that are, statistically, too friendly to spammers, pornographers, phishers, music-swappers, or holders of unpopular social or political positions? We all understand the difference between those issues and ones where the boundary can be set using objective technical criteria. But we have had long experience with governments and policy advocates not understanding the distinction and, indeed, being determined to not do so. (4) Finally, the result of too many warnings is that warnings are ignored. Certainly it is better to flag or color IDNs from a few domains than it is for all domains. And it is almost certainly better to do something than nothing. But, if the domains flagged contain a large fraction of all of the second-level registrations in the world, we should keep our expectations of how much such measures will help very moderate. john From owner-idn@ops.ietf.org Sun Feb 20 21:36:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08200 for ; Sun, 20 Feb 2005 21:36:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D33M9-0003Lq-Ey for idn-data@psg.com; Mon, 21 Feb 2005 02:31:29 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D33M7-0003LI-S2 for idn@ops.ietf.org; Mon, 21 Feb 2005 02:31:28 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1L2VPJR030297 for ; Mon, 21 Feb 2005 11:31:26 +0900 Message-ID: <421947FC.8000702@lsb.org> Date: Mon, 21 Feb 2005 11:31:24 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] another homograph attach: BIDI char Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit javascript:void(window.open(unescape("http://www.microsoft.com%u202e.uni.cc/%u1160%u1160%u1160"),"_self")) If some IDNA implementation does not handle BIDI filtering/verifying well, you can see similar results as "slash-space combination". %u202e is a bidi directional formatter (RLO, right-to-left) and should not be filtered char-by-char basis, because the char plays a crucual role in arabic/hebrew writings. You can refer to stringprep/nameprep document for details of BIDI checking part. Good implementations of IDNA would not suffer from the above attack. But, current MSIE does not support IDNA, while it still allow arbitrary utf-8 chars. So, current MSIE is exploitable for malicious phinshing attempts. I don't know whether this works for filefox/mozilla. The previous example, javascript:void(window.open(unescape("http://www.microsoft.com%u2044%u1160%u1160%u1160.uni.cc/"),"_self")) You can replace %u2044 with %u2205,%u3033 etc. I am now searching more slash/space like chars. I will post them here. Soobok From owner-idn@ops.ietf.org Sun Feb 20 21:57:17 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09986 for ; Sun, 20 Feb 2005 21:57:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D33gd-0006bU-ML for idn-data@psg.com; Mon, 21 Feb 2005 02:52:39 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D33gU-0006aB-Hn for idn@ops.ietf.org; Mon, 21 Feb 2005 02:52:30 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1L2qSJR001795; Mon, 21 Feb 2005 11:52:28 +0900 Message-ID: <42194CEB.9090602@lsb.org> Date: Mon, 21 Feb 2005 11:52:27 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soobok Lee CC: idn@ops.ietf.org Subject: Re: [idn] another homograph attach: BIDI char References: <421947FC.8000702@lsb.org> In-Reply-To: <421947FC.8000702@lsb.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > javascript:void(window.open(unescape("http://www.microsoft.com%u202e.uni.cc/%u1160%u1160%u1160"),"_self")) > > you can add "%u2044" at the filepath part of the url, which has no length limit like the label part. If you increase the number of %u1160 to 100, You can hide "uni.cc" part completely in most browsers. I request MS's urgent actions. javascript:void(window.open(unescape("http://www.microsoft.com%u202e.uni.cc/%u1160%u1160%u1160%u2044"),"_self")) > > If some IDNA implementation does not handle BIDI filtering/verifying > well, you can see similar results as "slash-space combination". > %u202e is a bidi directional formatter (RLO, right-to-left) and should > not be filtered char-by-char basis, because the char > plays a crucual role in arabic/hebrew writings. You can refer to > stringprep/nameprep document for details of BIDI checking part. > > Good implementations of IDNA would not suffer from the above attack. > But, current MSIE does not support IDNA, while it > still allow arbitrary utf-8 chars. So, current MSIE is exploitable for > malicious phinshing attempts. I don't know whether this works > for filefox/mozilla. > > The previous example, > javascript:void(window.open(unescape("http://www.microsoft.com%u2044%u1160%u1160%u1160.uni.cc/"),"_self")) > > You can replace %u2044 with %u2205,%u3033 etc. I am now searching more > slash/space like chars. I will post them here. %u2205 ===> %u2215 Soobok From owner-idn@ops.ietf.org Sun Feb 20 23:59:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20138 for ; Sun, 20 Feb 2005 23:59:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D35ZK-000OyF-6m for idn-data@psg.com; Mon, 21 Feb 2005 04:53:14 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D35ZI-000Oxv-8z for idn@ops.ietf.org; Mon, 21 Feb 2005 04:53:12 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D35ZH-0001KQ-00 for ; Sun, 20 Feb 2005 20:53:11 -0800 Date: Mon, 21 Feb 2005 04:53:11 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050221045311.GC31308~@nicemice.net> Reply-To: IETF idn working group References: <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4219249A.9060306@mozilla.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Gervase Markham wrote: > What someone posted a day ago about "/" homograph attacks has meant > that one thing we plan to do is have a short number of characters > which are completely forbidden in IDN domains at any level - in that, > mozilla.org products would refuse to recognise IDNs containing them. Please think twice before creating a precedent of a browser completely blackholing a technically valid (albeit devious) site. I think it would be sufficient, security-wise, for the browser to inhibit the display of domain names believed to be misleading, and to display them in ASCII form instead, but still allow access to the site. > My initial list includes the homographs of ":", ".", "/" and probably > "\" too, plus all the space characters. I imagine you'd want all the characters that could immediately follow the host name in a URI, so add "?" and "#" to that list. But how well do average users know URI syntax anyway? What would they think of: http://foo.com&bar.baz.xx http://foo.com~bar.baz.xx http://foo.com|bar.baz.xx Maybe we either need to ban all punctuation (as in my proposal about internationalized host names), or always make the boundaries of the domain name apparent to the user (using color or highlighting or underlining or something). > P.S. Of course, the slash homograph attack wouldn't fool the Firefox > SSL domain security indicator anyway, which would still display the > entire domain, fake slashes and all. Yes, but do users understand what that indicator means? If they see foo.com/bar.baz.xx in the indicator, do they understand that it is unrelated to foo.com? AMC From owner-idn@ops.ietf.org Mon Feb 21 02:47:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25900 for ; Mon, 21 Feb 2005 02:47:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D38Cn-0000Rz-9T for idn-data@psg.com; Mon, 21 Feb 2005 07:42:09 +0000 Received: from [203.117.75.21] (helo=red-aura.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D38Ck-0000Re-EH for idn@ops.ietf.org; Mon, 21 Feb 2005 07:42:06 +0000 Received: (qmail 1814 invoked from network); 21 Feb 2005 07:45:09 -0000 Received: from dhcp-apricot-77-249.kyoto.apricot.net (HELO ?202.13.77.249?) (jseng@202.13.77.249) by red-aura.com with RC4-SHA encrypted SMTP; 21 Feb 2005 07:45:09 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <20050221045311.GC31308~@nicemice.net> References: <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> Content-Transfer-Encoding: 7bit From: James Seng Subject: Re: [idn] upstream and downstream Date: Mon, 21 Feb 2005 15:42:05 +0800 To: IETF idn working group X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit the way i look at the '/' problem is that it isn't a IDN problem but rather an URL specific problem. So i think the problem can be resolved in IRI do appropriate mapping. -James Seng On 21-Feb-05, at PM 12:53, Adam M. Costello wrote: > Gervase Markham wrote: > >> What someone posted a day ago about "/" homograph attacks has meant >> that one thing we plan to do is have a short number of characters >> which are completely forbidden in IDN domains at any level - in that, >> mozilla.org products would refuse to recognise IDNs containing them. > > Please think twice before creating a precedent of a browser completely > blackholing a technically valid (albeit devious) site. I think it > would > be sufficient, security-wise, for the browser to inhibit the display of > domain names believed to be misleading, and to display them in ASCII > form instead, but still allow access to the site. > >> My initial list includes the homographs of ":", ".", "/" and probably >> "\" too, plus all the space characters. > > I imagine you'd want all the characters that could immediately follow > the host name in a URI, so add "?" and "#" to that list. > > But how well do average users know URI syntax anyway? What would they > think of: > > http://foo.com&bar.baz.xx > http://foo.com~bar.baz.xx > http://foo.com|bar.baz.xx > > Maybe we either need to ban all punctuation (as in my proposal about > internationalized host names), or always make the boundaries of the > domain name apparent to the user (using color or highlighting or > underlining or something). > >> P.S. Of course, the slash homograph attack wouldn't fool the Firefox >> SSL domain security indicator anyway, which would still display the >> entire domain, fake slashes and all. > > Yes, but do users understand what that indicator means? If they see > foo.com/bar.baz.xx in the indicator, do they understand that it is > unrelated to foo.com? > > AMC > From owner-idn@ops.ietf.org Mon Feb 21 03:22:33 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28481 for ; Mon, 21 Feb 2005 03:22:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D38lM-0006An-82 for idn-data@psg.com; Mon, 21 Feb 2005 08:17:52 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D38lJ-0006AW-BV for idn@ops.ietf.org; Mon, 21 Feb 2005 08:17:49 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D38lB-00024v-00; Mon, 21 Feb 2005 00:17:41 -0800 Date: Mon, 21 Feb 2005 08:17:41 +0000 From: "Adam M. Costello" To: James Seng Cc: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050221081741.GD31308~@nicemice.net> Reply-To: IETF idn working group References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng wrote: > the way i look at the '/' problem is that it isn't a IDN problem > but rather an URL specific problem. So i think the problem can be > resolved in IRI do appropriate mapping. That's an interesting idea. Maybe all homographs of the reserved characters should also be reserved, which would mean they must always be percent-escaped. AMC From owner-idn@ops.ietf.org Mon Feb 21 04:47:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04767 for ; Mon, 21 Feb 2005 04:47:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3A4Q-000Gbf-4D for idn-data@psg.com; Mon, 21 Feb 2005 09:41:38 +0000 Received: from [203.117.75.21] (helo=red-aura.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3A4L-000Gas-NO for idn@ops.ietf.org; Mon, 21 Feb 2005 09:41:35 +0000 Received: (qmail 15543 invoked from network); 21 Feb 2005 09:44:33 -0000 Received: from dhcp-apricot-77-249.kyoto.apricot.net (HELO ?202.13.77.249?) (jseng@202.13.77.249) by red-aura.com with RC4-SHA encrypted SMTP; 21 Feb 2005 09:44:33 -0000 In-Reply-To: <20050221081741.GD31308~@nicemice.net> References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43983878a97b8668b5eaaaac89029891@seng.cc> Content-Transfer-Encoding: 7bit Cc: James Seng From: James Seng Subject: Re: [idn] upstream and downstream Date: Mon, 21 Feb 2005 17:41:29 +0800 To: IETF idn working group X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit We do treat "." specially in IDNA because that's part of domain name. Likewise, IRI should treat '/', '#', spaces etc specially as part of URL handling. (if we ever get around to do email, i expect i18n email identifiers to handle a separate sets of symbols) -James Seng On 21-Feb-05, at PM 04:17, Adam M. Costello wrote: > James Seng wrote: > >> the way i look at the '/' problem is that it isn't a IDN problem >> but rather an URL specific problem. So i think the problem can be >> resolved in IRI do appropriate mapping. > > That's an interesting idea. Maybe all homographs of the reserved > characters should also be reserved, which would mean they must always > be > percent-escaped. > > AMC > From owner-idn@ops.ietf.org Mon Feb 21 06:25:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13126 for ; Mon, 21 Feb 2005 06:25:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3BYz-00069S-3l for idn-data@psg.com; Mon, 21 Feb 2005 11:17:17 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3BYw-00068y-5l for idn@ops.ietf.org; Mon, 21 Feb 2005 11:17:14 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3BYu-0002ma-00 for ; Mon, 21 Feb 2005 03:17:12 -0800 Date: Mon, 21 Feb 2005 11:17:12 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050221111712.GE31308~@nicemice.net> Reply-To: IETF idn working group References: <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> <43983878a97b8668b5eaaaac89029891@seng.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43983878a97b8668b5eaaaac89029891@seng.cc> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk James Seng wrote: > We do treat "." specially in IDNA because that's part of domain name. Yes, but IDNA's special treatment of "." was motivated by user convenience, not by defense against homographs of ".", so it's not surprising that IDNA's special treatment of "." is insufficient to prevent homograph attacks against ".". For example, someone could register a name that looks like "foo.bar.com", where the first dot was really U+0702. This attack would be equally effective no matter what larger structure (URI, email address, etc) the domain name appeared in. AMC From owner-idn@ops.ietf.org Mon Feb 21 06:40:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14928 for ; Mon, 21 Feb 2005 06:40:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3BsA-0008yL-QA for idn-data@psg.com; Mon, 21 Feb 2005 11:37:06 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Bs8-0008xz-S1 for idn@ops.ietf.org; Mon, 21 Feb 2005 11:37:05 +0000 Received: (qmail 28565 invoked by uid 0); 21 Feb 2005 19:40:09 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.038974 secs); 21 Feb 2005 11:40:09 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 1.038974 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 21 Feb 2005 19:40:06 +0800 Message-ID: <4219C7D2.8090602@dready.org> Date: Mon, 21 Feb 2005 22:36:50 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George W Gerrity CC: List Unicode , idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4aba7a4184c288476e81eadc047c15c8@gwg-associates.com.au> In-Reply-To: <4aba7a4184c288476e81eadc047c15c8@gwg-associates.com.au> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit George W Gerrity wrote: > For the second-level (or third-level where the top is a country code) > domain tag, it should be the legal responsibility of the name > authorities for the domain above to ensure that spoofed names cannot > be registered (or if registered, all belong to one owner). In the > Western world, if that is not already the case, then I'm sure that the > first time a spoof of, say Coca-Cola (or Pepsi — let's be even-handed) > is registered, then we can be certain that afterwards, the issuing > authority will never do it again. While it is true that TLDs are responsible for preventing the registration of spoofs, commercial TLDs that have automated registration systems never perform that check. Does registering coca-cola.com prevent someone else from getting coca-co1a.com? > In the case of countries whose law systems are still a bit wild and > wooly (The former Soviet Union?), then I suspect that for the time > being it will remain ‘Caveat Emptor’. In either case, a domain name > holder should be able to license all spoofs for free, in order to > limit its exposure to spoofing, whether or not there is adequate legal > recourse. If the TLD operator is careful, there is no need to license spoofs to protect one's domain from being spoofed. On the other hand, if the TLD does not even perform that check (such as .com), then it is unlikely that you get to license all spoofs for free anyway - you have to pay for each and every permutation of it. > > The point I'm making is that while the authorities for .com.au or > .com.ru may do what they like, we can at least give them advice plus > some tables that will detect many, if not most, spoofs. In the case > where the authority allows (for whatever reason) a name with mixed > orthographies, then clearly the first to apply whose signature is not > a spoof for an (already well-established) trade-marked name or domain > name, should get the license, and all other applicants with a similar > name be refused. The name authority should be protected by the laws of > the countries in which it operates from being sued for refusing to > register confusable names. This is a fairly interesting proposal, i.e. to use the bundling (see draft-klensin-reg-guidelines or rfc3743) to solve the homograph problem at the registry level, provided we can come up with a satisfactory table of lookalikes. As an example, the word "coke" can be represented completely in Cyrillic homographs, so one can generate 16 combinations of ASCII and Cyrillic characters forming strings that look like "coke". When you register "coke.com", the other 16 variants are automatically tied to this domain (for free or for a fee). They can be either all activated (put into the zone file) or simply blocked from registration. The good thing about this is that the lookalikes mapping table does not have to be set-in-stone at the protocol level, but individual registries may choose to implement whatever makes sense for them. The problem with this is that the number of variants gets out of hand pretty quickly, and most registry systems aren't equipped to deal with bundles. wil. From owner-idn@ops.ietf.org Mon Feb 21 07:02:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16928 for ; Mon, 21 Feb 2005 07:02:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3CC8-000BKr-28 for idn-data@psg.com; Mon, 21 Feb 2005 11:57:44 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3CC0-000BJy-KM for idn@ops.ietf.org; Mon, 21 Feb 2005 11:57:36 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D3CBv-0007JO-F3; Mon, 21 Feb 2005 03:57:31 -0800 Message-Id: <6.1.2.0.2.20050221125028.03d20770@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 21 Feb 2005 12:53:05 +0100 To: John C Klensin , "Martin v. Lwis" , tedd From: "JFC (Jefsey) Morfin" Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Cc: idn@ops.ietf.org, Erik van der Poel In-Reply-To: References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:17 21/02/2005, John C Klensin wrote: >(a) such a change would not change the >number of strings or characters that can be registered at all: >only the base characters can actually appear in an IDNA string >post the ToUnicode(ToASCII(char)) operation pair Interesting idea, but you may lose every chance to have a RHD/LHD common support if you make it too simply. On the countrary it permits to have the information to differentiate upper and lower cases if/when needed. jfc From owner-idn@ops.ietf.org Mon Feb 21 14:23:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03526 for ; Mon, 21 Feb 2005 14:23:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3J2F-0002MU-Ey for idn-data@psg.com; Mon, 21 Feb 2005 19:15:59 +0000 Received: from [68.168.78.202] (helo=mta10.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3J25-0002LT-FN for idn@ops.ietf.org; Mon, 21 Feb 2005 19:15:49 +0000 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050221191548.WVAC9599.mta10.adelphia.net@DEWELL>; Mon, 21 Feb 2005 14:15:48 -0500 Message-ID: <03f301c51849$983c6020$030aa8c0@DEWELL> From: "Doug Ewell" To: , "Unicode Mailing List" Cc: "Hans Aberg" , =?utf-8?Q?Keld_J=C3=83=C2=B8rn_Simonsen?= , "Erik van der Poel" References: Subject: Re: [idn] IDN spoofing Date: Mon, 21 Feb 2005 11:14:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hans Aberg wrote: >> That isn't the point. It doesn't matter if the mapping takes place >> at the character-encoding level or at some other level. The problem >> of determining which pairs of characters are confusable and should be >> folded together, and which pairs aren't and shouldn't, still remains >> to be solved. > > If one does the way, no characters or character sequences are actually > folded together, but one defines a semantics which tells which > character sequences should have the same semantics. Well, whatever. You know what I mean: "which pairs of characters should be treated the same for IDN purposes." >> And for something like IDNs, once you have decided on a mapping, you >> can never, ever change it. Otherwise you will have a domain name >> available for registration by customer A today, but a similar one not >> available to customer B six months later (or vice versa, A can't get >> it but B can). Either way, you have a lawsuit. > > Sure you can change it: One can make the equivalence classes smaller, > whenever one wants. For example, upper and lower case letters are now > considered equivalent. One takes that equivalence away, names must be > used as registered with respect to casing. If one introduces new > equivalence classes, then one must run through all registered names, > and require that names that are merged onto each other are changed. > But if one is sufficiently conservative when defining these > equivalences, that should not happen too often. For example, if now > Latin "o" and Greek "omicron" are viewed inequivalent but are declared > equivalent, then, if more than one user has used the name "foo" in > various combinations of the letter, then all but one must change > registration name. You make it sound so easy. Try explaining to a company that has advertised its Web address all over television, radio, newspapers, magazines, billboards, and business cards that they now have to change their address because someone changed the IDN rules. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Mon Feb 21 15:08:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08465 for ; Mon, 21 Feb 2005 15:08:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Jmt-0009TJ-AX for idn-data@psg.com; Mon, 21 Feb 2005 20:04:11 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Jms-0009Sx-4O for idn@ops.ietf.org; Mon, 21 Feb 2005 20:04:10 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1LK3fpY317110; Mon, 21 Feb 2005 15:03:46 -0500 Message-ID: <421A3E9C.5020204@vanderpoel.org> Date: Mon, 21 Feb 2005 12:03:40 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans Aberg CC: Doug Ewell , idn@ops.ietf.org, Unicode Mailing List , =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= Subject: Re: [idn] IDN spoofing References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hans Aberg wrote: > Sure you can change it: One can make the equivalence classes smaller, > whenever one wants. As a mathematician, one might be inclined to think that way. But here, we're not talking about theoretical mathematics. We're talking about network engineering. A totally different way of thinking. You can't just change the mapping whenever you want because there are many (client and server) installations out there that can't be changed overnight (what is known in network parlance as a "flag day"). For example, even if a registry were to change their mapping, go through their entire database, and delete the names that are determined to be duplicates (however one might accomplish that), there will be people with the old version of the app, which uses the old mapping, and will not be able to find the name (since it has been deleted). Now, this might be a good thing if the name is an evil spoof, but what about innocent registrations? What if two separate parties have an equally legitimate claim on a particular name? This happens a lot in the ASCII DNS, and basically, whoever got there first (or is willing to pay a lot of money) wins. One way to continue to support these innocent duplicates is to use a different prefix (i.e. something other than xn--) in the new mapping, and keep the old names (with the old prefix) in the database (instead of deleting them). This way, the old clients continue to find the old innocent names. But what about the new clients? Now they will suddenly end up on a different Web site when the user clicks on a link. I suppose the user will just have to update their client, or the domain name owner will have to register a different name and update all the Web pages to point to the different name (assuming that they even have control over *all* of the Web pages that might contain a link to their site). And so on. Do you get it now? You can't just change the mapping "whenever" you want. If you do this at all, you do it as few times as possible. Now, you may point out that we are just getting started with IDN and that not very many names have been registered (and I may even agree with you), but it would still take a while to come up with a better mapping (and reach consensus on it -- shudder), and in the meantime, more names would be registered. And this still would not negate my main point, which is that you can't do this "whenever" you want. Erik From owner-idn@ops.ietf.org Mon Feb 21 15:29:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11491 for ; Mon, 21 Feb 2005 15:29:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3K7p-000Cfx-Nl for idn-data@psg.com; Mon, 21 Feb 2005 20:25:49 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3K7o-000Cfk-Nr for idn@ops.ietf.org; Mon, 21 Feb 2005 20:25:48 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1LKPUuq383684; Mon, 21 Feb 2005 15:25:35 -0500 Message-ID: <421A43B9.4060505@vanderpoel.org> Date: Mon, 21 Feb 2005 12:25:29 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hans Aberg CC: Doug Ewell , idn@ops.ietf.org, Unicode Mailing List , =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= Subject: Re: [idn] IDN spoofing References: <421A3E9C.5020204@vanderpoel.org> In-Reply-To: <421A3E9C.5020204@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > But what about the new clients? Now they will suddenly end up on a > different Web site when the user clicks on a link. I suppose the user > will just have to update their client Sorry, I don't know how that last part got in there. Brain fart? Erik From owner-idn@ops.ietf.org Mon Feb 21 16:39:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17924 for ; Mon, 21 Feb 2005 16:39:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3LBi-000NHk-5X for idn-data@psg.com; Mon, 21 Feb 2005 21:33:54 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3LBh-000NHY-6b for idn@ops.ietf.org; Mon, 21 Feb 2005 21:33:53 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1LLXEuq419934; Mon, 21 Feb 2005 16:33:14 -0500 Message-ID: <421A5399.7030503@vanderpoel.org> Date: Mon, 21 Feb 2005 13:33:13 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Tan CC: George W Gerrity , List Unicode , idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4aba7a4184c288476e81eadc047c15c8@gwg-associates.com.au> <4219C7D2.8090602@dready.org> In-Reply-To: <4219C7D2.8090602@dready.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit William Tan wrote: > As an example, the word "coke" can be represented completely in Cyrillic > homographs, so one can generate 16 combinations of ASCII and Cyrillic > characters forming strings that look like "coke". When you register > "coke.com", the other 16 variants are automatically tied to this domain > (for free or for a fee). They can be either all activated (put into the > zone file) or simply blocked from registration. > > The good thing about this is that the lookalikes mapping table does not > have to be set-in-stone at the protocol level, but individual registries > may choose to implement whatever makes sense for them. If the lookalike mapping is not set in stone at the protocol level (i.e. embedded in the app), then the registry will have to activate *all* the variants, otherwise the app will not be able to look up all of them. No? Alternatively, you could embed each registry's lookalike mapping table into the app and just activate one of the variants. I feel like I'm missing something... Erik From owner-idn@ops.ietf.org Mon Feb 21 16:44:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18477 for ; Mon, 21 Feb 2005 16:44:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3LJm-000OLa-Vv for idn-data@psg.com; Mon, 21 Feb 2005 21:42:14 +0000 Received: from [68.168.78.199] (helo=mta9.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3LJl-000OLH-3L for idn@ops.ietf.org; Mon, 21 Feb 2005 21:42:13 +0000 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050221214212.DNSG23122.mta9.adelphia.net@DEWELL>; Mon, 21 Feb 2005 16:42:12 -0500 Message-ID: <043401c5185d$ff03ee40$030aa8c0@DEWELL> From: "Doug Ewell" To: , "Unicode List" Cc: "Hans Aberg" , "George W Gerrity" References: Subject: Re: [idn] IDN spoofing Date: Mon, 21 Feb 2005 13:40:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hans Aberg wrote: > The suggestion I made, was to use a function to detect confusables by > declaring them equivalent, but retaining the full Unicode character > set for representing the IDN's. If this is used at the registration > level only, the only thing that happens when somebody enters a > confusable, is that it is rejected. There is a problem only when an > authority admits parallel, confusable names to be registered. Granted. The problem, as I have said so often, is determining what the set of "confusables" is. Don't just say a/а and o/ο, either; that's only the tip of the iceberg. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Mon Feb 21 16:55:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19313 for ; Mon, 21 Feb 2005 16:55:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3LT3-000Pka-Jj for idn-data@psg.com; Mon, 21 Feb 2005 21:51:49 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3LT1-000PkC-LQ for idn@ops.ietf.org; Mon, 21 Feb 2005 21:51:48 +0000 Received: (qmail 834 invoked by uid 0); 22 Feb 2005 05:54:52 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.790902 secs); 21 Feb 2005 21:54:52 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.790902 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 22 Feb 2005 05:54:50 +0800 Message-ID: <421A57E4.2000207@dready.org> Date: Tue, 22 Feb 2005 08:51:32 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: George W Gerrity , List Unicode , idn@ops.ietf.org Subject: Re: [idn] IDN spoofing References: <4aba7a4184c288476e81eadc047c15c8@gwg-associates.com.au> <4219C7D2.8090602@dready.org> <421A5399.7030503@vanderpoel.org> In-Reply-To: <421A5399.7030503@vanderpoel.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > If the lookalike mapping is not set in stone at the protocol level > (i.e. embedded in the app), then the registry will have to activate > *all* the variants, otherwise the app will not be able to look up all > of them. No? For many variants, it's good enough to block them from being registered by phishers. One wouldn't expect the users to type in "coca-co1a.com" (with latin "1" instead of "l"), right? > Alternatively, you could embed each registry's lookalike mapping table > into the app and just activate one of the variants. I feel like I'm > missing something... > That wouldn't be a good idea, for reasons that John explained in an earlier mail about blacklists. wil. From owner-idn@ops.ietf.org Mon Feb 21 16:56:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19341 for ; Mon, 21 Feb 2005 16:56:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3LUn-00002L-2C for idn-data@psg.com; Mon, 21 Feb 2005 21:53:37 +0000 Received: from [68.168.78.199] (helo=mta9.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3LUm-000020-4b for idn@ops.ietf.org; Mon, 21 Feb 2005 21:53:36 +0000 Received: from DEWELL ([68.66.2.217]) by mta9.adelphia.net (InterMail vM.6.01.03.04 201-2131-111-106-20040729) with SMTP id <20050221215335.EFBX23122.mta9.adelphia.net@DEWELL>; Mon, 21 Feb 2005 16:53:35 -0500 Message-ID: <044e01c5185f$97d97da0$030aa8c0@DEWELL> From: "Doug Ewell" To: "Hans Aberg" , Cc: , "Unicode Mailing List" , =?utf-8?Q?Keld_J=C3=83=C2=B8rn_Simonsen?= , "Erik van der Poel" References: Subject: Re: [idn] IDN spoofing Date: Mon, 21 Feb 2005 13:52:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Once more from Hans Aberg : > ... For example, Latin and Greek "A" are equal. Then this forces > lowercase "a" and alpha top become equivalent, despite the fact that > no-one familiar with these scripts will confuse them. Not everyone is familiar with all these scripts, or expects them to appear arbitrarily mixed. That's why there's a spoofing problem. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Mon Feb 21 18:42:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29825 for ; Mon, 21 Feb 2005 18:42:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3N84-000Dqm-Im for idn-data@psg.com; Mon, 21 Feb 2005 23:38:16 +0000 Received: from [193.201.200.34] (helo=tuschin.blackcatnetworks.co.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3N83-000Dqa-Jr for idn@ops.ietf.org; Mon, 21 Feb 2005 23:38:15 +0000 Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.100]) by tuschin.blackcatnetworks.co.uk with asmtp (Exim 3.35 #1 (Debian)) id 1D3N82-0002UL-00 for ; Mon, 21 Feb 2005 23:38:14 +0000 Message-ID: <421A70B0.5030008@mozilla.org> Date: Mon, 21 Feb 2005 23:37:20 +0000 From: Gervase Markham Organization: mozilla.org User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> In-Reply-To: <20050221045311.GC31308~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > Please think twice before creating a precedent of a browser completely > blackholing a technically valid (albeit devious) site. If the site is devious, what possible benefit is there in allowing the user access to it? If someone came up with a valid use for this character in IDNs, that would be different. >>My initial list includes the homographs of ":", ".", "/" and probably >>"\" too, plus all the space characters. > > I imagine you'd want all the characters that could immediately follow > the host name in a URI, so add "?" and "#" to that list. Yes. It is looking a bit like "all punctuation", isn't it? But then, I bet there are some characters which look like punctuation. The Chinese character for the number 1 looks fairly like a hyphen. >>P.S. Of course, the slash homograph attack wouldn't fool the Firefox >>SSL domain security indicator anyway, which would still display the >>entire domain, fake slashes and all. > > Yes, but do users understand what that indicator means? If they see > foo.com/bar.baz.xx in the indicator, do they understand that it is > unrelated to foo.com? Well, it would certainly be different to all the other times they'd visited mybank.com, so hopefully that would give them some pause. Gerv From owner-idn@ops.ietf.org Mon Feb 21 18:42:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29847 for ; Mon, 21 Feb 2005 18:42:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3N5U-000DXO-6Q for idn-data@psg.com; Mon, 21 Feb 2005 23:35:36 +0000 Received: from [193.201.200.34] (helo=tuschin.blackcatnetworks.co.uk) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3N5T-000DX8-8U for idn@ops.ietf.org; Mon, 21 Feb 2005 23:35:35 +0000 Received: from grmarkham.plus.com ([80.229.30.161] helo=[192.168.1.100]) by tuschin.blackcatnetworks.co.uk with asmtp (Exim 3.35 #1 (Debian)) id 1D3N5Q-0007Qp-00 for ; Mon, 21 Feb 2005 23:35:32 +0000 Message-ID: <421A700D.2060609@mozilla.org> Date: Mon, 21 Feb 2005 23:34:37 +0000 From: Gervase Markham Organization: mozilla.org User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <4218A1D0.2040703@vanderpoel.org> <002c01c51770$b0f74be0$030aa8c0@DEWELL> <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> In-Reply-To: <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > the way i look at the '/' problem is that it isn't a IDN problem but > rather an URL specific problem. So i think the problem can be resolved > in IRI do appropriate mapping. I'm afraid I don't understand what you are proposing. :-( Gerv From owner-idn@ops.ietf.org Mon Feb 21 18:48:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00238 for ; Mon, 21 Feb 2005 18:48:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3NDf-000Eln-VE for idn-data@psg.com; Mon, 21 Feb 2005 23:44:03 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3NDf-000Ela-3r for idn@ops.ietf.org; Mon, 21 Feb 2005 23:44:03 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3NDd-0005xn-00 for ; Mon, 21 Feb 2005 15:44:01 -0800 Date: Mon, 21 Feb 2005 23:44:01 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050221234401.GA20718~@nicemice.net> Reply-To: IETF idn working group References: <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> <43983878a97b8668b5eaaaac89029891@seng.cc> <20050221111712.GE31308@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050221111712.GE31308@nicemice.net> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk I wrote: > IDNA's special treatment of "." is insufficient to prevent homograph > attacks against ".". > > For example, someone could register a name that looks like > "foo.bar.com", where the first dot was really U+0702. This attack > would be equally effective no matter what larger structure (URI, email > address, etc) the domain name appeared in. On second thought, the "." homograph attack is less severe than the "/" homograph attack. The former only allows the attacker to spoof names in the same domain that the attacker is registered in; therefore new registrants can protect themselves from this attack by registering in a domain with reasonable admission policies. The "/" attack, however, allows the attacker to spoof names in *any* domain, so there's nowhere registrants can go and be safe from it. The more severe attack can happen only when domain names are embedded in larger structures, so a case could be made that each of these larger structures should create its own recommendations for dealing with spoofs of its delimiters. On the other hand, non-technical users might be misled by all sorts of punctuation, even symbols that don't resemble the true delimiters. AMC From owner-idn@ops.ietf.org Mon Feb 21 19:19:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03285 for ; Mon, 21 Feb 2005 19:19:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3NgU-000K0O-Ha for idn-data@psg.com; Tue, 22 Feb 2005 00:13:50 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3NgT-000K0B-42 for idn@ops.ietf.org; Tue, 22 Feb 2005 00:13:49 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1M0DVHb192492; Mon, 21 Feb 2005 19:13:31 -0500 Message-ID: <421A792B.2050207@vanderpoel.org> Date: Mon, 21 Feb 2005 16:13:31 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , tedd , idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, I'm probably missing something, but if the apps are not currently warning the user when characters from blocks that ought to be banned appear, then people and/or tools may be generating references (e.g. HTML documents) to those characters, without realizing that those characters are being mapped to some other base characters, which then work OK in the DNS lookup. Maybe it is unlikely that a lot of such references would come to exist, and it wouldn't be such a burden to the user of a new app to see the occasional error e.g. when they click on such a link. But how do you determine how many HTML documents contain bad characters in their links, and how do you decide that that number is low enough to make such a change to the spec? So I'm wondering if you would really be able to state that such a change "would largely impact what can be registered". How do you know that such a change does not also impact the users of new clients accessing existing documents? Oh wait, I know! Just get Google to do a survey in their cache? Erik John C Klensin wrote: > (i) A change that would largely impact what can be registered > needs to be reflected and implemented only in 250-odd > registries. The registry operators are mostly on their toes, > communicate with each other, and many of them are pretty early > in their implementation of IDNs and conservative about what they > are permitting. Getting them to make changes is an entirely > different sort of problem than, e.g., trying to change > already-installed browsers or client plugins or getting people > to upgrade them. > > (ii) The main things I've seen in observing and working with > registries that I didn't understand well enough a couple of > years ago to argue forcefully are things that we might be able > to change because the impact of whether someone was running an > old or new version would not be large. For example, IDNA makes > some mappings that are dubious, not in the technical sense of > whether the characters are equivalent, but in the human factors > sense of whether treating them as equivalent leads to bad > habits. To take a handy example from a Roman ("Latin")-based > script, I now suspect that permitting all of those font-variant > "mathematical" characters to map onto their lower-case ASCII > equivalents is a bad idea, just because it encourages users to > assume that, if something looks like a particular base > character, it is that character. That, in turn, increases the > perceptual window for these phishing attacks. If, instead, we > had simply banned those characters, creating an error if someone > tried to use one rather than a quiet mapping into something > else, we might have been better off. So I now think we should > have banned them when IDNA and nameprep were defined and think I > could have made that case very strongly had I understood the > issues the way I do now. Is it worth making that change today? > I don't know. But I suggest that it would be possible to make > it for two reasons: (a) such a change would not change the > number of strings or characters that can be registered at all: > only the base characters can actually appear in an IDNA string > post the ToUnicode(ToASCII(char)) operation pair and (b) if I > were a browser or other application producer, I'd be seriously > considering warnings if any characters from those blocks > appeared... something IDNA certainly does not prohibit. Changes > that increased the number of registerable characters are > problematic, but not that problematic if they don't pick up a > character that now maps and make it "real" (which is the problem > with deciding that upper case Omega is a good idea). Reducing > the number of characters that can be registered --making a > now-valid base character invalid-- would be a much harder > problem. From owner-idn@ops.ietf.org Mon Feb 21 19:38:35 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04957 for ; Mon, 21 Feb 2005 19:38:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3O0h-000MZN-6A for idn-data@psg.com; Tue, 22 Feb 2005 00:34:43 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3O0g-000MZ4-4R for idn@ops.ietf.org; Tue, 22 Feb 2005 00:34:42 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1M0YQSJ116852; Mon, 21 Feb 2005 19:34:31 -0500 Message-ID: <421A7E11.60201@vanderpoel.org> Date: Mon, 21 Feb 2005 16:34:25 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , tedd , idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> <421A792B.2050207@vanderpoel.org> In-Reply-To: <421A792B.2050207@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > I'm probably missing something, but if the apps are not currently > warning the user when characters from blocks that ought to be banned > appear, then people and/or tools may be generating references (e.g. HTML > documents) to those characters, without realizing that those characters > are being mapped to some other base characters, which then work OK in > the DNS lookup. > > Maybe it is unlikely that a lot of such references would come to exist, > and it wouldn't be such a burden to the user of a new app to see the > occasional error e.g. when they click on such a link. > > But how do you determine how many HTML documents contain bad characters > in their links, and how do you decide that that number is low enough to > make such a change to the spec? > > So I'm wondering if you would really be able to state that such a change > "would largely impact what can be registered". Sorry, this last part is a mistake. Banning characters that were previously mapped to others does *not* affect what can be registered. Duh. But please consider the other parts of my email. Erik From owner-idn@ops.ietf.org Mon Feb 21 22:59:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29372 for ; Mon, 21 Feb 2005 22:59:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3R3Y-000O7h-2j for idn-data@psg.com; Tue, 22 Feb 2005 03:49:52 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3R3T-000O7N-2U for idn@ops.ietf.org; Tue, 22 Feb 2005 03:49:47 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3R3R-0007Qb-00 for ; Mon, 21 Feb 2005 19:49:45 -0800 Date: Tue, 22 Feb 2005 03:49:45 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050222034945.GA20176~@nicemice.net> Reply-To: IETF idn working group References: <421746D7.4070102@vanderpoel.org> <42176970.3050704@vanderpoel.org> <20050219214029.GA5457~@nicemice.net> <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <421A70B0.5030008@mozilla.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421A70B0.5030008@mozilla.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Gervase Markham wrote: > > Please think twice before creating a precedent of a browser > > completely blackholing a technically valid (albeit devious) site. > > If the site is devious, what possible benefit is there in allowing the > user access to it? The user might be investigating alleged phishers (who are targeting browsers less protective than the investigator's). Users often guess domain names. There might be cases where the common name of an organization includes non-ASCII punctuation that browsers would consider unsafe to display, but the organization might want to put a web server there that redirects users to a safe name when they type the unsafe name as a guess. Finally, I don't think we can be sure that our automated phishing detector has no false positives, so I think making sites completely inaccessible is overkill when it would be sufficient merely to foil the spoof by showing an unambiguous form of the name (like the ACE form, or a Unicode form with certain characters percent-encoded). AMC From owner-idn@ops.ietf.org Mon Feb 21 23:06:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00670 for ; Mon, 21 Feb 2005 23:06:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3RCV-000PiA-At for idn-data@psg.com; Tue, 22 Feb 2005 03:59:07 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3RCR-000PhX-H4 for idn@ops.ietf.org; Tue, 22 Feb 2005 03:59:04 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1M3wnpY157258; Mon, 21 Feb 2005 22:58:49 -0500 Message-ID: <421AADF8.7050409@vanderpoel.org> Date: Mon, 21 Feb 2005 19:58:48 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: John C Klensin , =?ISO-8859-1?Q?=22Martin_v=2E_L?= =?ISO-8859-1?Q?=F6wis=22?= , tedd , idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> <421A792B.2050207@vanderpoel.org> In-Reply-To: <421A792B.2050207@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been wondering whether my email was clear or not. The kind of reference I'm talking about is the kind that started this whole IDN spoofing discussion: > I'm probably missing something, but if the apps are not currently > warning the user when characters from blocks that ought to be banned > appear, then people and/or tools may be generating references (e.g. HTML > documents) to those characters, without realizing that those characters > are being mapped to some other base characters, which then work OK in > the DNS lookup. > > Maybe it is unlikely that a lot of such references would come to exist, > and it wouldn't be such a burden to the user of a new app to see the > occasional error e.g. when they click on such a link. > > But how do you determine how many HTML documents contain bad characters > in their links, and how do you decide that that number is low enough to > make such a change to the spec? > > [...] How do you know that such > a change does not also impact the users of new clients accessing > existing documents? > > Oh wait, I know! Just get Google to do a survey in their cache? > > John C Klensin wrote: > >> (i) A change that would largely impact what can be registered >> needs to be reflected and implemented only in 250-odd >> registries. The registry operators are mostly on their toes, >> communicate with each other, and many of them are pretty early >> in their implementation of IDNs and conservative about what they >> are permitting. Getting them to make changes is an entirely >> different sort of problem than, e.g., trying to change >> already-installed browsers or client plugins or getting people >> to upgrade them. >> >> (ii) The main things I've seen in observing and working with >> registries that I didn't understand well enough a couple of >> years ago to argue forcefully are things that we might be able >> to change because the impact of whether someone was running an >> old or new version would not be large. For example, IDNA makes >> some mappings that are dubious, not in the technical sense of >> whether the characters are equivalent, but in the human factors >> sense of whether treating them as equivalent leads to bad >> habits. To take a handy example from a Roman ("Latin")-based >> script, I now suspect that permitting all of those font-variant >> "mathematical" characters to map onto their lower-case ASCII >> equivalents is a bad idea, just because it encourages users to >> assume that, if something looks like a particular base >> character, it is that character. That, in turn, increases the >> perceptual window for these phishing attacks. If, instead, we >> had simply banned those characters, creating an error if someone >> tried to use one rather than a quiet mapping into something >> else, we might have been better off. So I now think we should >> have banned them when IDNA and nameprep were defined and think I >> could have made that case very strongly had I understood the >> issues the way I do now. Is it worth making that change today? >> I don't know. But I suggest that it would be possible to make >> it for two reasons: (a) such a change would not change the >> number of strings or characters that can be registered at all: >> only the base characters can actually appear in an IDNA string >> post the ToUnicode(ToASCII(char)) operation pair and (b) if I >> were a browser or other application producer, I'd be seriously >> considering warnings if any characters from those blocks >> appeared... something IDNA certainly does not prohibit. Changes >> that increased the number of registerable characters are >> problematic, but not that problematic if they don't pick up a >> character that now maps and make it "real" (which is the problem >> with deciding that upper case Omega is a good idea). Reducing >> the number of characters that can be registered --making a >> now-valid base character invalid-- would be a much harder >> problem. From owner-idn@ops.ietf.org Tue Feb 22 00:25:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10727 for ; Tue, 22 Feb 2005 00:25:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3SR6-000BGY-MJ for idn-data@psg.com; Tue, 22 Feb 2005 05:18:16 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3SR4-000BG8-Q2 for idn@ops.ietf.org; Tue, 22 Feb 2005 05:18:15 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1M5I7SJ096280; Tue, 22 Feb 2005 00:18:08 -0500 Message-ID: <421AC08F.2030207@vanderpoel.org> Date: Mon, 21 Feb 2005 21:18:07 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org, List Unicode CC: George W Gerrity Subject: [idn] nameprep, IDN spoofing and the registries References: <421A3E9C.5020204@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit OK, I think this latest flurry of emails is starting to form a picture of What We Must Do (re: nameprep, IDN spoofing and the registries): Basically, the work to install filters at the registries, and the work to write the next version of the nameprep spec can proceed in parallel, pretty much independently. As George points out, the registries are going to have to start filtering IDN lookalikes, otherwise they will eventually face lawsuits from the "big boys" (as George so delightfully puts it). The ccTLDs will have a relatively easy task, while the gTLDs like .com will have the difficult task of deciding which subset of Unicode to allow. They will also have to go through their database, looking for lookalikes, and deleting them or transferring them to new owners, probably paying their previous owners back. The registrars might have to be involved in the money transaction too. What a mess. I don't envy the gTLDs. Maybe the Unicode Consortium could help them out by providing homograph tables. One possible approach for the gTLDs is to halt IDN registration now. Then they can work on their filters, starting with a small subset of Unicode. After reopening IDN registration, they can grow the subset if there is enough demand for characters outside the initial subset. If the gTLDs are going to do some serious subsetting, then they will probably also need to provide software to the registrars that will map users' characters into the subset. E.g. converting a user's local charset to the subset of Unicode. Then again, this might be an area where registrars could compete with each other, to provide the most friendly software to the end-user (registrant). On the other side, we have the nameprep spec, and the work required to rev it. As John Klensin points out in another email, nameprep will eventually have to be updated to include new Unicode characters. Nameprep specifies Unicode 3.2, but Unicode itself is already at 4.0.1, and may be even further along by the time we finish discussing and drafting nameprep bis (new version). Call it nameprep2. Now, one item that is clearly on nameprep2's table is the new version of Unicode. Another item that could be considered is the banning of slash '/' homographs and others. This type of spoofing was recently discussed on the IDN list. Certain Unicode blocks, like the math characters, might also be banned instead of mapped as they are now. And I'm sure we would discuss mapping or banning the homographs, such as Cyrillic small 'a'. A lot of this is likely to be controversial, and some people might suggest that we leave the subsetting to the registries, since they have to do it anyway. So, instead of shrinking the character set, nameprep2 might just grow it (for the new version of Unicode). I don't know. We'll see. I'm not sure whether we would need a new ACE prefix if we are only adding characters (and not removing any). I'm too tired right now to think about it. Erik George W Gerrity wrote: > The two references below summarise much that has been said about the > difficulty of dealing with the internationalisation of Domain Names. Let > us agree once and for all: > > 1. The completely general problem is mathematically */and/* > computationally intractable, even if we use fuzzy mapping; > > 2. The problem is a typical engineering challenge to find a workable > solution — future-proofed as much as possible — which is minimally complex; > > 3. If the engineers (us?) don't solve it, the lawyers will have a > heyday, the courts will find expensive solutions, the cost of running > the web will blow out, and all of us will have mud all over our faces. > > 4. Now is the time — when there are only a very few registered names > with possible clashes — to do it before we */have/* to go through the > painful process of unregistering names and upgrading TLD machine codes. > > So let's sketch out an approach, using <.com.ru> as an example. > > a) The <.com.ru> registrar only accepts latin characters for that domain > name, or only accepts Cyrillic characters, */no mix/*, and maps the two > as equivalent. Case-equivalence mapping */may/* also be allowed, at a > cost of more complexity. Let the registrar decide that, and let's be > sure that as far as possible, the issuing authority licencing the TLD to > the registrar ensures legal protection for these */arbitrary/*, but > fixed decisions. > > b) the first filter selects name tags whose codes (including diacritics, > etc) are either not all in the Cyrillic block or the Latin block(s) for > special attention. > > My guess is that at this point, only a few percent will require special > attention. > > c) At this point, the <.com.ru> registrar will need to exercise some > common sense. For instance, it seems unreasonable that this domain > should accept codes outside the Latin and Cyrillic code blocks, and if > they do, then mixes should be strongly discouraged. Certainly, the use > of, say, Hebrew vowel pointing with Latin Codes, while perhaps > acceptable in Israel TLD, should be unacceptable in the Russia TLD. In > fact, as a general rule, mixes of diacritics from one code block with > code points from another, should never be allowed. > > Further rules can limit legal sequences of the allowed mixes. For > instance, in alphabetic scripts such as Latin and Cyrillic, isolated > code points from one script found in another make no sense unless > spoofing is intended. Earlier, I suggested that a code-point string of a > single script found mixed with strings of other scripts, should be of > minimum length 2. One can also limit the number of separate substrings > of an alternate script found interspersed with a dominant (national?) > script. > > These sort of common-sense rules can be easily implemented and the > computational overhead is minimal. Of course, owners of ridiculous trade > marks (such as , “KIΛ”, for the brand name of the > automobile “KIA”) will disagree, but realism has to intrude somewhere > into the free market economy. > > The problems for universal TLDs (<.com>, <.net>) are far more complex, > because they are required to accept all language scripts. At the TLD > itself, one can allow a limited, but finite number of character strings > to be equivalent, including the rule that script mixtures are > inadmissable, but maybe case folding will be allowed. > > Once again, however, application of some judicious sieve filters and > rules about how mixed scripts may be composed, can simplify the handling > of the name tags. There are also sieve rules that can immediately throw > out most inadmissable combinations, such as the string length rule > mentioned above. Those strings remaining can be tossed to a human, who > will be required to be an expert in orthography (nice new line of > business for many on the Unicode list?). > > Now, it doesn't make sense for these rules to be part of a standard on > how to extend Domain names to use scripts other than Latin: they are > much better handled as (algorithmic where possible) regulations > specified by the authority for a given TLD, or set of TLDs, in the case > of the universal TLDs. > > By using this approach, and starting off with a set of rules that > disallow most forms of script mixes, then where appeals to common sense > and the wishes of a reasonable number of potential clients suggest a > loosening of the rules, this can be done with little disruption to the > existing state of affairs. > > George > ------ > > On 22 Feb 2005, at 08:40, Doug Ewell wrote: > > Hans Aberg wrote: > > The suggestion I made, was to use a function to detect > confusables by > declaring them equivalent, but retaining the full Unicode character > set for representing the IDN's. If this is used at the registration > level only, the only thing that happens when somebody enters a > confusable, is that it is rejected. There is a problem only when an > authority admits parallel, confusable names to be registered. > > > Granted. The problem, as I have said so often, is determining what the > set of "confusables" is. Don't just say a/а and o/ο, either; that's > only the tip of the iceberg. > > > On 22 Feb 2005, at 07:03, Erik van der Poel wrote: > > Hans Aberg wrote: > > Sure you can change it: One can make the equivalence classes > smaller, > whenever one wants. > > > As a mathematician, one might be inclined to think that way. But > here, we're not talking about theoretical mathematics. We're talking > about network engineering. A totally different way of thinking. > > You can't just change the mapping whenever you want because there > are many (client and server) installations out there that can't be > changed overnight (what is known in network parlance as a "flag day"). > > For example, even if a registry were to change their mapping, go > through their entire database, and delete the names that are > determined to be duplicates (however one might accomplish that), > there will be people with the old version of the app, which uses the > old mapping, and will not be able to find the name (since it has > been deleted). > > Now, this might be a good thing if the name is an evil spoof, but > what about innocent registrations? What if two separate parties have > an equally legitimate claim on a particular name? This happens a lot > in the ASCII DNS, and basically, whoever got there first (or is > willing to pay a lot of money) wins. > > One way to continue to support these innocent duplicates is to use a > different prefix (i.e. something other than xn--) in the new > mapping, and keep the old names (with the old prefix) in the > database (instead of deleting them). This way, the old clients > continue to find the old innocent names. > > But what about the new clients? Now they will suddenly end up on a > different Web site when the user clicks on a link. I suppose the > user will just have to update their client, or the domain name owner > will have to register a different name and update all the Web pages > to point to the different name (assuming that they even have control > over *all* of the Web pages that might contain a link to their site). > > And so on. Do you get it now? You can't just change the mapping > "whenever" you want. If you do this at all, you do it as few times > as possible. > > Now, you may point out that we are just getting started with IDN and > that not very many names have been registered (and I may even agree > with you), but it would still take a while to come up with a better > mapping (and reach consensus on it -- shudder), and in the meantime, > more names would be registered. > > And this still would not negate my main point, which is that you > can't do this "whenever" you want. > > Erik From owner-idn@ops.ietf.org Tue Feb 22 00:58:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15266 for ; Tue, 22 Feb 2005 00:58:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3SzP-000Gkd-S2 for idn-data@psg.com; Tue, 22 Feb 2005 05:53:43 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3SzF-000Gj6-KU for idn@ops.ietf.org; Tue, 22 Feb 2005 05:53:33 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D3SzC-000Nbb-3u; Tue, 22 Feb 2005 00:53:30 -0500 Date: Tue, 22 Feb 2005 00:53:29 -0500 From: John C Klensin To: Erik van der Poel cc: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , tedd , idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: In-Reply-To: <421A792B.2050207@vanderpoel.org> References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> <421A792B.2050207@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 21 February, 2005 16:13 -0800 Erik van der Poel wrote: > John, > > I'm probably missing something, but if the apps are not > currently warning the user when characters from blocks that > ought to be banned appear, then people and/or tools may be > generating references (e.g. HTML documents) to those > characters, without realizing that those characters are being > mapped to some other base characters, which then work OK in > the DNS lookup. You are, of course, correct. While warning others to think about things from the user and content-generator side of things rather than the registrar/registry side, I made a similar mistake that probably leads to an incorrect conclusion. My assumption was that those who registered names and constructed links would end up with the domain names in those links that were equivalent of ToUnicode(ToASCII(whatever-was-submitted-for-registration), i.e., base characters only. That would certainly be the result of a number of the processes for obtaining those links that crossed my mind. But you are quite right, nothing requires it and references could be constructed using non-base characters. For languages with clear case distinctions, one would actually predict that it would occur: just as the owner of coolhotjunk.xyz might prefer to have it in the DNS and references as CoolHotJunk.xyz, I'd expect funny mixed case strings in IDNs which, under IDNA, would of course go into the DNS as the punycode encoding of the lowercase-only form. > Maybe it is unlikely that a lot of such references would come > to exist, and it wouldn't be such a burden to the user of a > new app to see the occasional error e.g. when they click on > such a link. > > But how do you determine how many HTML documents contain bad > characters in their links, and how do you decide that that > number is low enough to make such a change to the spec? > > So I'm wondering if you would really be able to state that > such a change "would largely impact what can be registered". > How do you know that such a change does not also impact the > users of new clients accessing existing documents? > > Oh wait, I know! Just get Google to do a survey in their cache? :-( Mumble. What a mess. john From owner-idn@ops.ietf.org Tue Feb 22 01:05:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16650 for ; Tue, 22 Feb 2005 01:05:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3T6F-000Ibr-GC for idn-data@psg.com; Tue, 22 Feb 2005 06:00:47 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3T6C-000IbS-9N for idn@ops.ietf.org; Tue, 22 Feb 2005 06:00:44 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D3T68-000Ndl-WD; Tue, 22 Feb 2005 01:00:41 -0500 Date: Tue, 22 Feb 2005 01:00:40 -0500 From: John C Klensin To: Erik van der Poel cc: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= , tedd , idn@ops.ietf.org Subject: Re: [idn] quick & dirty (but not too dirty) homograph defense Message-ID: <6A992935F1F58FE11475B3B4@scan.jck.com> In-Reply-To: <421AADF8.7050409@vanderpoel.org> References: <200502201529.j1KFTKdU091474@bartok.nlnetlabs.nl> <4218BC15.8060208@vanderpoel.org> <42191083.7040601@v.loewis.de> <421A792B.2050207@vanderpoel.org> <421AADF8.7050409@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 21 February, 2005 19:58 -0800 Erik van der Poel wrote: > I've been wondering whether my email was clear or not. The > kind of reference I'm talking about is the kind that started > this whole IDN spoofing discussion: > > > The above is from: > > http://secunia.com/multiple_browsers_idn_spoofing_test/ Clear enough, unfortunately. I'm still gagging. > As you can see, this HTML snippet is using a "numeric > character reference" (the а) instead of the Punycode > form of the name. Now, you may point out that HTML authors and > editors should use the Punycode form, but the above proves > that it is possible to type IDNs by hand. > > HTML has a long history of allowing users to type it manually, > and, regrettably, the browsers have an equally long history of > *accepting* practically anything that they type, whether it be > well-formed SGML or not. > > This is how we ended up with such a huge mass of garbage. The > Web browsers took the "be liberal in what you accept..." rule > a bit too literally. The browsers were too liberal. But I > digress. > > My point is that if it's possible to type IDNs manually into > HTML, then you might end up with some HTML documents that use > the very characters that you want to ban in the next rev of > nameprep. I am certainly not claiming that there will be very > many of those. All I'm asking is, how do we find out whether > they are going to be a problem? We don't. Even your Google plan (which I assume was at least partially tongue-in-cheek) would be pointless, as there is no way to run a check over the firewall and/or database-protected "dark web". We ultimately need to ask ourselves, and the implementer and, somehow, the user communities whether a more restrictive change is important enough. If it is, we pronounce the words "proposed standard" and "problems that showed up in implementation and deployment experience" and try to get it fixed as quickly as possible, recognizing that there will be links out there that need to be translated forward and back through IDNA2003 to get back links that would work with IDNA2005. If it isn't, we learn to cope. john From owner-idn@ops.ietf.org Tue Feb 22 01:44:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23118 for ; Tue, 22 Feb 2005 01:44:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Tg5-000OlQ-Ax for idn-data@psg.com; Tue, 22 Feb 2005 06:37:49 +0000 Received: from [80.67.18.15] (helo=smtprelay03.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Tfv-000Ok9-IA for idn@ops.ietf.org; Tue, 22 Feb 2005 06:37:39 +0000 Received: (qmail 17147 invoked from network); 22 Feb 2005 06:37:36 -0000 Received: from unknown (HELO [80.185.156.108]) (544451@[80.185.156.108]) (envelope-sender ) by smtprelay03.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Feb 2005 06:37:36 -0000 Message-ID: <421AD32F.6050305@v.loewis.de> Date: Tue, 22 Feb 2005 07:37:35 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <4217D4DA.4000908@vanderpoel.org> <20050220110817.GD14603~@nicemice.net> <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> <43983878a97b8668b5eaaaac89029891@seng.cc> <20050221111712.GE31308@nicemice.net> <20050221234401.GA20718~@nicemice.net> In-Reply-To: <20050221234401.GA20718~@nicemice.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: >>For example, someone could register a name that looks like >>"foo.bar.com", where the first dot was really U+0702. This attack >>would be equally effective no matter what larger structure (URI, email >>address, etc) the domain name appeared in. I may be missing something, but I think this cannot be registered: >>> u"foo\u0702bar.com".encode("idna") Traceback (most recent call last): File "", line 1, in ? File "/usr/local/lib/python2.5/encodings/idna.py", line 160, in encode result.append(ToASCII(label)) File "/usr/local/lib/python2.5/encodings/idna.py", line 75, in ToASCII label = nameprep(label) File "/usr/local/lib/python2.5/encodings/idna.py", line 50, in nameprep raise UnicodeError, "Violation of BIDI requirement 2" UnicodeError: Violation of BIDI requirement 2 So unless my IDNA implementation is incorrect, this label is banned. Clients should reject it, but if they fail to, atleast the registry should reject registration. > On second thought, the "." homograph attack is less severe than the "/" > homograph attack. The former only allows the attacker to spoof names > in the same domain that the attacker is registered in; I can't follow this reasoning, either: *if* foo.bar.com was possible, then I choose foo=www, bar=microsoft, and put an A record for the resulting label into DNS. The label would *not* be in the domain microsoft.com. Regards, Martin From owner-idn@ops.ietf.org Tue Feb 22 01:51:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24404 for ; Tue, 22 Feb 2005 01:51:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Tpn-0000nh-HZ for idn-data@psg.com; Tue, 22 Feb 2005 06:47:51 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Tpl-0000nU-LN for idn@ops.ietf.org; Tue, 22 Feb 2005 06:47:49 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3Tpl-00085Y-00 for ; Mon, 21 Feb 2005 22:47:49 -0800 Date: Tue, 22 Feb 2005 06:47:49 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] nameprep, IDN spoofing and the registries Message-ID: <20050222064748.GB20176~@nicemice.net> Reply-To: IETF idn working group References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421AC08F.2030207@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > I'm not sure whether we would need a new ACE prefix if we are only > adding characters (and not removing any). Nameprep was designed so that if Unicode evolves in a backward compatible way (new characters added, old normalization mappings unchanged), then Nameprep can evolve along with it in a backward compatible way, with no need to change the ACE prefix. (Actually Unicode normalization did change in an incompatible way between 3.2 and 4.0 when five erroneous compatibility mappings were fixed, but the NormalizationCorrections.txt file allows applications to choose whether to keep the errors for backward compatibility. A new Nameprep would have to specify which choice to make.) AMC From owner-idn@ops.ietf.org Tue Feb 22 03:00:59 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22421 for ; Tue, 22 Feb 2005 03:00:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Ute-000Bdg-Qt for idn-data@psg.com; Tue, 22 Feb 2005 07:55:54 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Uta-000BdI-R5 for idn@ops.ietf.org; Tue, 22 Feb 2005 07:55:50 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3Uta-0008Pw-00 for ; Mon, 21 Feb 2005 23:55:50 -0800 Date: Tue, 22 Feb 2005 07:55:49 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] upstream and downstream Message-ID: <20050222075549.GC20176~@nicemice.net> Reply-To: IETF idn working group References: <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> <43983878a97b8668b5eaaaac89029891@seng.cc> <20050221111712.GE31308@nicemice.net> <20050221234401.GA20718~@nicemice.net> <421AD32F.6050305@v.loewis.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <421AD32F.6050305@v.loewis.de> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit "\"Martin v. Lwis\"" wrote: > > For example, someone could register a name that looks like > > "foo.bar.com", where the first dot was really U+0702. > > I may be missing something, but I think this cannot be registered: > > UnicodeError: Violation of BIDI requirement 2 Sure enough. I didn't realize U+0702 was right-to-left. That helps, but I wonder if there's another dot-lookalike lurking in Unicode. > > On second thought, the "." homograph attack is less severe than the > > "/" homograph attack. The former only allows the attacker to spoof > > names in the same domain that the attacker is registered in; > > I can't follow this reasoning, either: *if* foo.bar.com was possible, > then I choose foo=www, bar=microsoft, and put an A record for the > resulting label into DNS. The label would *not* be in the domain > microsoft.com. Let use ! to denote the fake dot. What I meant was that if the attackee registers microsoft in the .com domain, then the attacker must likewise register www!microsoft in the .com domain, and maybe someday the .com registry will stop allowing such things. Let's use % to denote the fake slash. With this attack, the attacker can register www.microsoft.com%foo in the bar.blah.deep.whatever domain, unhindered by any restrictions that might someday be put on the .com domain. AMC P.S. What's up with the literal quotes in your display-name? Is that my mail program acting funny, or yours? From owner-idn@ops.ietf.org Tue Feb 22 08:15:49 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27970 for ; Tue, 22 Feb 2005 08:15:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3Zkx-0007Ej-5u for idn-data@psg.com; Tue, 22 Feb 2005 13:07:15 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3Zkv-0007EC-1T for idn@ops.ietf.org; Tue, 22 Feb 2005 13:07:13 +0000 Received: (qmail 4383 invoked by uid 0); 22 Feb 2005 21:10:16 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.255426 secs); 22 Feb 2005 13:10:16 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 5.255426 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 22 Feb 2005 21:10:10 +0800 Message-ID: <421B2E59.20205@dready.org> Date: Wed, 23 Feb 2005 00:06:33 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik van der Poel CC: idn@ops.ietf.org, List Unicode , George W Gerrity Subject: [idn] Re: nameprep, IDN spoofing and the registries References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> In-Reply-To: <421AC08F.2030207@vanderpoel.org> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > As George points out, the registries are going to have to start > filtering IDN lookalikes, otherwise they will eventually face lawsuits > from the "big boys" (as George so delightfully puts it). Actually, I don't see that happening. It is generally accepted that neither gTLD registries or registrars check the names with human eyes before registering them. You can't sue if they've not been negligent. While I hope that gTLDs such as Verisign start filtering, I'm afraid we can't wait that long. That is why an application level solution is necessary. > The ccTLDs will have a relatively easy task, while the gTLDs like .com > will have the difficult task of deciding which subset of Unicode to > allow. Actually, most ccTLDs who are currently not offering a bundling solution specifically decided not to do bundling. They were fully aware that by not bundling, they are allowing the possibility of spoofing with the introduction of IDNs. And they have valid reasons for not doing so. This homograph attack advisory may well trigger some of them to change policies (though highly unlikely IMO), and hopefully get registries that are considering implementing IDN to employ some form of bundling solution, if applicable. > They will also have to go through their database, looking for > lookalikes, and deleting them or transferring them to new owners, > probably paying their previous owners back. If you're running a registry, you'd understand that deregistering or transferring a name against the registrant's will is no where as easy as it sounds. You might see lawsuits here. > One possible approach for the gTLDs is to halt IDN registration now. > Then they can work on their filters, starting with a small subset of > Unicode. After reopening IDN registration, they can grow the subset if > there is enough demand for characters outside the initial subset. > Sounds like a logical solution to me, that's the easiest way to stop spoofed names from being registered. Again, it may or may not happen depending on the registries in question. > If the gTLDs are going to do some serious subsetting, then they will > probably also need to provide software to the registrars that will map > users' characters into the subset. E.g. converting a user's local > charset to the subset of Unicode. Then again, this might be an area > where registrars could compete with each other, to provide the most > friendly software to the end-user (registrant). > It would really be nice if filtering is done earlier (i.e. at the registrar level instead of registry level) but that's not currently the case for Verisign's registrars, I suspect because it requires significantly more work for both the registry and registrars, not to mention that when the rules change, the registry needs to push the changes to the registrars. Right now, if you went to an ICANN accredited registrar and try to register an IDN, you'd need to input your unicode string, and select a language tag from a list, then click submit. The registrar does ToASCII(your_domain_name) and send the results along with the language tag to the registry after you have submitted your credit card details. Now, if the language tag you selected has a table attached, the registry will check the submitted domain against the table. At this point, if the test fails, an error will be returned to the registrar, then only do you get the message. And if you're lucky, at this point your credit card would be refunded. That might just be a particular registrar's implementation, but I did experience it. I don't know if Edmon's IDN-over-EPP is going to help with the situation, since I don't know what's going on in the SRS. wil. From owner-idn@ops.ietf.org Tue Feb 22 08:31:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29404 for ; Tue, 22 Feb 2005 08:31:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3a45-0009qU-Qa for idn-data@psg.com; Tue, 22 Feb 2005 13:27:01 +0000 Received: from [192.134.4.11] (helo=mx2.nic.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3a43-0009qA-Dj for idn@ops.ietf.org; Tue, 22 Feb 2005 13:26:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 535C026C076; Tue, 22 Feb 2005 14:26:58 +0100 (CET) Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by mx2.nic.fr (Postfix) with ESMTP id 31D9726C071; Tue, 22 Feb 2005 14:26:57 +0100 (CET) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id j1MDQvT3823364; Tue, 22 Feb 2005 14:26:57 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id EC04016A980; Tue, 22 Feb 2005 14:26:56 +0100 (CET) Date: Tue, 22 Feb 2005 14:26:56 +0100 From: Stephane Bortzmeyer To: Erik van der Poel Cc: idn@ops.ietf.org Subject: [idn] Re: nameprep, IDN spoofing and the registries Message-ID: <20050222132656.GA13173@nic.fr> References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421AC08F.2030207@vanderpoel.org> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On Mon, Feb 21, 2005 at 09:18:07PM -0800, Erik van der Poel wrote a message of 218 lines which said: > As George points out, the registries are going to have to start > filtering IDN lookalikes, otherwise they will eventually face > lawsuits from the "big boys" (as George so delightfully puts it). Quite the opposite: according to our lawyer, if the process is completely automatic (no human eyes involved), you can disclaim any responsability. But if you do screen, you accept a liability if the screening fails (and it will fail, trying to catch homographs is an hopeless task). I seriously doubt that european registries, which all moved from a "screen every domain to check if it is legal" model to a "accept anything" model in the '90s will go back... From owner-idn@ops.ietf.org Tue Feb 22 12:48:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27801 for ; Tue, 22 Feb 2005 12:48:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3e2a-000MyO-F0 for idn-data@psg.com; Tue, 22 Feb 2005 17:41:44 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3e2Z-000MyA-6K for idn@ops.ietf.org; Tue, 22 Feb 2005 17:41:43 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1MHfbHb091400; Tue, 22 Feb 2005 12:41:38 -0500 Message-ID: <421B6ED1.6060500@vanderpoel.org> Date: Tue, 22 Feb 2005 09:41:37 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org, unicode@unicode.org Subject: Re: [idn] Re: nameprep, IDN spoofing and the registries References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> <20050222132656.GA13173@nic.fr> In-Reply-To: <20050222132656.GA13173@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >>As George points out, the registries are going to have to start >>filtering IDN lookalikes, otherwise they will eventually face >>lawsuits from the "big boys" (as George so delightfully puts it). > > Quite the opposite: according to our lawyer, if the process is > completely automatic (no human eyes involved), you can disclaim any > responsability. But if you do screen, you accept a liability if the > screening fails (and it will fail, trying to catch homographs is an > hopeless task). > > I seriously doubt that european registries, which all moved from a > "screen every domain to check if it is legal" model to a "accept > anything" model in the '90s will go back... Chuckle. That's funny. Here I am telling a mathematician to think more like a network engineer, then I turn around and say something about law even though I'm not a lawyer! Seriously, I did not say that human eyes would do the filtering (though of course humans would have to come up with the policies and code to do the filtering). So, if a registry can claim that it can disclaim responsibility for spoofing *because* it is using an automatic registration process, then wouldn't it be possible for someone (or a class action) to claim that their automatic process isn't good enough? I mean, we all know where the obvious homographs are, and any engineer can tell you that it is easy to write a program to generate all the spoofs from those, or to filter them. This may be a gray area that I believe Peter may have been referring to when he said that in some countries it might be possible to force the registry to change. As it turns out, mozilla.org has also discussed the idea that Mozilla may not want to try to solve the IDN spoofing problem, since it cannot accept the legal responsibility for doing so. Is the Unicode Consortium now also going to say "Sorry, we cannot provide homograph tables because we cannot be held responsible for any spoofing that may occur."? Is everyone just going to pass the buck? How sad. By the way, not all European registries "accept anything". Some of them are checking a character inclusion table to see if the domain name is allowed. What do you say to this? Erik From owner-idn@ops.ietf.org Tue Feb 22 14:18:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06231 for ; Tue, 22 Feb 2005 14:18:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3fU7-000BjC-Oh for idn-data@psg.com; Tue, 22 Feb 2005 19:14:15 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3fU6-000Biz-RH for idn@ops.ietf.org; Tue, 22 Feb 2005 19:14:15 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1MJECHb179866; Tue, 22 Feb 2005 14:14:13 -0500 Message-ID: <421B8484.3070802@vanderpoel.org> Date: Tue, 22 Feb 2005 11:14:12 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] nameprep2 and the slash homograph issue Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, In a way, it was pretty sensible for the IETF to decide to avoid subsetting Unicode too much so that national registries could make those decisions on their own. After all, those countries know more about their own characters than the IETF does, and it seems more fair to let them make such a decision. One could see this as an instance of "Push the problem downstream, so that we cannot be blamed for being overly restrictive up here". Now I'm wondering if we could make a similar argument in the slash homograph case. If nameprep2 bans the slash homograph, then there is no way for any community to use it in a domain name, even if that domain name appears in a context where slash means nothing. Consider the email case. There are no slashes in the vicinity of a domain name in an email app. The URI case is, of course, different. Here you often see slashes, so a slash homograph could easily spoof someone. So, could nameprep2's position be, "Push the slash homograph problem downstream, to the app, so that we cannot be blamed for being overly restrictive up here"? Or is the slash fundamentally different from national characters? And if so, who are we to make that statement? Shouldn't the countries be deciding that? (Not that TLDs can restrict names in 3LDs and up, only the apps can address those.) Another argument against banning the slash homograph is that any new banning would require a new ACE prefix, which is a lot of work, and, as John said, there should be a high threshold for any demonstration that tries to show that a new prefix is necessary. Instead of banning the slash homograph, nameprep2 could simply warn implementors of the spoofing problem, giving some vague advice (without overly restricting the apps). Erik From owner-idn@ops.ietf.org Tue Feb 22 14:18:50 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06269 for ; Tue, 22 Feb 2005 14:18:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3fVP-000BvA-0K for idn-data@psg.com; Tue, 22 Feb 2005 19:15:35 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3fVM-000Buw-ND for idn@ops.ietf.org; Tue, 22 Feb 2005 19:15:32 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D3fVJ-00068b-SR; Tue, 22 Feb 2005 11:15:30 -0800 Message-Id: <6.1.2.0.2.20050222163109.02e51db0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Feb 2005 16:58:37 +0100 To: Stephane Bortzmeyer , Erik van der Poel From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: nameprep, IDN spoofing and the registries Cc: idn@ops.ietf.org In-Reply-To: <20050222132656.GA13173@nic.fr> References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> <20050222132656.GA13173@nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 14:26 22/02/2005, Stephane Bortzmeyer wrote: >On Mon, Feb 21, 2005 at 09:18:07PM -0800, > Erik van der Poel wrote > a message of 218 lines which said: > > > As George points out, the registries are going to have to start > > filtering IDN lookalikes, otherwise they will eventually face > > lawsuits from the "big boys" (as George so delightfully puts it). > >Quite the opposite: according to our lawyer, if the process is >completely automatic (no human eyes involved), you can disclaim any >responsability. But if you do screen, you accept a liability if the >screening fails (and it will fail, trying to catch homographs is an >hopeless task). > >I seriously doubt that european registries, which all moved from a >"screen every domain to check if it is legal" model to a "accept >anything" model in the '90s will go back... Full agreement. Now, only for the reasons explained below, I am ready to test and propose several ccTLDs a filtering experimentation. 1. I filter the registered names (against foul names, blocked names) at registration level, before accepting payment. 2. the filtering will therefore be on xn--entries strings. This being accepted: 1. could someone point a "C" source code to carry what has to be carried to filter out the dangerous names? Please help: I have no resource on this. 2. could someone list all the Unicode codes to blacklist that way? 3. could someone point a Perl code to use to enter a IDN and to get it properly punycoded, which could use such a list. My rationale is that I only want to protect my own operations from confusion. I will only extend the description of the non-authorized characters in the terms and conditions. If this works properly I will describe the solution and experience in a for information Draft and a request to the IANA to list a Unicode black list. jfc jfc From owner-idn@ops.ietf.org Tue Feb 22 15:12:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13337 for ; Tue, 22 Feb 2005 15:12:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3gJL-000JST-C7 for idn-data@psg.com; Tue, 22 Feb 2005 20:07:11 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3gJK-000JSC-6X for idn@ops.ietf.org; Tue, 22 Feb 2005 20:07:10 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1MK74uq196556; Tue, 22 Feb 2005 15:07:05 -0500 Message-ID: <421B90E8.5060609@vanderpoel.org> Date: Tue, 22 Feb 2005 12:07:04 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> In-Reply-To: <421B8484.3070802@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Or is the slash fundamentally different from national characters? I guess you could make the case that U+2215 is different from national characters, because it is a mathematical operator. Similarly, U+2044 is a general punctuation character. Are either of these already banned by nameprep? There is another character U+30CE that looks like a slash. Perhaps we would warn about characters like this in nameprep2? I still wonder whether U+2215 and U+2044 are sufficiently problematic to require a new ACE prefix. Erik From owner-idn@ops.ietf.org Tue Feb 22 17:07:39 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28325 for ; Tue, 22 Feb 2005 17:07:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3i47-000BgJ-N1 for idn-data@psg.com; Tue, 22 Feb 2005 21:59:35 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3i45-000Bfs-Hc for idn@ops.ietf.org; Tue, 22 Feb 2005 21:59:33 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D3i42-0001SI-U1; Tue, 22 Feb 2005 13:59:31 -0800 Message-Id: <6.1.2.0.2.20050222221611.03e44d70@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 22 Feb 2005 22:59:22 +0100 To: Erik van der Poel From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: nameprep, IDN spoofing and the registries Cc: Stephane Bortzmeyer , idn@ops.ietf.org In-Reply-To: <421B966F.1020803@vanderpoel.org> References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> <20050222132656.GA13173@nic.fr> <6.1.2.0.2.20050222163109.02e51db0@mail.jefsey.com> <421B966F.1020803@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 21:30 22/02/2005, Erik van der Poel wrote: >JFC (Jefsey) Morfin wrote: >>2. could someone list all the Unicode codes to blacklist that way? > >It will take a while to create a relatively complete table of homographs, >but here are a couple of starting points: > >https://bugzilla.mozilla.org/attachment.cgi?id=174139 >https://bugzilla.mozilla.org/show_bug.cgi?id=279099#c192 > >Also, I've been thinking of writing a program that would look at the >"cmap" of every font on a Windows box and check to see which pairs of >Unicodes have the same glyph index (which leads to identical display). This would help. But a ccTLD managing IDNs in computer environment and wanting to avoid any mistake, manages names in most of the case under the ACE format. In ASCII. I am not sure about existing dispute cases, but we consider that two IDNs are different if they have different in ACE format? Anyway, I answer you below. >>3. could someone point a Perl code to use to enter a IDN and to get it >>properly punycoded, which could use such a list. > >I don't know about Perl, but I believe Python has IDN. Thank you, but as I said, I have no resource on this. So what would be great wold be that this list would actually help preparing a Draft - may be someone of more technical skill and competence would be interested in leading it? So we can start working on something real. I listed my pratical needs. I suppose others would have others to add. Stephane is key person in supporting many ccTLDs in real life. I am sure he will be of great help. So would Gervase's with the ability to test in Firefox environment. I have reported the problem and my request on the ccTLD list. I asked about the additional requirements they might have. I will inform this list of any additional demands they may have IRT a practical solution for them. I also documented that my concern was not about the phishing issue but about the ccTLD owns operations. This leaves the legal aside and may be more motivating since their own Registry could be the first victim of a confusion (in Whois display, for example). jfc From owner-idn@ops.ietf.org Tue Feb 22 18:34:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08886 for ; Tue, 22 Feb 2005 18:34:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3jRm-000Myo-Dm for idn-data@psg.com; Tue, 22 Feb 2005 23:28:06 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3jRi-000MyX-NS for idn@ops.ietf.org; Tue, 22 Feb 2005 23:28:03 +0000 Received: (qmail 75938 invoked by uid 0); 23 Feb 2005 07:31:07 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.854892 secs); 22 Feb 2005 23:31:07 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.854892 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 23 Feb 2005 07:31:06 +0800 Message-ID: <421BBFF5.6090902@dready.org> Date: Wed, 23 Feb 2005 10:27:49 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: Stephane Bortzmeyer , Erik van der Poel , idn@ops.ietf.org Subject: Re: [idn] Re: nameprep, IDN spoofing and the registries References: <421A3E9C.5020204@vanderpoel.org> <421AC08F.2030207@vanderpoel.org> <20050222132656.GA13173@nic.fr> <6.1.2.0.2.20050222163109.02e51db0@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050222163109.02e51db0@mail.jefsey.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jefsey, Which ccTLDs do you intend to propose this experiment? If you don't mind revealing... Have these ccTLDs rolled out IDN implementation? If so, do they currently employ a character table of sorts?\ > 1. could someone point a "C" source code to carry what has to be > carried to filter out the dangerous names? Please help: I have no > resource on this. I'm not sure what exactly you need. If you have the tables it should be fairly trivial to write some functions in C to filter names. Make sure your inputs are properly normalized and just compare the to-be-registered name against your blacklist, reject the name on any match. > 2. could someone list all the Unicode codes to blacklist that way? If character tables are used, they effectively serve as a whitelist. If you wish to disallow any character from being registered, just make sure that it's not on the whitelist. > 3. could someone point a Perl code to use to enter a IDN and to get it > properly punycoded, which could use such a list. > Try Net::LibIDN (http://spaceship.berlios.de/index.php?page=idn.php) which is a Perl binding for GNU Libidn. It seems to have some support for character inclusion list, not sure about blacklists though. Regards, wil. From owner-idn@ops.ietf.org Tue Feb 22 19:48:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16923 for ; Tue, 22 Feb 2005 19:48:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3kcp-0008gX-Tt for idn-data@psg.com; Wed, 23 Feb 2005 00:43:35 +0000 Received: from [80.67.18.16] (helo=smtprelay04.ispgateway.de) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3kcm-0008fm-Fd for idn@ops.ietf.org; Wed, 23 Feb 2005 00:43:32 +0000 Received: (qmail 1969 invoked from network); 23 Feb 2005 00:43:30 -0000 Received: from unknown (HELO [80.185.144.174]) (544451@[80.185.144.174]) (envelope-sender ) by smtprelay04.ispgateway.de (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Feb 2005 00:43:30 -0000 Message-ID: <421BD1B0.6060809@v.loewis.de> Date: Wed, 23 Feb 2005 01:43:28 +0100 From: =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= User-Agent: Debian Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] upstream and downstream References: <4218A1D0.2040703@vanderpoel.org> <20050220234256.GB31308~@nicemice.net> <4219249A.9060306@mozilla.org> <20050221045311.GC31308~@nicemice.net> <61b9d024408c83dce474862ae51abf0c@pobox.org.sg> <20050221081741.GD31308~@nicemice.net> <43983878a97b8668b5eaaaac89029891@seng.cc> <20050221111712.GE31308@nicemice.net> <20050221234401.GA20718~@nicemice.net> <421AD32F.6050305@v.loewis.de> <20050222075549.GC20176~@nicemice.net> In-Reply-To: <20050222075549.GC20176~@nicemice.net> X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Adam M. Costello wrote: > P.S. What's up with the literal quotes in your display-name? Is that my > mail program acting funny, or yours? My mail program puts =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= into From; this decodes to "Martin v. Lwis" So two of the quotes are mine (from thunderbird) - the other two must, and the backslashes, must be yours. Regards, Martin From owner-idn@ops.ietf.org Wed Feb 23 02:45:26 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03342 for ; Wed, 23 Feb 2005 02:45:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3qws-000Ka0-Tl for idn-data@psg.com; Wed, 23 Feb 2005 07:28:42 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3qwq-000KZj-V8 for idn@ops.ietf.org; Wed, 23 Feb 2005 07:28:41 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3qwn-0005fV-00 for ; Tue, 22 Feb 2005 23:28:37 -0800 Date: Wed, 23 Feb 2005 07:28:37 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] nameprep2 and the slash homograph issue Message-ID: <20050223072837.GA21463~@nicemice.net> Reply-To: IETF idn working group References: <421B8484.3070802@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421B8484.3070802@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > Another argument against banning the slash homograph is that any new > banning would require a new ACE prefix, which is a lot of work, and, > as John said, there should be a high threshold for any demonstration > that tries to show that a new prefix is necessary. An alternative, rather than banning the character, is to recommend that it not be shown; the ACE form could be shown instead. This would effectively make the character useless in domain names (for both phishers and honest folks) without requiring a new ACE prefix. We could push ToUnicode down inside a wrapper function, ToDisplay. Applications would never call ToUnicode directly anymore. Whenever they wanted to display a domain name, they'd call ToDisplay, which would call ToUnicode, check the result, and if it didn't like it, call ToASCII. (Of course, since ToUnicode typically calls ToASCII, there are opportunities to optimize that logic.) AMC From owner-idn@ops.ietf.org Wed Feb 23 03:37:21 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11757 for ; Wed, 23 Feb 2005 03:37:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3rty-00076y-AO for idn-data@psg.com; Wed, 23 Feb 2005 08:29:46 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3rtw-00076k-Hu for idn@ops.ietf.org; Wed, 23 Feb 2005 08:29:44 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1N8TgJR014030 for ; Wed, 23 Feb 2005 17:29:42 +0900 Message-ID: <421C3EF3.4020005@lsb.org> Date: Wed, 23 Feb 2005 17:29:39 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] another BIDI/ASCII representation problem on w3.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Even stringprep-validated name label maybe cause problems when being prefixed by digits-only label or digits-only mailbox names. If we should redesign stringprep/nameprep we should take the following BIDI issue together. Please see this article from W3.org: http://lists.w3.org/Archives/Public/public-iri/2003Sep/0000.html Soobok Lee From owner-idn@ops.ietf.org Wed Feb 23 03:47:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13492 for ; Wed, 23 Feb 2005 03:47:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3s3u-000853-I5 for idn-data@psg.com; Wed, 23 Feb 2005 08:40:02 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3s3r-000841-7S for idn@ops.ietf.org; Wed, 23 Feb 2005 08:39:59 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D3s3q-0009Ac-RK for idn@ops.ietf.org; Wed, 23 Feb 2005 03:39:58 -0500 Date: Wed, 23 Feb 2005 03:39:58 -0500 From: John C Klensin To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue Message-ID: In-Reply-To: <20050223072837.GA21463~@nicemice.net> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MAILTO_TO_REMOVE autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Wednesday, 23 February, 2005 07:28 +0000 "Adam M. Costello" wrote: > Erik van der Poel wrote: > >> Another argument against banning the slash homograph is that >> any new banning would require a new ACE prefix, which is a >> lot of work, and, as John said, there should be a high >> threshold for any demonstration that tries to show that a new >> prefix is necessary. > > An alternative, rather than banning the character, is to > recommend that it not be shown; the ACE form could be shown > instead. This would effectively make the character useless in > domain names (for both phishers and honest folks) without > requiring a new ACE prefix. > > We could push ToUnicode down inside a wrapper function, > ToDisplay. Applications would never call ToUnicode directly > anymore. Whenever they wanted to display a domain name, > they'd call ToDisplay, which would call ToUnicode, check the > result, and if it didn't like it, call ToASCII. (Of course, > since ToUnicode typically calls ToASCII, there are > opportunities to optimize that logic.) Adam, there are two problems with this. First, it effectively dictates UI behavior, which is generally a bad idea. It is a particularly bad idea in this case because you are proposing the sort of UI behavior that generates a lot of very confused questions and trouble reports, which is something no sane implementer wants. And "won't display" is not the right answer on the registration side of the process, even if it were right on the lookup side. The second problem is that it is a kludge, and that inserting kludges into critical protocols or procedures --and IDNs are certainly critical-- almost always turns out to be a seriously bad idea sooner or later. If we find a need to start banning characters that we could not agree on banning the first time around, there is another approach, also unpleasant but IMO less problematic, that could be considered. Just as RFC 2822 moved past a lot of legacy nonsense by having two separate "create" and "accept" syntaxes, we could define an additional profile, say "NameRegisterPrep". It would look a lot like Nameprep but would ban the characters you are now suggesting banning, plus, based on what I think is growing experience in the registries, ban any character that mapped to anything else. The effect would be to permit only those code points as input to the registration process that could be output into punycode and the DNS. Several registries have adopted the latter part of that model already: basically what you register is ToASCII(string) and/or ToUnicode(ToASCII(string)), but never "string". The lookup process would remain the same, with no changes to Nameprep being made at all. And, by eliminating all of the mapping tables and replacing them with prohibitions, it would make the question "can this character appear in an IDN" a great deal less complicated, which would certainly be an advantage. This type of registration restriction is rather different from our asking/expecting ICANN and the registries to adopt rules about, e.g., mixed-script registrations that would help people stay out of trouble. For better or worse, ICANN has a great deal less trouble asking (or demanding) that people conform to the protocols than it does with making up a somewhat fuzzy guideline and enforcing it. In the most extreme of cases, violating a protocol in a significant way is one of those "not acting in the best interests of the local users and the Internet community" that RFC 1591 warns against and indicates could be grounds for redelegating a registry. It would leave the registries and ICANN stuck with the problem of what to do about anything that was now registered which violated the new rules, but that problem would exist for _any_ substantive change we made. john From owner-idn@ops.ietf.org Wed Feb 23 04:06:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17278 for ; Wed, 23 Feb 2005 04:06:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3sQI-000B6d-Fu for idn-data@psg.com; Wed, 23 Feb 2005 09:03:10 +0000 Received: from [211.196.150.53] (helo=postel5.postel.co.kr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3sQH-000B6I-HG for idn@ops.ietf.org; Wed, 23 Feb 2005 09:03:09 +0000 Received: from [10.1.1.21] ([211.217.233.223]) by postel5.postel.co.kr (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id j1N936JR020358; Wed, 23 Feb 2005 18:03:07 +0900 Message-ID: <421C46C7.8080506@lsb.org> Date: Wed, 23 Feb 2005 18:03:03 +0900 From: Soobok Lee User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soobok Lee CC: idn@ops.ietf.org Subject: Re: [idn] another BIDI/ASCII representation problem on w3.org References: <421C3EF3.4020005@lsb.org> In-Reply-To: <421C3EF3.4020005@lsb.org> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_PROXY autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Soobok Lee wrote: > > Even stringprep-validated name label maybe cause problems when being > prefixed by name lable ==> BIDI name lable. this label may be arabic or hebrew one. > > digits-only label or digits-only mailbox names. If we should redesign > stringprep/nameprep > we should take the following BIDI issue together. > > Please see this article from W3.org: > > http://lists.w3.org/Archives/Public/public-iri/2003Sep/0000.html > > Soobok Lee From owner-idn@ops.ietf.org Wed Feb 23 05:57:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02346 for ; Wed, 23 Feb 2005 05:57:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3u8O-000Ooh-CG for idn-data@psg.com; Wed, 23 Feb 2005 10:52:48 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3u8L-000OoL-Eg for idn@ops.ietf.org; Wed, 23 Feb 2005 10:52:45 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D3u8K-0006Qs-00 for ; Wed, 23 Feb 2005 02:52:44 -0800 Date: Wed, 23 Feb 2005 10:52:44 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue Message-ID: <20050223105244.GE21463~@nicemice.net> Reply-To: IETF idn working group References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk John C Klensin wrote: > If we find a need to start banning characters that we could not agree > on banning the first time around, there is another approach, also > unpleasant but IMO less problematic, that could be considered. Just > as RFC 2822 moved past a lot of legacy nonsense by having two separate > "create" and "accept" syntaxes, we could define an additional profile, > say "NameRegisterPrep". It would look a lot like Nameprep but would > ban the characters you are now suggesting banning, plus, based on what > I think is growing experience in the registries, ban any character > that mapped to anything else. > > The lookup process would remain the same, with no changes to Nameprep > being made at all. But browser implementers want to protect their users today against malicious names that may exist in the DNS today. I don't see how this proposal would help them do that. Browser implementors are comtemplating banning characters in IDNs the browser (that is, failing to look up names containing blacklisted characters), and I was trying to think of a less drastic, less blatantly nonconformant, but equally protective measure that could be taken in the browser. AMC From owner-idn@ops.ietf.org Wed Feb 23 10:35:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28930 for ; Wed, 23 Feb 2005 10:35:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3yR9-0007SW-Vb for idn-data@psg.com; Wed, 23 Feb 2005 15:28:27 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3yR8-0007SI-RC for idn@ops.ietf.org; Wed, 23 Feb 2005 15:28:27 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NFSLHb155098; Wed, 23 Feb 2005 10:28:21 -0500 Message-ID: <421CA114.9090302@vanderpoel.org> Date: Wed, 23 Feb 2005 07:28:20 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> In-Reply-To: <20050223105244.GE21463~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam, The IETF generally only specifies the "wire" protocol, not UI behavior. The IETF does not specify how apps interface with users; it only specifies how apps interface with other apps, over the wire. Note that this does not even include APIs in many cases. However, it *would* be very wise to *warn* implementors about any dangerous homographs in the new RFC (if we decide not to ban them outright). Erik Adam M. Costello wrote: > But browser implementers want to protect their users today against > malicious names that may exist in the DNS today. I don't see how > this proposal would help them do that. Browser implementors are > comtemplating banning characters in IDNs the browser (that is, failing > to look up names containing blacklisted characters), and I was trying > to think of a less drastic, less blatantly nonconformant, but equally > protective measure that could be taken in the browser. From owner-idn@ops.ietf.org Wed Feb 23 12:11:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12892 for ; Wed, 23 Feb 2005 12:11:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D3zyB-000M6C-EX for idn-data@psg.com; Wed, 23 Feb 2005 17:06:39 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D3zy7-000M5T-Bk for idn@ops.ietf.org; Wed, 23 Feb 2005 17:06:35 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NH6TSJ207970; Wed, 23 Feb 2005 12:06:29 -0500 Message-ID: <421CB812.3050400@vanderpoel.org> Date: Wed, 23 Feb 2005 09:06:26 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> In-Reply-To: <421CA114.9090302@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > However, it *would* be very wise to *warn* implementors about any > dangerous homographs in the new RFC (if we decide not to ban them > outright). Yesterday, I started a new Web site to collect nameprep issues, and now I'm thinking that it might also be a good place to collect info about dangerous homographs. Implementors could look here for guidance. I stress that this site is unofficial. I am merely offering a place for us to collect info and present it to others. The mailing list archive is a daunting and unorganized place to look for such info. Please send any additions, comments, etc to me or to the mailing list. I promise to be open about it, but if that turns out to be a problem, maybe I or someone can start a Wiki instead. http://nameprep.org/ Erik From owner-idn@ops.ietf.org Wed Feb 23 12:14:15 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13470 for ; Wed, 23 Feb 2005 12:14:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D401x-000Mi5-MS for idn-data@psg.com; Wed, 23 Feb 2005 17:10:33 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D401v-000MhV-7r for idn@ops.ietf.org; Wed, 23 Feb 2005 17:10:31 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D401t-0003Jf-D4; Wed, 23 Feb 2005 09:10:30 -0800 Message-Id: <6.1.2.0.2.20050223175234.0355d270@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 23 Feb 2005 18:02:26 +0100 To: John C Klensin , IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] nameprep2 and the slash homograph issue In-Reply-To: References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, MAILTO_TO_REMOVE autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk John, your proposition makes more sense than Adam as kludges do not escalate, and when you start censoring you never know where you will have to stop, and I do not know how you can enforce it. But your proposition is not the panacea. 1) it is meant only for registration. So it is for TLD Registry Managers or goodwill registrants (for 3+LD). They are ignorant, lazzy, opposed or accepting, but they do not oppose. So the real problem is not with them but with phishers. 2) your poposition is to have an oline correction of the problem. Some Registry may like it, some not. I would have strong objections because it complexifies the user support. But we can try it. This is why I asked the solution I asked and asked if a Perl program existed to test a correction at registration. Actually I repeat that all the propositions to change what the user can see is user hurting. The need for the click to send a request which the one the user want, not the one the phisher want. IMHO one does not increase security in hiding the existand of the danger, one increases the risks. jfc At 09:39 23/02/2005, John C Klensin wrote: >--On Wednesday, 23 February, 2005 07:28 +0000 "Adam M. Costello" > wrote: > > > Erik van der Poel wrote: > > > >> Another argument against banning the slash homograph is that > >> any new banning would require a new ACE prefix, which is a > >> lot of work, and, as John said, there should be a high > >> threshold for any demonstration that tries to show that a new > >> prefix is necessary. > > > > An alternative, rather than banning the character, is to > > recommend that it not be shown; the ACE form could be shown > > instead. This would effectively make the character useless in > > domain names (for both phishers and honest folks) without > > requiring a new ACE prefix. > > > > We could push ToUnicode down inside a wrapper function, > > ToDisplay. Applications would never call ToUnicode directly > > anymore. Whenever they wanted to display a domain name, > > they'd call ToDisplay, which would call ToUnicode, check the > > result, and if it didn't like it, call ToASCII. (Of course, > > since ToUnicode typically calls ToASCII, there are > > opportunities to optimize that logic.) > >Adam, there are two problems with this. First, it effectively >dictates UI behavior, which is generally a bad idea. It is a >particularly bad idea in this case because you are proposing the >sort of UI behavior that generates a lot of very confused >questions and trouble reports, which is something no sane >implementer wants. And "won't display" is not the right answer >on the registration side of the process, even if it were right >on the lookup side. The second problem is that it is a kludge, >and that inserting kludges into critical protocols or procedures >--and IDNs are certainly critical-- almost always turns out to >be a seriously bad idea sooner or later. > >If we find a need to start banning characters that we could not >agree on banning the first time around, there is another >approach, also unpleasant but IMO less problematic, that could >be considered. Just as RFC 2822 moved past a lot of legacy >nonsense by having two separate "create" and "accept" syntaxes, >we could define an additional profile, say "NameRegisterPrep". >It would look a lot like Nameprep but would ban the characters >you are now suggesting banning, plus, based on what I think is >growing experience in the registries, ban any character that >mapped to anything else. The effect would be to permit only >those code points as input to the registration process that >could be output into punycode and the DNS. Several registries >have adopted the latter part of that model already: basically >what you register is ToASCII(string) and/or >ToUnicode(ToASCII(string)), but never "string". The lookup >process would remain the same, with no changes to Nameprep being >made at all. And, by eliminating all of the mapping tables and >replacing them with prohibitions, it would make the question >"can this character appear in an IDN" a great deal less >complicated, which would certainly be an advantage. > >This type of registration restriction is rather different from >our asking/expecting ICANN and the registries to adopt rules >about, e.g., mixed-script registrations that would help people >stay out of trouble. For better or worse, ICANN has a great >deal less trouble asking (or demanding) that people conform to >the protocols than it does with making up a somewhat fuzzy >guideline and enforcing it. In the most extreme of cases, >violating a protocol in a significant way is one of those "not >acting in the best interests of the local users and the Internet >community" that RFC 1591 warns against and indicates could be >grounds for redelegating a registry. > >It would leave the registries and ICANN stuck with the problem >of what to do about anything that was now registered which >violated the new rules, but that problem would exist for _any_ >substantive change we made. > > john From owner-idn@ops.ietf.org Wed Feb 23 12:14:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13523 for ; Wed, 23 Feb 2005 12:14:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4025-000Mir-SI for idn-data@psg.com; Wed, 23 Feb 2005 17:10:41 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D401w-000Mhu-Tz for idn@ops.ietf.org; Wed, 23 Feb 2005 17:10:33 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D401v-0003Jf-6Y; Wed, 23 Feb 2005 09:10:31 -0800 Message-Id: <6.1.2.0.2.20050223180502.031d5730@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 23 Feb 2005 18:06:33 +0100 To: Erik van der Poel , IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] nameprep2 and the slash homograph issue In-Reply-To: <421CA114.9090302@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 16:28 23/02/2005, Erik van der Poel wrote: >Adam, >The IETF generally only specifies the "wire" protocol, not UI behavior. >The IETF does not specify how apps interface with users; it only specifies >how apps interface with other apps, over the wire. Note that this does not >even include APIs in many cases. > >However, it *would* be very wise to *warn* implementors about any >dangerous homographs in the new RFC (if we decide not to ban them outright). Yes. But this does not prevent to warn in proposing solutions to the system conceptual problems, like for tables. The same for TLD Managers. jfc From owner-idn@ops.ietf.org Wed Feb 23 12:57:22 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19602 for ; Wed, 23 Feb 2005 12:57:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D40hI-00024I-Iv for idn-data@psg.com; Wed, 23 Feb 2005 17:53:16 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D40h6-00021Y-3S for idn@ops.ietf.org; Wed, 23 Feb 2005 17:53:04 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NHqaSJ188854; Wed, 23 Feb 2005 12:52:45 -0500 Message-ID: <421CC2E4.5000908@vanderpoel.org> Date: Wed, 23 Feb 2005 09:52:36 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> <6.1.2.0.2.20050223180502.031d5730@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050223180502.031d5730@mail.jefsey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > At 16:28 23/02/2005, Erik van der Poel wrote: >> However, it *would* be very wise to *warn* implementors about any >> dangerous homographs in the new RFC (if we decide not to ban them >> outright). > > Yes. But this does not prevent to warn in proposing solutions to the > system conceptual problems, like for tables. The same for TLD Managers. I agree. Specs often have normative and informative sections, appendices, etc. We could easily insert some *advice* in an informative part. Erik From owner-idn@ops.ietf.org Wed Feb 23 13:24:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23718 for ; Wed, 23 Feb 2005 13:24:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D418C-00067Z-Lq for idn-data@psg.com; Wed, 23 Feb 2005 18:21:04 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D418B-00067J-Lo for idn@ops.ietf.org; Wed, 23 Feb 2005 18:21:03 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NIKquq322402; Wed, 23 Feb 2005 13:20:56 -0500 Message-ID: <421CC983.1030507@vanderpoel.org> Date: Wed, 23 Feb 2005 10:20:51 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <6.1.2.0.2.20050223175234.0355d270@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050223175234.0355d270@mail.jefsey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > Actually I repeat that all the propositions to change what the user can > see is user hurting. The need for the click to send a request which the > one the user want, not the one the phisher want. IMHO one does not > increase security in hiding the existand of the danger, one increases > the risks. Jefsey, it must be difficult to participate in this kind of group when English is not your main language, but I, for one, do appreciate your wise contributions, so I take them seriously. However, I must disagree with this particular suggestion (if I understand you correctly). If a phisher spams users, it is not the email app's responsibility to direct the user to whatever site the app might guess is the "correct" one. No, I think it's better for the app to warn the user in some way that this is a phishy email, and might be evil. This is similar to the advice that you should not give your Social Security Number (SSN) or credit card number to someone over the phone, unless *you* are the one dialing the phone number (using a well-known, published phone number). Erik From owner-idn@ops.ietf.org Wed Feb 23 13:38:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25819 for ; Wed, 23 Feb 2005 13:38:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D41MM-0008AW-P1 for idn-data@psg.com; Wed, 23 Feb 2005 18:35:42 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D41ML-0008A9-T7 for idn@ops.ietf.org; Wed, 23 Feb 2005 18:35:41 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 10:35:41 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 23 Feb 2005 10:35:40 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 10:35:41 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Wed, 23 Feb 2005 10:35:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] another BIDI/ASCII representation problem on w3.org Date: Wed, 23 Feb 2005 10:35:40 -0800 Message-ID: Thread-Topic: [idn] another BIDI/ASCII representation problem on w3.org thread-index: AcUZhvaAGUcNFuCATpOW4wIZFkm9WwATifVQ From: "Michel Suignard" To: "Soobok Lee" Cc: X-OriginalArrivalTime: 23 Feb 2005 18:35:38.0317 (UTC) FILETIME=[785FD7D0:01C519D6] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable That comment from the public-iri list has been disposed a long time ago = by the authors of the now RFC 3987 (IRI). BIDI introduces its own set of security issues on IDN and IRI but these = issues are not homograph related. Furthermore, the recommendation concerning mix of rtl and ltr characters = in IRI (such mix may make the host name in a IRI visually undetectable = because of the mix with with path and query parts) is only a 'should' in = RFC speak, because an IRI (as well as URI) may be opaque (i.e, never = visually displayed). However it is pretty clear that it is expected that = a user agent displaying an IRI containing bidi content would enforce the = IRI bidi restrictions. In all cases the IDN bidi restrictions apply. Please refere to the IRI RFC for more details. Michel -----Original Message----- From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf = Of Soobok Lee Sent: Wednesday, February 23, 2005 1:03 AM To: Soobok Lee Cc: idn@ops.ietf.org Subject: Re: [idn] another BIDI/ASCII representation problem on w3.org Soobok Lee wrote: > > Even stringprep-validated name label maybe cause problems when being=20 > prefixed by name lable =3D=3D> BIDI name lable. this label may be arabic or hebrew one. > > digits-only label or digits-only mailbox names. If we should redesign=20 > stringprep/nameprep we should take the following BIDI issue together. > > Please see this article from W3.org: > > http://lists.w3.org/Archives/Public/public-iri/2003Sep/0000.html > > Soobok Lee From owner-idn@ops.ietf.org Wed Feb 23 16:50:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23154 for ; Wed, 23 Feb 2005 16:50:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D44I7-00073y-K6 for idn-data@psg.com; Wed, 23 Feb 2005 21:43:31 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D44I4-00072V-Ic for idn@ops.ietf.org; Wed, 23 Feb 2005 21:43:28 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1NLhQpY206100; Wed, 23 Feb 2005 16:43:27 -0500 Message-ID: <421CF8FE.1070706@vanderpoel.org> Date: Wed, 23 Feb 2005 13:43:26 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] homographs of the delimiters aka syntax chars Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've added a table of protocols (DNS, URI and email) with their delimiters to the doc at: http://nameprep.org/ Please send me your additions. Also, readers on this list may be interested to see: http://www.unicode.org/reports/tr36/tr36-2.html This doc calls them "syntax characters". Erik From owner-idn@ops.ietf.org Wed Feb 23 17:50:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04442 for ; Wed, 23 Feb 2005 17:50:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D45GE-000FIV-Ss for idn-data@psg.com; Wed, 23 Feb 2005 22:45:38 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D45GB-000FHw-UY for idn@ops.ietf.org; Wed, 23 Feb 2005 22:45:36 +0000 Received: from [10.20.30.249] ([65.209.230.238]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1NMjTSo039945; Wed, 23 Feb 2005 14:45:30 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <421CF8FE.1070706@vanderpoel.org> References: <421CF8FE.1070706@vanderpoel.org> Date: Wed, 23 Feb 2005 14:45:24 -0800 To: Erik van der Poel , idn@ops.ietf.org From: Paul Hoffman Subject: Re: [idn] homographs of the delimiters aka syntax chars Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 1:43 PM -0800 2/23/05, Erik van der Poel wrote: >Also, readers on this list may be interested to see: > >http://www.unicode.org/reports/tr36/tr36-2.html > >This doc calls them "syntax characters". The Unicode Consortium's call for comments was: >The Unicode Technical Committee has posted a new Draft Unicode Technical >Report for public review and comment. Details of the issue are on the >following web page: > > http://www.unicode.org/review/ > >Briefly the issue is: > >64 Draft UTR #36: Security Considerations for the Implementation > of Unicode and Related Technology > >This draft Unicode Technical Report describes security considerations >that are important to be aware of when working with Unicode, and provides >specific recommendations for dealing with the issues that arise. > >The technical report itself is located at the following link: > > http://www.unicode.org/reports/tr36/tr36-2.html > >Review period for this draft closes on May 3, 2005. > > >If you have comments for official UTC consideration, please post them by >submitting your comments through our feedback & reporting page: > > http://www.unicode.org/reporting.html > >If you wish to discuss issues on the Unicode mail list, then please >use the following link to subscribe (if necessary). Please be aware >that discussion comments on the Unicode mail list are not automatically >recorded as input to the UTC. You must use the reporting link above >to generate comments for UTC consideration. > > http://www.unicode.org/consortium/distlist.html > >Regards, > Rick McGowan --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Thu Feb 24 02:48:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12639 for ; Thu, 24 Feb 2005 02:48:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4DYO-000E7g-UL for idn-data@psg.com; Thu, 24 Feb 2005 07:36:56 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4DYM-000E7R-OQ for idn@ops.ietf.org; Thu, 24 Feb 2005 07:36:55 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1O7anuq419934; Thu, 24 Feb 2005 02:36:50 -0500 Message-ID: <421D8411.9030006@vanderpoel.org> Date: Wed, 23 Feb 2005 23:36:49 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: [idn] punctuation References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > I imagine you'd want all the characters that could immediately follow > the host name in a URI, so add "?" and "#" to that list. > > But how well do average users know URI syntax anyway? What would they > think of: > > http://foo.com&bar.baz.xx > http://foo.com~bar.baz.xx > http://foo.com|bar.baz.xx > > Maybe we either need to ban all punctuation (as in my proposal about > internationalized host names), or always make the boundaries of the > domain name apparent to the user (using color or highlighting or > underlining or something). I started to write down all the delimiters that could appear in DNS, URIs and email, and then I realized that this problem is not just about the homographs of the *legal* delimiters used in these contexts. No, it is about whatever *looks like* a legal delimiter to the average user, because the phishers don't have to stick to the (homographs of the) legal delimiters. Then I went back in the archives, and of course, Adam has already pointed this out. The implications of this are actually quite profound. Since there are so many characters in Unicode, and since many of those are unfamiliar to the average user, a lot of those might look like punctuation. As Adam also points out in another email, it's too bad that domain names are usually displayed in "little-endian" order. If they were displayed in the opposite (big-endian) order, the 3rd example above would become: http://xx.baz.com|bar.foo Notice how the "com" and "foo" are now separated. The "real" (unspoofed) URI would look like this: http://com.foo If users were actually used to seeing it this way, they might notice the spoof above more easily. But they aren't used to seeing it this way, and it would be pretty difficult to change this convention now. It's too late. Back to punctuation: Banning all punctuation would not be enough. We would have to ban anything that might look like punctuation to the user. That would mean banning a huge swath of Unicode, which is probably not in the best interests of various communities around the world. Besides, different people will have different ideas about what looks like punctuation. So it might be hard to decide which huge swath of Unicode to ban. So maybe it's better to consider Adam's alternative idea: make the boundaries of the domain name apparent (using color or whatever). Over time, the users will get used to seeing domain names this way, and then they will be able to spot domain name spoofs more easily too. But even if we were to color the whole domain name: foo.com|bar.baz.xx The user might still think that this site is somehow related to foo.com and therefore safe (as was also pointed out). So you'd have to display the "unusual" characters like '|' differently. Or something. Sigh. Seems hopeless. Are the phishers going to have a field day with IDN, or what? But is this problem really limited to IDN? What about the following legal ASCII DNS name: foo.com--secure-user-services-and-products.tech-mecca.biz Does this mean that we should try to switch left-to-right readers (most of the world) over to big-endian domain names? Please tell me I'm overreacting! Erik From owner-idn@ops.ietf.org Thu Feb 24 03:21:43 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15437 for ; Thu, 24 Feb 2005 03:21:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4EBY-000JHs-Mo for idn-data@psg.com; Thu, 24 Feb 2005 08:17:24 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4EBW-000JHY-L4 for idn@ops.ietf.org; Thu, 24 Feb 2005 08:17:22 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D4EBV-0003N6-00 for ; Thu, 24 Feb 2005 00:17:21 -0800 Date: Thu, 24 Feb 2005 08:17:21 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue Message-ID: <20050224081721.GB12336~@nicemice.net> Reply-To: IETF idn working group References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421CA114.9090302@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > The IETF generally only specifies the "wire" protocol, not UI > behavior. The IETF does not specify how apps interface with users; Generally, that's true, but IDNA is an exception. It state four requirements (RFC 3490 section 3.1), and one of those four has rather little to do with wire protocols, and quite a lot to do with UI behavior: 3) ACE labels obtained from domain name slots SHOULD be hidden from users when it is known that the environment can handle the non-ACE form, except when the ACE form is explicitly requested. When it is not known whether or not the environment can handle the non-ACE form, the application MAY use the non-ACE form (which might fail, such as by not being displayed properly), or it MAY use the ACE form (which will look unintelligible to the user). I think this discussion is headed toward an update to IDNA that would add a second exception to that requirement, for protecting the user against phishing. What we need to figure out is how to describe that exception, and how specific or deliberately vague that description should be. AMC From owner-idn@ops.ietf.org Thu Feb 24 05:06:23 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26276 for ; Thu, 24 Feb 2005 05:06:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4FpA-0006hg-2l for idn-data@psg.com; Thu, 24 Feb 2005 10:02:24 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Fp8-0006hJ-Qp for idn@ops.ietf.org; Thu, 24 Feb 2005 10:02:23 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id j1OA2LoN067669 for ; Thu, 24 Feb 2005 11:02:21 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200502241002.j1OA2LoN067669@bartok.nlnetlabs.nl> To: IETF idn working group Subject: Re: [idn] punctuation In-reply-to: Your message of Wed, 23 Feb 2005 23:36:49 -0800. <421D8411.9030006@vanderpoel.org> Date: Thu, 24 Feb 2005 11:02:21 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk But is this problem really limited to IDN? What about the following legal ASCII DNS name: foo.com--secure-user-services-and-products.tech-mecca.biz I don't know what the problem is with this one. It is a perfect normal domain name. (*) Does this mean that we should try to switch left-to-right readers (most of the world) over to big-endian domain names? Please tell me I'm overreacting! If I remember correctly, that is what the plan9 people did with ``text'' files (although there was not really a concept of file types). The information in the file was considered to be in ``time order'', and the time went from left to right. Time order as in, if you read it out allowed, the first phrase you utter was the first in time. Whether it should be displayed right to left or in time order is considered an display (application) problem. So ``cat'' would not bother with the write order and just dump the bytes, but your display might parse the unicode (runes) and certainly ``troff'' should (**). jaap (*) Although YMMV. In .nl, two consecutive hyphens have never been allowed for registration by the registry. (**) There was a version of troff around (done in Israel) which actually did all four directions (left-right, right-left, printing downwards and, I believe, for good measures also upwards) From owner-idn@ops.ietf.org Thu Feb 24 10:21:56 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01630 for ; Thu, 24 Feb 2005 10:21:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Kbn-000NuQ-9d for idn-data@psg.com; Thu, 24 Feb 2005 15:08:55 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Kbk-000Nty-Rg for idn@ops.ietf.org; Thu, 24 Feb 2005 15:08:53 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OF8lpY115802; Thu, 24 Feb 2005 10:08:48 -0500 Message-ID: <421DEDFF.2000300@vanderpoel.org> Date: Thu, 24 Feb 2005 07:08:47 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> <20050224081721.GB12336~@nicemice.net> In-Reply-To: <20050224081721.GB12336~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > Erik van der Poel wrote: >>The IETF generally only specifies the "wire" protocol, not UI >>behavior. The IETF does not specify how apps interface with users; > > Generally, that's true, but IDNA is an exception. It state four > requirements (RFC 3490 section 3.1), and one of those four has rather > little to do with wire protocols, and quite a lot to do with UI > behavior: > > 3) ACE labels obtained from domain name slots SHOULD be hidden from > users when it is known that the environment can handle the non-ACE > form, except when the ACE form is explicitly requested. When it > is not known whether or not the environment can handle the non-ACE > form, the application MAY use the non-ACE form (which might fail, > such as by not being displayed properly), or it MAY use the ACE > form (which will look unintelligible to the user). I don't think IDNA is an exception. Note that the part you quote above uses words like SHOULD and MAY. I would say that those words were chosen for *exactly* the reasons I mentioned (i.e. IETF *specifies* wire protocols, not UI behavior). See section 6 of: http://ietf.org/rfc/rfc2119.txt This RFC focusses on "interoperability" (but also mentions "harm") so I would say that the wire protocol is the main concern. > I think this discussion is headed toward an update to IDNA that would > add a second exception to that requirement, for protecting the user > against phishing. What we need to figure out is how to describe that > exception, and how specific or deliberately vague that description > should be. Here I agree with you. I'm not going to try to come up with the wording for that, but this morning I started to think that the right-to-left DNS and IDN spoofing problems *could* be addressed at the UI level by providing a *tool* that security-conscious users could *choose* to use. I'm thinking of a tool that might be implemented as an extension for Mozilla, for example. It would offer to display domain names in the safe order, i.e. left-to-right for users whose main language is left-to-right. I have not heard of any UIs that offer top-to-bottom in their menus, dialogs, etc, so I would guess that this would be omitted in the extension too, though right-to-left might be offered for right-to-left users (many of which are in the Middle East -- Hebrew and Arabic). In addition, such a tool would offer to display domain names in a clear font, unlike the sans-serif that is commonly used today. This would make the distinction between lowercase l and digit 1 clearer. And it would separate the domain name from its context, e.g. using color. Finally, this tool would offer to display characters outside the user's language(s) in a special way, to make them stand out and catch the user's attention. I believe we need to focus on the user here, because we are talking about how things *look* to the user. For example, people in the Far East are used to spotting small differences between complicated characters because they were taught as children to read and write the thousands of complex "Han" characters that differ in small ways. Americans, on the other hand, are only used to seeing a small number of characters, and would not even be able to *read* Han characters, let alone spot differences between them. This is why I believe that a tool that focusses on the user might be a good idea. You may claim that nobody would ever want to read domain names left-to-right, to which I would counter that some people are willing to try Dvorak keyboards, which are totally different from QWERTY. I.e. it's the user's choice. Internet security education may eventually lead *some* users to make this choice. Erik From owner-idn@ops.ietf.org Thu Feb 24 10:52:04 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05497 for ; Thu, 24 Feb 2005 10:52:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4LDj-0002WV-Dg for idn-data@psg.com; Thu, 24 Feb 2005 15:48:07 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4LDf-0002WG-Ts for idn@ops.ietf.org; Thu, 24 Feb 2005 15:48:04 +0000 Received: from pimout6-ext.prodigy.net (pimout6-ext.prodigy.net [207.115.63.78]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1OFlwxd014529 for ; Thu, 24 Feb 2005 10:48:01 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout6-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OFlvpH345048; Thu, 24 Feb 2005 10:47:58 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <421D8411.9030006@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> Date: Thu, 24 Feb 2005 10:47:56 -0500 To: idn@ops.ietf.org From: tedd Subject: Re: [idn] punctuation Cc: Erik van der Poel Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik et al: >But even if we were to color the whole domain name: > >foo.com|bar.baz.xx > >The user might still think that this site is somehow related to >foo.com and therefore safe (as was also pointed out). So you'd have >to display the "unusual" characters like '|' differently. Or >something. Sigh. Seems hopeless. Yes, it may seem hopeless. I believe that the "fruit-loop" solution would fall short of expectations. However, browser makers may find opportunity in providing a more in-your-face homographic solution by analyzing url's and alerting users of potential problems (i.e., beating them about the head). But this possibility/solution is beyond the scope of this group. >Are the phishers going to have a field day with IDN, or what? Yes, they probably are going to have a field day, but I don't think there is much that can be done about that. Much of this problem will be dealt with in the courts -- where it should be. As for end-users, remember less than ten years ago the average user didn't care squat about spam, but now they think different. This homographic phenomena will run its course as well and solutions will be found. >But is this problem really limited to IDN? What about the following >legal ASCII DNS name: > >foo.com--secure-user-services-and-products.tech-mecca.biz > >Does this mean that we should try to switch left-to-right readers >(most of the world) over to big-endian domain names? Please tell me >I'm overreacting! Possibly... but perhaps everyone is overreacting. IMO no safeguards will stop illegal use of anything. Stop signs don't stop everyone regardless of size, color, placement, fines, and laws regarding stop signs. Likewise, and no offense, the efforts of this group will be no different. There will be abuse regardless. The most I think anyone can do is to focus on approaches like the "Delimiter solution" such as those noted at: http://nameprep.org/ Therein, I think there is solid logic in this approach. You might even go after punctuation or symbols, but then there are honest reasons for people having punctuation and symbols in domain names -- do you want to prohibit them because of the possibility of abuse? Abuse, I might add, that could/should be dealt with via ICANN and/or the courts -- where both sides can present their arguments. Not everyone who uses a symbol in a domain name is wrong or is attempting to commit fraud. For example, I have the domain "not-equal sign" dot com. Why? It seemed kind of neat at the time, and being disabled, I was thinking of using it as a discrimination related web site. But, I had a business approach me yesterday saying that they wanted to purchase the name because the design (the not-equal sign) resembles their product, which is a cat toy -- imagine that. So, for what purpose/use can a symbol domain name be? It depends upon the market and regardless if you believe in, or approve of, market forces, there are honest reasons for such domain names. So, let's not throw the baby out with the bath water. There are going to be many avenues for abuse, and I suspect many more than this group can imagine. I know that after reading: http://www.unicode.org/reports/tr36/tr36-2.html I was alerted to more than what I wanted to know. However, my advice (being one of the lessor thinkers in this group) is to concentrate on solid logic, like the delimiter argument, and not on what "may" happen. I'm not saying "give-up" -- I'm simply saying "don't overreact". tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Thu Feb 24 12:27:01 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20077 for ; Thu, 24 Feb 2005 12:27:00 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Mg6-000ExX-7Y for idn-data@psg.com; Thu, 24 Feb 2005 17:21:30 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Mg3-000ExE-99 for idn@ops.ietf.org; Thu, 24 Feb 2005 17:21:27 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OHLGpY336252; Thu, 24 Feb 2005 12:21:25 -0500 Message-ID: <421E0D0C.2000309@vanderpoel.org> Date: Thu, 24 Feb 2005 09:21:16 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tedd CC: idn@ops.ietf.org Subject: Re: [idn] punctuation References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit tedd wrote: > I believe that the "fruit-loop" solution > would fall short of expectations. I wasn't talking about many colors. A character is either in the user's set or not. So we only need 2 colors (if colors are used at all). The user's set is typically derived from the browser localization or HTTP Accept-Language preference setting. Erik From owner-idn@ops.ietf.org Thu Feb 24 13:04:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24017 for ; Thu, 24 Feb 2005 13:04:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4NIO-000JqK-LN for idn-data@psg.com; Thu, 24 Feb 2005 18:01:04 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4NIM-000Jpw-Cw for idn@ops.ietf.org; Thu, 24 Feb 2005 18:01:02 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OI0xSJ208658; Thu, 24 Feb 2005 13:01:00 -0500 Message-ID: <421E165B.6040706@vanderpoel.org> Date: Thu, 24 Feb 2005 10:00:59 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: Re: [idn] punctuation References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> In-Reply-To: <421D8411.9030006@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If they were displayed > in the opposite (big-endian) order, the 3rd example above would become: > > http://xx.baz.com|bar.foo > > Notice how the "com" and "foo" are now separated. There was a gap in my logic here. A phisher could easily keep the "com" and "foo" next to each other. My real point is that big-endian display of domain names would put the important parts of the name near the beginning for a left-to-right reader: > The "real" (unspoofed) > URI would look like this: > > http://com.foo Erik From owner-idn@ops.ietf.org Thu Feb 24 13:27:58 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26724 for ; Thu, 24 Feb 2005 13:27:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4NeR-000MgU-TK for idn-data@psg.com; Thu, 24 Feb 2005 18:23:51 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4NeP-000MgF-TR for idn@ops.ietf.org; Thu, 24 Feb 2005 18:23:49 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 10:23:49 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 10:23:26 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 24 Feb 2005 10:23:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 24 Feb 2005 10:23:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] punctuation Date: Thu, 24 Feb 2005 10:23:47 -0800 Message-ID: Thread-Topic: [idn] punctuation thread-index: AcUamzMFZrWCSMRCQ8Oud0d1NElAcQAAY0hA From: "Michel Suignard" To: "Erik van der Poel" Cc: "IETF idn working group" X-OriginalArrivalTime: 24 Feb 2005 18:23:49.0354 (UTC) FILETIME=[FC366CA0:01C51A9D] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Many web sites use deep DNS sub-zones today (including the company I = work for) and I really doubt our customers would appreciate such a = radical change in user experience. Most people expect to see = www.example.org not org.example.www. These days the 'www' is really = noise, but it also frequent to see myzone.example.org which works really = well with autocompletion logic. Putting org first would sort of defeat = that logic as well. Don't get me wrong, your idea is good, it is just way too late. Like somebody else already said, I feel some level of overreaction in = these threads. Michel=20 -----Original Message----- From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org] On Behalf = Of Erik van der Poel Sent: Thursday, February 24, 2005 10:01 AM To: IETF idn working group Subject: Re: [idn] punctuation > If they were displayed > in the opposite (big-endian) order, the 3rd example above would = become: >=20 > http://xx.baz.com|bar.foo >=20 > Notice how the "com" and "foo" are now separated. There was a gap in my logic here. A phisher could easily keep the "com"=20 and "foo" next to each other. My real point is that big-endian display = of domain names would put the important parts of the name near the = beginning for a left-to-right reader: > The "real" (unspoofed) > URI would look like this: >=20 > http://com.foo Erik From owner-idn@ops.ietf.org Thu Feb 24 13:28:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26790 for ; Thu, 24 Feb 2005 13:28:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Ndf-000MeS-T2 for idn-data@psg.com; Thu, 24 Feb 2005 18:23:03 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Ndd-000MeC-Sd for idn@ops.ietf.org; Thu, 24 Feb 2005 18:23:02 +0000 Received: from pimout7-ext.prodigy.net (pimout7-ext.prodigy.net [207.115.63.58]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1OIMwxd020705 for ; Thu, 24 Feb 2005 13:22:59 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OIMwMk183410 for ; Thu, 24 Feb 2005 13:22:59 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <421E0D0C.2000309@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> Date: Thu, 24 Feb 2005 13:22:57 -0500 To: idn@ops.ietf.org From: tedd Subject: Re: [idn] punctuation Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk >tedd wrote: >>I believe that the "fruit-loop" solution would fall short of expectations. > >I wasn't talking about many colors. A character is either in the >user's set or not. So we only need 2 colors (if colors are used at >all). The user's set is typically derived from the browser >localization or HTTP Accept-Language preference setting. > >Erik Erik: I understand -- however: First, I was addressing the idea of a colored url via a "tool-tip plug-in" type solution -- a multi-colored or two toned fruit loop -- it doesn't make any difference, it's the same idea. Second, while the user's set is typically derived as you say, I imagine there will be users who will transcend those boundaries (i.e., multilingual). Considering such, whatever the solution, it will most likely "look" different for the same url and thus lose some of it's potency as an alert. Third, I imagine there may even be concerns (i.e., companies, persons, organizations, sport groups, and even countries) who may want a fruit-loop domain with their specific colors. It might get that ridiculous or maybe this will be a new way to market domains. :-) It's not a bad idea, just one that falls short of solving the problem. Sometimes adding partial solutions to a problem become part of the problem. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Thu Feb 24 14:02:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00509 for ; Thu, 24 Feb 2005 14:02:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4OBS-00016l-Mr for idn-data@psg.com; Thu, 24 Feb 2005 18:57:58 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4OBP-000169-OT for idn@ops.ietf.org; Thu, 24 Feb 2005 18:57:56 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D4OBE-000Laz-O2; Thu, 24 Feb 2005 13:57:44 -0500 Date: Thu, 24 Feb 2005 13:57:44 -0500 From: John C Klensin To: tedd , idn@ops.ietf.org Subject: Re: [idn] punctuation Message-ID: In-Reply-To: References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tedd, It seems to me that, if an application wanted to provide its users a way to specify a list of expected characters that was relatively short compared to the size of Unicode, and then to warn the user in some way when an unexpected character appeared, that would be reasonable and, for some users, helpful. I think the idea gets into trouble only when the application starts making guesses as to what should (or should not) be on that list. No, this wouldn't "solve" the problem. I agree with Erik that, if people had people had high expectations for it, they would be badly disappointed. But I'm convinced that we aren't going to find a magic bullet here. Instead, we can do some large fraction of the "useful, but not a solution" tools that have been suggested. We can try to restrict characters that are clearly dangerous, adopting, if necessary, a view that the fact someone wants to register or use a particular string doesn't mean that they are entitled to do so. We can adopt a variety of warning technologies --whether they involve colors, displaying punycode, pop-up warnings, or something else-- and let applications compete on which ones can do a better job of that. We can try some user education. We can use the UDRP and/or the legal system in various countries to push back on those who register deceptive names and on the registrars and registries that encourage the registration of such names. And other ideas may come along that should be implemented. Then we can hope that those things, in combination, reduce the problem to some tolerable level, understanding that it will never completely go away. john --On Thursday, 24 February, 2005 13:22 -0500 tedd wrote: >> tedd wrote: >>> I believe that the "fruit-loop" solution would fall short of >>> expectations. >> >> I wasn't talking about many colors. A character is either in >> the user's set or not. So we only need 2 colors (if colors >> are used at all). The user's set is typically derived from >> the browser localization or HTTP Accept-Language preference >> setting. >> >> Erik > > Erik: > > I understand -- however: > > First, I was addressing the idea of a colored url via a > "tool-tip plug-in" type solution -- a multi-colored or two > toned fruit loop -- it doesn't make any difference, it's the > same idea. > > Second, while the user's set is typically derived as you say, > I imagine there will be users who will transcend those > boundaries (i.e., multilingual). Considering such, whatever > the solution, it will most likely "look" different for the > same url and thus lose some of it's potency as an alert. > > Third, I imagine there may even be concerns (i.e., companies, > persons, organizations, sport groups, and even countries) who > may want a fruit-loop domain with their specific colors. It > might get that ridiculous or maybe this will be a new way to > market domains. :-) > > It's not a bad idea, just one that falls short of solving the > problem. Sometimes adding partial solutions to a problem > become part of the problem. From owner-idn@ops.ietf.org Thu Feb 24 14:06:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00904 for ; Thu, 24 Feb 2005 14:06:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4OHB-00022W-7Q for idn-data@psg.com; Thu, 24 Feb 2005 19:03:53 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4OH9-000226-53 for idn@ops.ietf.org; Thu, 24 Feb 2005 19:03:51 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OJ3juq104784; Thu, 24 Feb 2005 14:03:46 -0500 Message-ID: <421E2511.3080508@vanderpoel.org> Date: Thu, 24 Feb 2005 11:03:45 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michel Suignard CC: IETF idn working group Subject: Re: [idn] punctuation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Michel Suignard wrote: > Many web sites use deep DNS sub-zones today > (including the company I work for) and I really > doubt our customers would appreciate such a > radical change in user experience. As has already been pointed out on this list, a phisher could take advantage of a very long domain name to push the important part past the end of the display area. In the long run, the phishing problem may outweigh the user experience problem that would result from the radical change that I am talking about. Besides, there is a much better way to tell the user where they are. See the blurb about "breadcrumb trails" at: http://useit.com/alertbox/20000109.html You can see these breadcrumb trails near the top of: http://msdn.microsoft.com/Longhorn/toolsamp/default.aspx > it also frequent to see > myzone.example.org which works really well with > autocompletion logic. Putting org first would > sort of defeat that logic as well. I have seen autocompleters that work for the middle or end of a string. In fact, Microsoft Internet Explorer has one. > Like somebody else already said, I feel some > level of overreaction in these threads. Ten years from now, let's revisit this topic together, shall we? I am not a betting man, but let's just see how it goes. Erik From owner-idn@ops.ietf.org Thu Feb 24 14:37:13 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05702 for ; Thu, 24 Feb 2005 14:37:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Ogz-00059Z-UN for idn-data@psg.com; Thu, 24 Feb 2005 19:30:33 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Ogr-000590-1C for idn@ops.ietf.org; Thu, 24 Feb 2005 19:30:25 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 11:30:24 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 11:29:59 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 11:30:23 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 24 Feb 2005 11:30:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [idn] punctuation Date: Thu, 24 Feb 2005 11:30:23 -0800 Message-ID: Thread-Topic: [idn] punctuation thread-index: AcUao6NxeeH3HyESSUyZYYKhYJ9mUwAAlJwg From: "Michel Suignard" To: "Erik van der Poel" Cc: "IETF idn working group" X-OriginalArrivalTime: 24 Feb 2005 19:30:22.0607 (UTC) FILETIME=[486079F0:01C51AA7] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Erik, I don't think it is useful to engage on a debate about web site = design and the appropriateness of multi node web site. All your points = are probably valid there but they are mostly orthogonal to the = discussion here. I am still not convinced that reversing the display order of domain = names is a good idea. And there are many more reasons that the ones I = already gave, such as disruption of the current logical order. = Especially if we can convince quickly ICANN and most registry orgs to = effectively deprecate usage of all homographs of URI reserved = characters. This seems to me a more realistic approach and it doesn't = prevent browsers to pay attention to those homographs when they are = detected in IRIs. Michel=20 From owner-idn@ops.ietf.org Thu Feb 24 14:58:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07852 for ; Thu, 24 Feb 2005 14:58:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4P4y-00087D-5G for idn-data@psg.com; Thu, 24 Feb 2005 19:55:20 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4P4t-000850-4L for idn@ops.ietf.org; Thu, 24 Feb 2005 19:55:15 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D4P4r-000LtB-Hc; Thu, 24 Feb 2005 14:55:13 -0500 Date: Thu, 24 Feb 2005 14:55:09 -0500 From: John C Klensin To: Michel Suignard , Erik van der Poel cc: IETF idn working group Subject: RE: [idn] punctuation Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 February, 2005 11:30 -0800 Michel Suignard wrote: > Erik, I don't think it is useful to engage on a debate about > web site design and the appropriateness of multi node web > site. All your points are probably valid there but they are > mostly orthogonal to the discussion here. > > I am still not convinced that reversing the display order of > domain names is a good idea. And there are many more reasons > that the ones I already gave, such as disruption of the > current logical order. Especially if we can convince quickly > ICANN and most registry orgs to effectively deprecate usage of > all homographs of URI reserved characters. This seems to me a > more realistic approach and it doesn't prevent browsers to pay > attention to those homographs when they are detected in IRIs. Michel, If we can reach some reasonable consensus about what characters (URI-reserved or otherwise) that ICANN should deprecate, I'm more than happy to put my liaison hat on and forcefully carry the message over there. But we need to remember that ICANN's authority, and hence the impact of their deprecating something, is very limited. In particular: * For the gTLDs, they can create additional guidelines or modify the existing ones, but it is not clear how forcefully they can, or will, apply them if some gTLDs decide to ignore those guidelines. As has been pointed out, the example that started these thread could almost certainly not have been registered if the intent of the existing guidelines had been observed by all relevant domains. * For the ccTLDs, ICANN can recommend and advise, but their enforcement power is between "slight" and "none", at least unless there is a clear violation of a standard (see below). * For any domain below the second level -- i.e., a registration in a TLD -- ICANN is generally not only completely lacking in authority but most of the relevant domain administrators don't even have a way to hear about the fact that ICANN has deprecated (or otherwise recommended against the use of) some characters. So, yes, let's do something. Note, fwiw, that they have opened a public comment forum at idn-homograph@icann.org -- see the "IDN Homograph Concerns" section on http://www.icann.org/topics/idn.html. But, if we think particular characters are bad news, we need to follow up whatever actions browser-writers take spontaneously, and whatever we ask ICANN to do, by deprecating them in nameprep. If those nameprep changes are implemented, then the characters get rejected at both registration and lookup time, in a consistent way, and get rejected in any domain and at any level of the tree. And violating the standard is something that gives ICANN at least a little leverage, since most registries have agreed -- as a consequence of accepting RFC 1591 if not by explicit agreements with ICANN, that ignoring standards is a Bad Thing. john From owner-idn@ops.ietf.org Thu Feb 24 14:58:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07878 for ; Thu, 24 Feb 2005 14:58:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4P4Q-0007zV-6s for idn-data@psg.com; Thu, 24 Feb 2005 19:54:46 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4P4P-0007zE-1B for idn@ops.ietf.org; Thu, 24 Feb 2005 19:54:45 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OJsQHb209220; Thu, 24 Feb 2005 14:54:31 -0500 Message-ID: <421E30F2.1040408@vanderpoel.org> Date: Thu, 24 Feb 2005 11:54:26 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: tedd , idn@ops.ietf.org Subject: Re: [idn] punctuation References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > We can try > to restrict characters that are clearly dangerous, adopting, if > necessary, a view that the fact someone wants to register or use > a particular string doesn't mean that they are entitled to do > so. You can write RFCs, move them to STD status, and jump up and down all you want, but you can't stop domain name owners from creating "deep" sub-domains with deceptive names that make the important part of the name go off the end of the display area. > We > can use the UDRP and/or the legal system in various countries to > push back on those who register deceptive names and on the > registrars and registries that encourage the registration of > such names. The registrars and registries are not the problem. The domain name owners are. If a poor individual has created a deceptive name that hurts a huge company, that company may go after Microsoft (since it has deep pockets) instead of the poor person. So, the apps' current way of displaying the domain name (right-to-left) in left-to-right cultures is the problem. I tried to make the case that this is even a problem in the ASCII DNS (regardless of IDN), since hyphens are allowed in most DNS implementations. I wonder if a phisher would only have to change their own DNS server to get other characters (like ASCII slash '/') into the names? Or would many of the DNS clients refuse to lookup names containing such characters? (I tried to create a name containing ASCII slash yesterday, but my DNS server wouldn't accept it.) Hasn't this stuff been covered in any RFC yet? Erik From owner-idn@ops.ietf.org Thu Feb 24 17:27:52 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29789 for ; Thu, 24 Feb 2005 17:27:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4RNi-000Pqc-I0 for idn-data@psg.com; Thu, 24 Feb 2005 22:22:50 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4RNf-000PpY-VN for idn@ops.ietf.org; Thu, 24 Feb 2005 22:22:48 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D4RNe-000Mdu-BY; Thu, 24 Feb 2005 17:22:46 -0500 Date: Thu, 24 Feb 2005 17:22:35 -0500 From: John C Klensin To: Erik van der Poel cc: tedd , idn@ops.ietf.org Subject: Re: [idn] punctuation Message-ID: <0E7F74C71945B923C52211F3@scan.jck.com> In-Reply-To: <421E30F2.1040408@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 February, 2005 11:54 -0800 Erik van der Poel wrote: > John C Klensin wrote: >> We can try >> to restrict characters that are clearly dangerous, adopting, >> if necessary, a view that the fact someone wants to register >> or use a particular string doesn't mean that they are >> entitled to do so. > > You can write RFCs, move them to STD status, and jump up and > down all you want, but you can't stop domain name owners from > creating "deep" sub-domains with deceptive names that make the > important part of the name go off the end of the display area. Of course not. But there are several separate problems here. For example: (i) No one _makes_ an application author write things so that "go off the end of the display area" is an option. It may or may not be worth it, but there are all sorts of ways to design a UI so that things wrap, scroll, pop-up, warn, or are otherwise accessible from end to end. It seems to me that convincing your favorite applications author to not let long FQNS disappear off-screen is likely to be a lot easier than turning domain names around (see below). (ii) The Internet has never had a presentation layer, and the IETF and its predecessors have never tried to standardize one or what happens in it. To some extent, many of the issues with URIs/IRIs, IDNs, etc., suggest that may have been a mistake. But we just haven't gone in that direction and starting to do so now would be a pretty big deal. A presentation layer might solve this problem because a user could then specify how various things are to be displayed. Without it, and without common operating system or utility library interfaces for these things that everyone uses, one risks having one application use one display order and another application, on the same host and for the same user, use a different one. That would create a mess and its own set of risks; see below. >> We >> can use the UDRP and/or the legal system in various countries >> to push back on those who register deceptive names and on the >> registrars and registries that encourage the registration of >> such names. > > The registrars and registries are not the problem. The domain > name owners are. If a poor individual has created a deceptive > name that hurts a huge company, that company may go after > Microsoft (since it has deep pockets) instead of the poor > person. As I have said before, there is no magic bullet solution to this group of problems. And, for the zones that are under their control, the registries are the problem (for some part of the broader problem) because they are in a position to prohibit unacceptable registrations .. as they have done for years in prohibiting names that aren't "hostname" (LDH)-conformant. That conformance is not not now, and has never been, a DNS protocol requirement. > So, the apps' current way of displaying the domain name > (right-to-left) in left-to-right cultures is the problem. I > tried to make the case that this is even a problem in the > ASCII DNS (regardless of IDN), since hyphens are allowed in > most DNS implementations. I wonder if a phisher would only > have to change their own DNS server to get other characters > (like ASCII slash '/') into the names? Or would many of the > DNS clients refuse to lookup names containing such characters? > (I tried to create a name containing ASCII slash yesterday, > but my DNS server wouldn't accept it.) There are people who would claim that your DNS server is broken -- see RFC 2181. However... The reality is that whether DNS names were to be treated as big-endian or little-endian was hotly developed when the DNS was first being designed and, if I recall what I was told, actually changed once or twice. Plus or minus a bit, for every argument that it should be one way, there was an argument that it should be the other. For example, while you would like to see com.mumblefraz.foo so as to detect issues the TLD chosen, it is equally the case that, for many of us in daily use, the distinction between foo.mumblefraz.com and bar.mumblefraz.com is more important. Regardless of how one might toss that particular coin, it has been tossed. We have a huge deployed base of the current order and, even worse than software issues, the current order has been imprinted on the consciousness of a lot of folks who don't really know what a domain name is. Due to the intersection of old JANET Coloured Book names with DNS names, we also have considerable experience trying to operate an Internet in which some names run from left to right and others run from right to left. It wasn't a lot of fun and sometimes people (and software) made mistakes: a domain name like uk.ac.ucl.bar.com was a public nuisance or worse. So, like it or not, I think you had best let this one go and get used to it. FWIW, my ordering preference is the same as yours. But, if I were to make a list of the Internet design decisions that, in retrospect, I would have been happier if they had been made some other way, this one wouldn't make the top ten. And I suspect that opinion would be consistent with a poll of either users or protocol designers, had such a poll been held. (Also, FWIW, "not having domain names in URLs at all" would be close to the top of my list.) john From owner-idn@ops.ietf.org Thu Feb 24 17:29:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29869 for ; Thu, 24 Feb 2005 17:29:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4RQn-0000IH-EN for idn-data@psg.com; Thu, 24 Feb 2005 22:26:01 +0000 Received: from [207.115.57.43] (helo=ylpvm12.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4RQk-0000Hi-9h for idn@ops.ietf.org; Thu, 24 Feb 2005 22:25:58 +0000 Received: from pimout5-ext.prodigy.net (pimout5-ext.prodigy.net [207.115.63.73]) by ylpvm12.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j1OMPgxf007534 for ; Thu, 24 Feb 2005 17:25:51 -0500 X-ORBL: [69.208.249.149] Received: from [192.168.0.101] (adsl-69-208-249-149.dsl.lgtpmi.ameritech.net [69.208.249.149]) by pimout5-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1OMPYR5121882; Thu, 24 Feb 2005 17:25:36 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> Date: Thu, 24 Feb 2005 17:25:34 -0500 To: idn@ops.ietf.org From: tedd Subject: Re: [idn] punctuation Cc: John C Klensin Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk John: >I think the idea gets into trouble only when the application starts >making guesses as to what should (or should not) be on that >list. Yes, that's one problem -- a big one. >No, this wouldn't "solve" the problem. I agree with Erik that, >if people had people had high expectations for it, they would be >badly disappointed. Agreed. >But I'm convinced that we aren't going to find a magic bullet >here. Instead, we can do some large fraction of the "useful, >but not a solution" tools that have been suggested. Provided that those tools do not instill a false sense of security or overly-warn the end user. I certainly would not want to be on the receiving end of a law suit claiming that my tool-tip didn't warn an end-user of a spoof OR from an honest company suing me for defamation of character because my tool-tip suggested otherwise. I know the law well enough to realize that sometimes doing anything is an admission of responsibility. As such, regardless of the intellectual intent and pursuit, doing something is not always better than doing nothing. If you're going to do something, make sure you have a defendable foundation for your actions. >We can try >to restrict characters that are clearly dangerous, adopting, if >necessary, a view that the fact someone wants to register or use >a particular string doesn't mean that they are entitled to do >so. If you are talking about characters that are "clearly" dangerous, then of course you have sufficient proof for your actions and I agree with you. However, the fact that someone "wants" to register a particular string doesn't mean that they are NOT entitled to do so. In fact, considering civil liberties and freedom of speech, they may even have the right to do so. However, I am not offering a legal opinion. I'm just saying that the entire process is not evolving a vacuum, but rather driven by multifaceted interest and concerns -- that are larger than this list. >We can adopt a variety of warning technologies --whether >they involve colors, displaying punycode, pop-up warnings, or >something else-- and let applications compete on which ones can >do a better job of that. We can try some user education. We >can use the UDRP and/or the legal system in various countries to >push back on those who register deceptive names and on the >registrars and registries that encourage the registration of >such names. And other ideas may come along that should be >implemented. Again, I believe that you are assuming liability by doing so. How much liability depends upon how deep your pockets are, or those of your employer. That's not good, nor bad -- it's just life. >Then we can hope that those things, in combination, reduce the >problem to some tolerable level, understanding that it will >never completely go away. I wish you the best. But before you do, you might want to look into the problems that the anti-spam industry has with the back-lash of law suits from spammers. Not a pretty picture and it seems that everyone has rights, or at the very least, money to spend to prove their point. tedd -- -------------------------------------------------------------------------------- http://sperling.com/ From owner-idn@ops.ietf.org Thu Feb 24 18:09:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04754 for ; Thu, 24 Feb 2005 18:09:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4S1n-0005nd-CY for idn-data@psg.com; Thu, 24 Feb 2005 23:04:15 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4S1m-0005mZ-B1 for idn@ops.ietf.org; Thu, 24 Feb 2005 23:04:14 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1ON40uq126642; Thu, 24 Feb 2005 18:04:05 -0500 Message-ID: <421E5D60.3050802@vanderpoel.org> Date: Thu, 24 Feb 2005 15:04:00 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: tedd , idn@ops.ietf.org Subject: Re: [idn] punctuation References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> In-Reply-To: <0E7F74C71945B923C52211F3@scan.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > > So, like it or not, I think you had best let this one go and get > used to it. FWIW, my ordering preference is the same as yours. OK, I'll stop talking about domain name display order. (But you've all been warned.) Back to the business at hand: For Nameprep, I've been wondering whether it would make sense to explore what exactly would have to happen if we were to change the ACE prefix from xn-- to something else. I.e. clients would have to be updated, servers would have to accept both the old and the new during the transition period, etc. I'm not even sure this is correct. Anyway, I think such an exploration, including many details, might tell us whether or not we should even contemplate making an incompatible change to Nameprep. Or do people think that we should approach this from the other side? I.e. if we can come up with seriously dangerous homographs and other characters that must be banned or mapped in a new nameprep, then this could in itself be viewed as justification for a new ACE prefix, regardless of how hard it might be to add it or move to it. Thoughts? Erik From owner-idn@ops.ietf.org Thu Feb 24 20:09:10 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15180 for ; Thu, 24 Feb 2005 20:09:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4Ts4-000LXK-3B for idn-data@psg.com; Fri, 25 Feb 2005 01:02:20 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Ts1-000LVX-JN for idn@ops.ietf.org; Fri, 25 Feb 2005 01:02:17 +0000 Received: from lns-p19-1-idf-82-251-87-159.adsl.proxad.net ([82.251.87.159] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D4Trz-0002PR-TS; Thu, 24 Feb 2005 17:02:16 -0800 Message-Id: <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Thu, 24 Feb 2005 23:13:06 +0100 To: Erik van der Poel , IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] nameprep2 and the slash homograph issue In-Reply-To: <421DEDFF.2000300@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> <20050224081721.GB12336~@nicemice.net> <421DEDFF.2000300@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Very, very good idea. This could be a _standard_ way to print the domain name in the browser bar. A very simple way could just be to print every URL in the bar with a different color for each level. This does not change anything in any procedure and can be very easily tought and understood. If one standardizes the colors it may help customer support, advertizing, discussing, etc? permitting to speak of the "blue", "red", "green" part of a discussed URI. This would be far easier for lay people than to talk of first, second, etc. level - whatever the language. I suggest you write a private Draft of this asap. Probably a single page enough. Mozilla could make it an immediate update if it would be an RFC on the standard track. This is would stop the developing campaign of concerns, with something which would be considered as positive. Or, would this be for the W3C? jfc At 16:08 24/02/2005, Erik van der Poel wrote: >Adam M. Costello wrote: >>Erik van der Poel wrote: >>>The IETF generally only specifies the "wire" protocol, not UI >>>behavior. The IETF does not specify how apps interface with users; >>Generally, that's true, but IDNA is an exception. It state four >>requirements (RFC 3490 section 3.1), and one of those four has rather >>little to do with wire protocols, and quite a lot to do with UI >>behavior: >> 3) ACE labels obtained from domain name slots SHOULD be hidden from >> users when it is known that the environment can handle the non-ACE >> form, except when the ACE form is explicitly requested. When it >> is not known whether or not the environment can handle the non-ACE >> form, the application MAY use the non-ACE form (which might fail, >> such as by not being displayed properly), or it MAY use the ACE >> form (which will look unintelligible to the user). > >I don't think IDNA is an exception. Note that the part you quote above >uses words like SHOULD and MAY. I would say that those words were chosen >for *exactly* the reasons I mentioned (i.e. IETF *specifies* wire >protocols, not UI behavior). See section 6 of: > >http://ietf.org/rfc/rfc2119.txt > >This RFC focusses on "interoperability" (but also mentions "harm") so I >would say that the wire protocol is the main concern. > >>I think this discussion is headed toward an update to IDNA that would >>add a second exception to that requirement, for protecting the user >>against phishing. What we need to figure out is how to describe that >>exception, and how specific or deliberately vague that description >>should be. > >Here I agree with you. I'm not going to try to come up with the wording >for that, but this morning I started to think that the right-to-left DNS >and IDN spoofing problems *could* be addressed at the UI level by >providing a *tool* that security-conscious users could *choose* to use. > >I'm thinking of a tool that might be implemented as an extension for >Mozilla, for example. It would offer to display domain names in the safe >order, i.e. left-to-right for users whose main language is left-to-right. >I have not heard of any UIs that offer top-to-bottom in their menus, >dialogs, etc, so I would guess that this would be omitted in the extension >too, though right-to-left might be offered for right-to-left users (many >of which are in the Middle East -- Hebrew and Arabic). > >In addition, such a tool would offer to display domain names in a clear >font, unlike the sans-serif that is commonly used today. This would make >the distinction between lowercase l and digit 1 clearer. And it would >separate the domain name from its context, e.g. using color. > >Finally, this tool would offer to display characters outside the user's >language(s) in a special way, to make them stand out and catch the user's >attention. I believe we need to focus on the user here, because we are >talking about how things *look* to the user. > >For example, people in the Far East are used to spotting small differences >between complicated characters because they were taught as children to >read and write the thousands of complex "Han" characters that differ in >small ways. > >Americans, on the other hand, are only used to seeing a small number of >characters, and would not even be able to *read* Han characters, let alone >spot differences between them. This is why I believe that a tool that >focusses on the user might be a good idea. > >You may claim that nobody would ever want to read domain names >left-to-right, to which I would counter that some people are willing to >try Dvorak keyboards, which are totally different from QWERTY. I.e. it's >the user's choice. Internet security education may eventually lead *some* >users to make this choice. > >Erik > > From owner-idn@ops.ietf.org Thu Feb 24 20:22:05 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16941 for ; Thu, 24 Feb 2005 20:22:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4U7j-000NRo-SC for idn-data@psg.com; Fri, 25 Feb 2005 01:18:31 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4U7i-000NRc-MM for idn@ops.ietf.org; Fri, 25 Feb 2005 01:18:30 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1P1IGSJ290836; Thu, 24 Feb 2005 20:18:22 -0500 Message-ID: <421E7CD8.50904@vanderpoel.org> Date: Thu, 24 Feb 2005 17:18:16 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: IETF idn working group Subject: Re: [idn] nameprep2 and the slash homograph issue References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <20050223105244.GE21463~@nicemice.net> <421CA114.9090302@vanderpoel.org> <20050224081721.GB12336~@nicemice.net> <421DEDFF.2000300@vanderpoel.org> <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050224224107.027ee9d0@mail.jefsey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jefsey, Thanks for the support. Your idea about giving each level of the domain name a standard color is very interesting. I am reworking nameprep.org right now, and I'll probably include a section near the end about this. Note that just because this section is in the doc at nameprep.org does not mean that it would necessarily find its way into any Internet Draft, let alone a new RFC. If this section tries to mandate colors, it probably would not be in a normative (or MUST) part of an IETF RFC. It would end up in an informative appendix (or a MAY). No, I don't think W3C is the right organization for this. IDNA has already been produced by the IETF, and domain name issues don't really belong at W3C, even though URIs are covered by some of their docs. Mozilla has very different plans in this space. I have been unable to convince them of the need for tools/extensions. So far. :-) Erik JFC (Jefsey) Morfin wrote: > Very, very good idea. > > This could be a _standard_ way to print the domain name in the browser > bar. A very simple way could just be to print every URL in the bar with > a different color for each level. This does not change anything in any > procedure and can be very easily tought and understood. If one > standardizes the colors it may help customer support, advertizing, > discussing, etc? permitting to speak of the "blue", "red", "green" part > of a discussed URI. This would be far easier for lay people than to talk > of first, second, etc. level - whatever the language. > > I suggest you write a private Draft of this asap. Probably a single page > enough. Mozilla could make it an immediate update if it would be an RFC > on the standard track. This is would stop the developing campaign of > concerns, with something which would be considered as positive. > > Or, would this be for the W3C? > jfc > > At 16:08 24/02/2005, Erik van der Poel wrote: > >> Here I agree with you. I'm not going to try to come up with the >> wording for that, but this morning I started to think that the >> right-to-left DNS and IDN spoofing problems *could* be addressed at >> the UI level by providing a *tool* that security-conscious users could >> *choose* to use. From owner-idn@ops.ietf.org Thu Feb 24 20:48:25 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18919 for ; Thu, 24 Feb 2005 20:48:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4UW3-0001CS-Il for idn-data@psg.com; Fri, 25 Feb 2005 01:43:39 +0000 Received: from [203.117.75.22] (helo=mx1.allumer.com.au) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4UW0-0001C3-D2 for idn@ops.ietf.org; Fri, 25 Feb 2005 01:43:36 +0000 Received: (qmail 2483 invoked by uid 0); 25 Feb 2005 09:46:43 +0800 Received: from wil@dready.org by allumer.com.au by uid 0 with qmail-scanner-1.22 (clamdscan: 0.74. spamassassin: 2.63. Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.97658 secs); 25 Feb 2005 01:46:43 -0000 X-Qmail-Scanner-Mail-From: wil@dready.org via allumer.com.au X-Qmail-Scanner: 1.22 (Clear:RC:0(220.233.74.98):SA:0(0.0/7.0):. Processed in 0.97658 secs) Received: from unknown (HELO ?192.168.1.7?) (wil@dready.org@220.233.74.98) by mx1.allumer.com.au with RC4-MD5 encrypted SMTP; 25 Feb 2005 09:46:41 +0800 Message-ID: <421E82BC.8070805@dready.org> Date: Fri, 25 Feb 2005 12:43:24 +1100 From: William Tan User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] gTLD Registry Constituency's statement X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The gTLD Registry Constituency issued a statement about the homograph attack: http://www.icann.org/topics/news022305.html For languages that use the LDH characters and for which a registry does not have explicit inclusion tables, the LDH table may be used as a default table for registration requests tagged with those languages, pending fully developed inclusion tables becoming available during the course of dialogue between the registries and their reference groups in the respective language communities. The decision to apply the LDH default to a given language will be made in consideration of the requirements applying to the other scripts that might appear in the full inclusion table, such as the restrictions on bidirectional strings imposed by the IDNA standard. These measures will be implemented in the shortest possible time by all of the IDN registries listed above. AFAIK, only com/net has not implemented the restriction in the paragraph quoted above. This may be an indication that Verisign will essentially stop allowing languages for which they have no inclusion tables? If that's the case, it's certainly good news for the community. Nothing has been said about the pre-existing names in those registries, and how they would deal with them in the case of renewals. wil. From owner-idn@ops.ietf.org Thu Feb 24 21:13:46 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21068 for ; Thu, 24 Feb 2005 21:13:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4UuA-0005cv-2q for idn-data@psg.com; Fri, 25 Feb 2005 02:08:34 +0000 Received: from [203.231.231.191] (helo=orasmtp.netian.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4Uu7-0005cI-4e for idn@ops.ietf.org; Fri, 25 Feb 2005 02:08:31 +0000 Received: from [210.117.75.187] (song8765@netian.com) by orasmtp.netian.com (Terrace MailWatcher) with ESMTP id 2005022511:05:47:677955.14026.6 for ; Fri, 25 Feb 2005 11:05:47 +0900 (KST) Message-ID: <006b01c51ade$e6a48250$6d7ba8c0@your52b54f9488> From: =?ks_c_5601-1987?B?vNuz7rrO?= To: Subject: [idn] mailing list Date: Fri, 25 Feb 2005 11:08:27 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C51B2A.54B19DF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-TERRACE-SPAMMARK: NOT YET spam-rated. X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, MIME_BASE64_TEXT autolearn=no version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C51B2A.54B19DF0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 dW5zdWJzY3JpYmUgc29uZzg3NjVAbmV0aWFuLmNvbSAuDQoNClBsZWFzZSByZW1vdmUgIHNvbmc4 NzY1QG5ldGlhbi5jb20gZnJvbSBtYWlsaW5nIGxpc3QuDQoNCnVuc3Vic2NyaWJlIGRlbW8tbGlz dA== ------=_NextPart_000_0068_01C51B2A.54B19DF0 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjYwNCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+dW5zdWJzY3JpYmUmbmJzcDs8QSAN CmhyZWY9Im1haWx0bzpzb25nODc2NUBuZXRpYW4uY29tIj5zb25nODc2NUBuZXRpYW4uY29tPC9B PiAuDQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPlBsZWFzZSBy ZW1vdmUmbmJzcDsmbmJzcDs8QSBocmVmPSIiPnNvbmc4NzY1QG5ldGlhbi5jb208L0E+IGZyb20g bWFpbGluZyANCmxpc3QuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj51bnN1YnNjcmli ZSBkZW1vLWxpc3Q8L0RJVj48L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0068_01C51B2A.54B19DF0-- From owner-idn@ops.ietf.org Thu Feb 24 22:57:11 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29842 for ; Thu, 24 Feb 2005 22:57:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4WVy-000KOx-7t for idn-data@psg.com; Fri, 25 Feb 2005 03:51:42 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4WVx-000KOi-75 for idn@ops.ietf.org; Fri, 25 Feb 2005 03:51:41 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1P3pcSJ326524; Thu, 24 Feb 2005 22:51:38 -0500 Message-ID: <421EA0C9.1010500@vanderpoel.org> Date: Thu, 24 Feb 2005 19:51:37 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] process References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> In-Reply-To: <0E7F74C71945B923C52211F3@scan.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, 1. Is this the right time to start working on Internet Drafts leading up to new version(s) of the IDNA RFC(s)? If not, when? 2. Am I stepping on someone's toes by creating nameprep.org? Feel free to respond publicly or privately. 3. If this is the right time to start work on drafts, who would like to write some prose? 4. Do we need to revive the IDN WG? 5. Any other process questions? Thanks, Erik From owner-idn@ops.ietf.org Thu Feb 24 23:41:19 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04327 for ; Thu, 24 Feb 2005 23:41:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4XDO-0000kw-HK for idn-data@psg.com; Fri, 25 Feb 2005 04:36:34 +0000 Received: from [68.168.78.205] (helo=mta11.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4XDM-0000kg-Oq for idn@ops.ietf.org; Fri, 25 Feb 2005 04:36:32 +0000 Received: from DEWELL ([68.66.2.217]) by mta11.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050225043631.QNFD5532.mta11.adelphia.net@DEWELL>; Thu, 24 Feb 2005 23:36:31 -0500 Message-ID: <00a401c51af3$7863aae0$030aa8c0@DEWELL> From: "Doug Ewell" To: Cc: "Erik van der Poel" References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> Subject: Re: [idn] process Date: Thu, 24 Feb 2005 20:35:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > 1. Is this the right time to start working on Internet Drafts leading > up to new version(s) of the IDNA RFC(s)? If not, when? > ... I don't know about anyone else, but something seems badly wrong here. Is it really possible that we spent a year and a half, two years on putting together an IDN architecture, and during all that time nobody ever gave the slightest thought to the possibility of someone using IDNs for spoofing purposes, and now that one or two well-publicized spoofing examples have appeared, we are ready to start all over again with a new and probably incompatible version of the architecture? Is this sending the kind of "stability" message that was considered so important two or three years ago? Is there even enough solid information to begin writing anything, or just a general feeling that Something Needs To Be Done? -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Fri Feb 25 06:50:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03985 for ; Fri, 25 Feb 2005 06:50:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4drc-0005GC-0z for idn-data@psg.com; Fri, 25 Feb 2005 11:42:32 +0000 Received: from [192.134.4.10] (helo=mx1.nic.fr) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4drY-0005Fi-M6 for idn@ops.ietf.org; Fri, 25 Feb 2005 11:42:28 +0000 Received: from localhost (unknown [127.0.0.1]) by mx1.nic.fr (Postfix) with ESMTP id B272394008; Fri, 25 Feb 2005 12:42:27 +0100 (CET) Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by mx1.nic.fr (Postfix) with ESMTP id 83E4494005; Fri, 25 Feb 2005 12:42:26 +0100 (CET) Received: from batilda.nic.fr (postfix@batilda.nic.fr [192.134.4.69]) by maya20.nic.fr (8.12.4/8.12.4) with ESMTP id j1PBbQ4u1417997; Fri, 25 Feb 2005 12:37:26 +0100 (CET) Received: by batilda.nic.fr (Postfix, from userid 1000) id F3CB416A980; Fri, 25 Feb 2005 12:37:25 +0100 (CET) Date: Fri, 25 Feb 2005 12:37:25 +0100 From: Stephane Bortzmeyer To: Doug Ewell Cc: idn@ops.ietf.org, Erik van der Poel Subject: [idn] Re: process Message-ID: <20050225113725.GA8820@nic.fr> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a401c51af3$7863aae0$030aa8c0@DEWELL> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new at mx1.nic.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On Thu, Feb 24, 2005 at 08:35:43PM -0800, Doug Ewell wrote a message of 26 lines which said: > Is it really possible that we spent a year and a half, two years on > putting together an IDN architecture, and during all that time > nobody ever gave the slightest thought to the possibility of someone > using IDNs for spoofing purposes, This is absolutely wrong. The issue has been discussed at length. See the "Security Considerations" of RFC 3490. > and now that one or two well-publicized spoofing examples have > appeared, Pure marketing, BTW. Nothing new in the recent announces, just sensation papers. > Is there even enough solid information to begin writing anything, or > just a general feeling that Something Needs To Be Done? The Powers Above require that Something should be done (they will forget about it in a few weeks) but, technically speaking, there is indeed nothing now. From owner-idn@ops.ietf.org Fri Feb 25 10:53:02 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02247 for ; Fri, 25 Feb 2005 10:53:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4hfF-000CSv-4t for idn-data@psg.com; Fri, 25 Feb 2005 15:46:01 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4hfB-000CSR-Q8 for idn@ops.ietf.org; Fri, 25 Feb 2005 15:45:58 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1PFjmHb195030; Fri, 25 Feb 2005 10:45:53 -0500 Message-ID: <421F482B.1060909@vanderpoel.org> Date: Fri, 25 Feb 2005 07:45:47 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephane Bortzmeyer CC: Doug Ewell , idn@ops.ietf.org Subject: Re: [idn] Re: process References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> In-Reply-To: <20050225113725.GA8820@nic.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: > The issue has been discussed at length. See > the "Security Considerations" of RFC 3490. It is true that some of the issues are pointed out by that section, so the registries and application developers have to pay attention. But one might argue that we have recently been discussing a new *class* of homographs. The RFC mentions "multiple scripts" and one and l. These two refer to letters such as Cyrillic small 'a' and digits (the "one"). But the slash homograph recently raised on this list might be considered to be a new class of homograph (punctuation), not specifically indicated in the RFC. Not only is this type of character different from letters and digits, it is arguably even more dangerous than the script-based (Cyrillic) attack, since it can be done in a domain label that is not under the control of the registries. So that first line of defense is not there, and we must rely totally on the apps, and there are many. One could argue that a new document should be published and widely circulated to warn about this new kind of attack. One of my questions is whether this warning should appear in a new version of the RFC, or in a separate document. Alternatively, it may be decided that this type of homograph is so different and so dangerous that a new version of the protocol that prohibits these characters, with a new ACE prefix, should be created. I don't know. Also, the "multiple scripts" wording does not specifically cover the all-Cyrillic case. So that part could be tightened up too. By the way, the RFC's Security section includes the following: No security issues such as string length increases or new allowed values are introduced by the encoding process or the use of these encoded values, apart from those introduced by the ACE encoding itself. What does this mean, exactly? Are any new allowed values introduced by the ACE encoding? This part could be clearer. Also, O and 0 are mentioned, but is this technically correct? I mean, aren't uppercase ASCIIs supposed to be lowercased? I'm sorry if I'm wrong about this part. > Nothing new in the recent announces, just > sensation papers. Again, I think the slash homograph might be new. Do you have evidence to suggest that it *was* considered by the WG or anybody else? > The Powers Above require that Something should be done Have you seen any indication of this? Thanks, Erik From owner-idn@ops.ietf.org Fri Feb 25 11:56:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07566 for ; Fri, 25 Feb 2005 11:56:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4ig2-000Mb5-CF for idn-data@psg.com; Fri, 25 Feb 2005 16:50:54 +0000 Received: from [61.215.206.254] (helo=vbn.inter-touch.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4ifz-000Mae-IK for idn@ops.ietf.org; Fri, 25 Feb 2005 16:50:51 +0000 Received: from [219.101.164.151] (unknown [219.101.164.151]) by vbn.inter-touch.net (Postfix) with ESMTP id 433CC40033E; Sat, 26 Feb 2005 01:50:41 +0900 (JST) In-Reply-To: <421F482B.1060909@vanderpoel.org> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> <421F482B.1060909@vanderpoel.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2b4b22d85b2872558414c64071e7b993@seng.cc> Content-Transfer-Encoding: 7bit Cc: idn@ops.ietf.org, Stephane Bortzmeyer , Doug Ewell From: James Seng Subject: Re: [idn] Re: process Date: Sat, 26 Feb 2005 00:50:44 +0800 To: Erik van der Poel X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit FYI, punctuation were also debated extensively back then so it isn't really 'Oh, we just discover this!'. It's just interesting to see people putting it into action. Does apps needs to be fixed? Yes, absolutely. App developers needs to go read the security consideration of rfc3490 and think about how to implement some solution to reduce the spoofing risk. but does it warrant changing the existing rfc? I dunno..I havent seen anything that suggest we missed something back then. -James Seng On 25-Feb-05, at PM 11:45, Erik van der Poel wrote: > Stephane Bortzmeyer wrote: >> The issue has been discussed at length. See >> the "Security Considerations" of RFC 3490. > > It is true that some of the issues are pointed out by that section, so > the registries and application developers have to pay attention. But > one might argue that we have recently been discussing a new *class* > of homographs. The RFC mentions "multiple scripts" and one and l. > These two refer to letters such as Cyrillic small 'a' and digits (the > "one"). But the slash homograph recently raised on this list might be > considered to be a new class of homograph (punctuation), not > specifically indicated in the RFC. Not only is this type of character > different from letters and digits, it is arguably even more dangerous > than the script-based (Cyrillic) attack, since it can be done in a > domain label that is not under the control of the registries. So that > first line of defense is not there, and we must rely totally on the > apps, and there are many. > > One could argue that a new document should be published and widely > circulated to warn about this new kind of attack. One of my questions > is whether this warning should appear in a new version of the RFC, or > in a separate document. Alternatively, it may be decided that this > type of homograph is so different and so dangerous that a new version > of the protocol that prohibits these characters, with a new ACE > prefix, should be created. I don't know. > > Also, the "multiple scripts" wording does not specifically cover the > all-Cyrillic case. So that part could be tightened up too. > > By the way, the RFC's Security section includes the following: > > No security issues such as string length increases or new > allowed values are introduced by the encoding process or the use of > these encoded values, apart from those introduced by the ACE > encoding > itself. > > What does this mean, exactly? Are any new allowed values introduced by > the ACE encoding? This part could be clearer. > > Also, O and 0 are mentioned, but is this technically correct? I mean, > aren't uppercase ASCIIs supposed to be lowercased? I'm sorry if I'm > wrong about this part. > >> Nothing new in the recent announces, just >> sensation papers. > > Again, I think the slash homograph might be new. Do you have evidence > to suggest that it *was* considered by the WG or anybody else? > >> The Powers Above require that Something should be done > > Have you seen any indication of this? > > Thanks, > > Erik > From owner-idn@ops.ietf.org Fri Feb 25 12:02:06 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07990 for ; Fri, 25 Feb 2005 12:02:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4ilr-000NVq-SD for idn-data@psg.com; Fri, 25 Feb 2005 16:56:55 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4ilr-000NVc-3E for idn@ops.ietf.org; Fri, 25 Feb 2005 16:56:55 +0000 Received: from [10.0.0.17] ([65.241.178.4]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGurfC091133; Fri, 25 Feb 2005 08:56:54 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <421EA0C9.1010500@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> Date: Fri, 25 Feb 2005 08:56:09 -0800 To: Erik van der Poel , idn@ops.ietf.org From: Paul Hoffman Subject: Re: [idn] process Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 7:51 PM -0800 2/24/05, Erik van der Poel wrote: >1. Is this the right time to start working on Internet Drafts >leading up to new version(s) of the IDNA RFC(s)? If not, when? That's your call. There is certainly no one stopping you (but, as far as I can tell, very few people encouraging you either). >2. Am I stepping on someone's toes by creating nameprep.org? Feel >free to respond publicly or privately. You are only stepping on toes if you try to pass it off as something official, and so far you haven't at all. It certainly looks like a useful service to me. >4. Do we need to revive the IDN WG? No. Individuals can submit proposals to update or replace standards without a WG. The IESG will probably expect proof that there is community support for a change to an existing, widely-deployed standard. If you can show that and write a good revision to the standard, no WG is needed. In the current case, trying to start up the IDN WG is probably a bad idea, given the history of the previous WG. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Fri Feb 25 12:11:38 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08792 for ; Fri, 25 Feb 2005 12:11:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4iwZ-000PiZ-JV for idn-data@psg.com; Fri, 25 Feb 2005 17:07:59 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4iwY-000PiF-6t for idn@ops.ietf.org; Fri, 25 Feb 2005 17:07:58 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id j1PH7qb1055250; Fri, 25 Feb 2005 18:07:52 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200502251707.j1PH7qb1055250@bartok.nlnetlabs.nl> To: Erik van der Poel cc: Stephane Bortzmeyer , Doug Ewell , idn@ops.ietf.org Subject: Re: [idn] Re: process In-reply-to: Your message of Fri, 25 Feb 2005 07:45:47 -0800. <421F482B.1060909@vanderpoel.org> Date: Fri, 25 Feb 2005 18:07:52 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Also, the "multiple scripts" wording does not specifically cover the all-Cyrillic case. So that part could be tightened up too. The all cyrillic case is quite known by a lot of people. I seem to remember court case about it dating back to even before IDNS was discussed. Security sections are not necessarily describing all corner cases. Also, O and 0 are mentioned, but is this technically correct? I mean, aren't uppercase ASCIIs supposed to be lowercased? When the input to the encoding is consists of ASCII in the set LDH, it wil be left untouched. For DNS is deosn't matter (case insensitive), but the case should be preserved when possible. Only when the label contains LDH, the ASCII is lower cased. jaap From owner-idn@ops.ietf.org Fri Feb 25 12:18:44 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09733 for ; Fri, 25 Feb 2005 12:18:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4j3F-0000ay-Ju for idn-data@psg.com; Fri, 25 Feb 2005 17:14:53 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4j3E-0000af-3x for idn@ops.ietf.org; Fri, 25 Feb 2005 17:14:52 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1PHEepY359948; Fri, 25 Feb 2005 12:14:40 -0500 Message-ID: <421F5CFA.5020903@vanderpoel.org> Date: Fri, 25 Feb 2005 09:14:34 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Seng CC: idn@ops.ietf.org, Stephane Bortzmeyer , Doug Ewell Subject: Re: [idn] Re: process References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> <421F482B.1060909@vanderpoel.org> <2b4b22d85b2872558414c64071e7b993@seng.cc> In-Reply-To: <2b4b22d85b2872558414c64071e7b993@seng.cc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit James Seng wrote: > FYI, punctuation were also debated extensively back then so it isn't > really 'Oh, we just discover this!'. > > It's just interesting to see people putting it into action. Does apps > needs to be fixed? Yes, absolutely. App developers needs to go read the > security consideration of rfc3490 and think about how to implement some > solution to reduce the spoofing risk. > > but does it warrant changing the existing rfc? I dunno..I havent seen > anything that suggest we missed something back then. That's a pretty cavalier attitude for someone who used to be co-chair of an IETF Working Group. http://ietf.org/html.charters/OLD/idn-charter.html Maybe I should write an Informational RFC titled "IDN Considered Harmful". Would that catch your attention? Erik PS Re: RFC 3490 Security Considerations, please tell me exactly where punctuation is specifically mentioned. From owner-idn@ops.ietf.org Fri Feb 25 12:32:30 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10853 for ; Fri, 25 Feb 2005 12:32:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4jGA-0002Tp-33 for idn-data@psg.com; Fri, 25 Feb 2005 17:28:14 +0000 Received: from [213.154.224.50] (helo=bartok.nlnetlabs.nl) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4jG8-0002Ta-Uy for idn@ops.ietf.org; Fri, 25 Feb 2005 17:28:13 +0000 Received: from bartok.nlnetlabs.nl (localhost.nlnetlabs.nl [127.0.0.1]) by bartok.nlnetlabs.nl (8.13.1/8.13.1) with ESMTP id j1PHSADA055533; Fri, 25 Feb 2005 18:28:10 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <200502251728.j1PHSADA055533@bartok.nlnetlabs.nl> cc: Erik van der Poel , Stephane Bortzmeyer , Doug Ewell , idn@ops.ietf.org Subject: Re: [idn] Re: process In-reply-to: Your message of Fri, 25 Feb 2005 18:07:52 +0100. <200502251707.j1PH7qb1055250@bartok.nlnetlabs.nl> Date: Fri, 25 Feb 2005 18:28:10 +0100 From: Jaap Akkerhuis X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,MISSING_HEADERS autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Oops, When the input to the encoding is consists of ASCII in the set LDH, it wil be left untouched. For DNS is deosn't matter (case insensitive), but the case should be preserved when possible. Only when the label contains LDH, the ASCII is lower cased. s/contains LDH/contains other characters then just LDH/ jaap From owner-idn@ops.ietf.org Fri Feb 25 12:34:09 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11107 for ; Fri, 25 Feb 2005 12:34:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4jI7-0002pf-5Y for idn-data@psg.com; Fri, 25 Feb 2005 17:30:15 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4jI4-0002pM-4c for idn@ops.ietf.org; Fri, 25 Feb 2005 17:30:12 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D4jI2-0002sx-Us; Fri, 25 Feb 2005 12:30:11 -0500 Date: Fri, 25 Feb 2005 12:29:58 -0500 From: John C Klensin To: Doug Ewell , idn@ops.ietf.org cc: Erik van der Poel Subject: Re: [idn] process Message-ID: In-Reply-To: <00a401c51af3$7863aae0$030aa8c0@DEWELL> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Thursday, 24 February, 2005 20:35 -0800 Doug Ewell wrote: > Erik van der Poel wrote: > >> 1. Is this the right time to start working on Internet Drafts >> leading up to new version(s) of the IDNA RFC(s)? If not, when? >> ... > > I don't know about anyone else, but something seems badly > wrong here. > > Is it really possible that we spent a year and a half, two > years on putting together an IDN architecture, and during all > that time nobody ever gave the slightest thought to the > possibility of someone using IDNs for spoofing purposes, and > now that one or two well-publicized spoofing examples have > appeared, we are ready to start all over again with a new and > probably incompatible version of the architecture? I certainly hope not. And certainly we knew about these issues. Even the potential problem with symbols and box-drawing characters was identified, although not in the lurid detail of some of the recent example. There was discussion around the WG about what to do about those issues, and how completely to describe them. I think the consensus at that time was to not write a lot of these issues up in detail for fear of discouraging IDNA implementations. That consensus was, IMO, reached in a WG in which many of the participants were, for various reasons, just anxious to get finished and not paying much attention to the finer details. While I advocated at least one radically different architecture while the IDN WG work was going on, I think, personally, that looking at a new and incompatible architecture would be pretty close to insane. As I tried to explain in my remarks on Erik's proposal that we reverse the presentation order of domain names, I just don't think it is possible to go there. And, even if we wanted to, there is no reason to believe that any other architecture would work better: these homograph problems are the inevitable consequence of the relationships among the scripts themselves: it is unlikely that even dumping Unicode and switching to something else would help very much. And there isn't any "something else". However, the decision to adopt two philosophical principles, and one strong assumption, went into the design of IDNA and its supporting tables. The assumption has not turned out to be completely valid and we may need to look harder at the implications of its failure. I suggest that either or both of the philosophical principles could be reviewed and, if necessary, changed in the light of experience and that neither change would be fatal to IDNs or IDNA, or even especially disruptive if not fairly soon. This is _not_ a suggestion that those changes should be made, only that it would be plausible for us to review the decisions and reach some conclusions about whether they are still appropriate in the light of experience. I hope that those who wrote the IDNA specs will agree with the statement of those principles I'm about to make, or at least that they are close... they may not. (1) To the extent possible, we should accommodate all Unicode characters, excluding as little as possible. This position was reinforced by the view that, at the time, the Unicode classifications of characters were considered a little soft and a general conviction that the IETF should not be making character-by-character decisions. A counter-principle, now if not then, is that we should permit a relatively narrow extension of the "letter-digit-hyphen" rule, i.e., permitting, only letters (in any alphabet or script), perhaps local digits, and the hyphen, but no other punctuation, symbols, drawing characters, or other non-letter characters. Adam has argued for that revised principle recently; several people argued for it when IDNA was being produced. We could probably still impose it, and, in any event, it would not require a change in the basic architecture (see below). (2) When code points had been identified by UTC as the same as, or equivalent to, others, we tended to map them together, rather than picking one and prohibiting the others. This has caused more problems than most of us expected, with people being surprised when they register or query using one character and the result that comes back uses another. It also creates a near-homograph problem that we haven't "discovered" in the last couple of weeks: If we have character X mapping to character Y, but X looks vaguely like Z, then there may be no Y-Z homograph, but there may be an X-Z one. That could make display decisions, etc., quite critical and, unless applications got it entirely right, we might end up with a new family of attacks. Again, that decision could be reviewed. Perhaps there are groups of characters that should be prohibited from being included in a lookup or registration operation, not just mapped to something more reasonable. And, again, this would be a tuning of tables, not a change in the basis architecture. The assumption I referred to above was that ICANN would take a strong role in determining which characters were really appropriate for registration and under what circumstances, that they would institute and enforce appropriate rules, and that everyone relevant would pay attention to whatever they said. Every element of that assumption has turned out to be false: they haven't taken that role; their guidelines are weak, ambiguous, and at least partially wrong; and some registries have just ignored the rules that do exist without any penalty. If there is a problem, either we are going to need to solve it, or we are going to risk different solutions in different applications that, taken together, compromise interoperability. > Is this sending the kind of "stability" message that was > considered so important two or three years ago? It is sending the "get it right and get it interoperable" message that is supposed to dominate IETF decision-making, especially with Proposed Standards. > Is there even enough solid information to begin writing > anything, or just a general feeling that Something Needs To Be > Done? I think it is time for us to ask the questions that are suggested above, and to ask them explicitly. If doing so produces the answer that it is time to make changes --table changes, not architectural changes-- I think we should do so. Perhaps we could combine that table review process with an upgrade to Unicode 4.x, which would accommodate several scripts we can't handle today. Could this be done compatibly? Not quite. For starters, we would have to address more squarely the question that the first principle identified above bypassed: does someone have the _right_ to register a particular sequence of Unicode characters? If the answer is that, because I can draw out a symbol that represents my business, or my religion, or my location, then I have the "right" to register it, then we are in trouble: someone out there will organize the Church of the Holy Right-Slash and prohibiting it will discriminate against that religion, especially if left-slashes and vertical bars are permitted. If we can get past "right to register", we need to look at the experience of the browser implementers who have already concluded that, registered or not, they really don't want to recognize or process domain names containing such characters. And then we need to present the transition problem of eliminating any such domains that may exist to ICANN and say "you were unable or ineffective at preventing these problems from occurring, so, as a prize, you get to figure out how to retire those names and are now prohibited by the updated standard". Curiously, if we followed existing precedents, we could even more IDNA from Proposed to Draft and change the tables to eliminate many mappings and characters: no change to the algorithm, just elimination of some features that didn't work in practice. That is not a proposal, just an observation :-) john From owner-idn@ops.ietf.org Fri Feb 25 12:36:29 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11366 for ; Fri, 25 Feb 2005 12:36:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4jLI-0003MI-RT for idn-data@psg.com; Fri, 25 Feb 2005 17:33:32 +0000 Received: from [61.215.206.254] (helo=vbn.inter-touch.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4jLH-0003Lt-S2 for idn@ops.ietf.org; Fri, 25 Feb 2005 17:33:32 +0000 Received: from [219.101.164.151] (unknown [219.101.164.151]) by vbn.inter-touch.net (Postfix) with ESMTP id 25E08409484; Sat, 26 Feb 2005 02:33:27 +0900 (JST) In-Reply-To: <421F5CFA.5020903@vanderpoel.org> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> <421F482B.1060909@vanderpoel.org> <2b4b22d85b2872558414c64071e7b993@seng.cc> <421F5CFA.5020903@vanderpoel.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: idn@ops.ietf.org, Stephane Bortzmeyer , Doug Ewell From: James Seng Subject: Re: [idn] Re: process Date: Sat, 26 Feb 2005 01:33:30 +0800 To: Erik van der Poel X-Mailer: Apple Mail (2.619.2) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik, > That's a pretty cavalier attitude for someone who used to be co-chair > of an IETF Working Group. Please focus on my logic of my explanation instead of paying attention to who I am or who I was. Whats wrong with my explanation? > Maybe I should write an Informational RFC titled "IDN Considered > Harmful". Would that catch your attention? You should write what you think, and stop writing what will catch my (or others) attention. Perhaps that would be most constructive for all. > PS Re: RFC 3490 Security Considerations, please tell me exactly where > punctuation is specifically mentioned. I said it was discussed in the wg before. Lots of the discussion wasn't recorded into the RFC. Please go thru the archive and you find at least 2 threads discussing it. Its 2:32am for me now so I am heading to bed so sorry I cant post any URLs you right now. -James Seng From owner-idn@ops.ietf.org Fri Feb 25 17:32:03 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09539 for ; Fri, 25 Feb 2005 17:32:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4nrv-000GHC-PB for idn-data@psg.com; Fri, 25 Feb 2005 22:23:31 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4nru-000GGy-52 for idn@ops.ietf.org; Fri, 25 Feb 2005 22:23:30 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1PMNOHb145020; Fri, 25 Feb 2005 17:23:25 -0500 Message-ID: <421FA55B.9000308@vanderpoel.org> Date: Fri, 25 Feb 2005 14:23:23 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: Doug Ewell , idn@ops.ietf.org Subject: Re: [idn] process References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, Thank you for taking the time to write such a well-thought-out response. I agree with some of the points you make, but I'm going to present arguments against the others. I'm currently leaning towards *not* changing IDNA (other than to fix mistakes and clarify some sections). John C Klensin wrote: > > (1) To the extent possible, we should accommodate all Unicode > characters, excluding as little as possible. This position was > reinforced by the view that, at the time, the Unicode > classifications of characters were considered a little soft and > a general conviction that the IETF should not be making > character-by-character decisions. A counter-principle, now if > not then, is that we should permit a relatively narrow extension > of the "letter-digit-hyphen" rule, i.e., permitting, only > letters (in any alphabet or script), perhaps local digits, and > the hyphen, but no other punctuation, symbols, drawing > characters, or other non-letter characters. Adam has argued for > that revised principle recently; several people argued for it > when IDNA was being produced. We could probably still impose > it, and, in any event, it would not require a change in the > basic architecture (see below). I believe it would be difficult to reach consensus on a relatively narrow extension of the LDH rule. Just for starters, the hyphen used to separate names and other strings in the Western world is not used in Japan for Katakana, because Katakana uses a middle dot (U+30FB) to separate 2 Katakana strings. In fact, this character is allowed in .jp. If we do *not* allow these special local characters that function in the same way as the hyphen in the West, then people in other parts of the world would not only claim that our spec is unfair, they might even ignore it. If we *do* allow this Japanese example, then we have started sliding down a slippery slope that ends with a rather large extension of the LDH rule (for the rest of the world), and then the phishing problem would not be alleviated as much as we might have hoped when we started with just LDH. This would be a lot of work for little gain. So it's a lose-lose situation. Instead, we should probably stick to IDNA's original principle of allowing a lot of Unicode, and have the local registries, zone administrators and apps address the phishing problem. > (2) When code points had been identified by UTC as the same as, > or equivalent to, others, we tended to map them together, rather > than picking one and prohibiting the others. This has caused > more problems than most of us expected, with people being > surprised when they register or query using one character and > the result that comes back uses another. It also creates a > near-homograph problem that we haven't "discovered" in the last > couple of weeks: If we have character X mapping to character Y, > but X looks vaguely like Z, then there may be no Y-Z homograph, > but there may be an X-Z one. That could make display decisions, > etc., quite critical and, unless applications got it entirely > right, we might end up with a new family of attacks. Again, > that decision could be reviewed. Perhaps there are groups of > characters that should be prohibited from being included in a > lookup or registration operation, not just mapped to something > more reasonable. And, again, this would be a tuning of tables, > not a change in the basis architecture. It may be possible to "tune" the tables, but nowhere in your email do I find any reference to the ACE prefix. I think that we should also figure out exactly which types of changes would absolutely require a new ACE prefix, and then explore in detail what all the affected parties would have to do to add a new prefix to the mix or to transition to it. The parties I'm thinking of are app developers and registries, mostly, but content developers might also be affected. > The assumption I referred to above was that ICANN would take a > strong role in determining which characters were really > appropriate for registration and under what circumstances, that > they would institute and enforce appropriate rules, and that > everyone relevant would pay attention to whatever they said. > Every element of that assumption has turned out to be false: > they haven't taken that role; their guidelines are weak, > ambiguous, and at least partially wrong; and some registries > have just ignored the rules that do exist without any penalty. > If there is a problem, either we are going to need to solve it, > or we are going to risk different solutions in different > applications that, taken together, compromise interoperability. I'm currently thinking that we (IETF) can't really solve these problems, and that the registries and apps are going to have to address them. But I strongly sympathize with your stated concern about differing solutions leading to interoperability problems, and so I think "we" (not IETF) must come up with much better registry guidelines and even recommendations and proposals for the apps. Such documents would not necessarily be IETF documents, though they could be if they are merely informational (not standards track). Other organizations like ICANN could then take some of that and fold it into their own doc, but they would probably make some of it normative (or MUST). There isn't really a single organization for the apps (W3C doesn't cover all), so an IETF informational RFC might be good for them. > If > we can get past "right to register", we need to look at the > experience of the browser implementers who have already > concluded that, registered or not, they really don't want to > recognize or process domain names containing such characters. Some of these implementors might decide to disable IDNA labels under some circumstances, but the existence of a number of IDN plug-ins for MSIE and the extensibility of Mozilla and the need for IDNs around the world suggest that their decisions may be circumvented. Eventually, these implementors may decide to improve their own IDN support. I realize that the short-term decisions may be bad for IDN, but I am hopeful for the future. Erik From owner-idn@ops.ietf.org Fri Feb 25 20:13:34 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21650 for ; Fri, 25 Feb 2005 20:13:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4qQu-000CYC-A7 for idn-data@psg.com; Sat, 26 Feb 2005 01:07:48 +0000 Received: from [207.115.63.101] (helo=pimout2-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4qQr-000CXr-Rd for idn@ops.ietf.org; Sat, 26 Feb 2005 01:07:46 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout2-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1Q17auq070134; Fri, 25 Feb 2005 20:07:40 -0500 Message-ID: <421FCBD7.8000805@vanderpoel.org> Date: Fri, 25 Feb 2005 17:07:35 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: idn@ops.ietf.org Subject: Re: [idn] process References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> In-Reply-To: <421FA55B.9000308@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > If we do *not* allow these special local characters that function in the > same way as the hyphen in the West, then people in other parts of the > world would not only claim that our spec is unfair, they might even > ignore it. If we *do* allow this Japanese example, then we have started > sliding down a slippery slope that ends with a rather large extension of > the LDH rule (for the rest of the world), and then the phishing problem > would not be alleviated as much as we might have hoped when we started > with just LDH. This would be a lot of work for little gain. > > So it's a lose-lose situation. Sorry, I said that wrong. What I meant was, "Damned if you do, damned if you don't." However, one avenue that might be worth exploring some more is to check each registry's character table (for those that have one) and see what the Unicode category is for each character. The Japanese Katakana middle dot U+30FB has the category "Pc" which means "punctuation, connector" and LDH's hyphen U+002D has the category "Pd" which means "punctuation, dash". http://www.unicode.org/Public/UNIDATA/UnicodeData.txt http://www.unicode.org/Public/UNIDATA/UCD.html#General_Category_Values http://vanderpoel.org/networking/i/idn.html (see bottom) If it turns out that all or most of the registries that have tables are using characters with only a small number of Unicode categories, then we may wish to consider moving IDNA to that set of categories (disallowing all others). This would keep the registries happy while keeping *some* of the phishy characters out of DNS. Erik From owner-idn@ops.ietf.org Fri Feb 25 20:23:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22151 for ; Fri, 25 Feb 2005 20:23:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4qd1-000E6S-JL for idn-data@psg.com; Sat, 26 Feb 2005 01:20:19 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4qcz-000E5x-U1 for idn@ops.ietf.org; Sat, 26 Feb 2005 01:20:18 +0000 Received: from lns-p19-1-idf-82-251-82-92.adsl.proxad.net ([82.251.82.92] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D4qcy-0001w8-BS; Fri, 25 Feb 2005 17:20:17 -0800 Message-Id: <6.1.2.0.2.20050225185646.030e9900@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 26 Feb 2005 02:20:06 +0100 To: Erik van der Poel , idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: Re: [idn] process In-Reply-To: <421EA0C9.1010500@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik, I will try to respond that with caution. Based upon real world situation. Trying not to hurt anyone. At 04:51 25/02/2005, Erik van der Poel wrote: >1. Is this the right time to start working on Internet Drafts leading up >to new version(s) of the IDNA RFC(s)? If not, when? The IDNA solution as well described by John Klensin, has IMHO low chances to commercially take off. I suppose it will progressively be replaced by different grassroots solutions in non-Latin countries at lease, as this has started. Due to this progressive evolution, we may suppose these solutions will still use punycode, so the experience acquired will remain of real interest. nameprep.org is OK. I may be wrong but the solution will most probably be based on simple principles: - respect of the DNS. Either with lingual TLD (extension of the root or PAD [private alias directory]) or with .lingual_sld.tld and conversion. - language homogeneity for the whole URL - reduced number of authorized characters as decided by the TLD/PAD Manager. This will probably supported by local ISPs and by plug in (lingual names are probably to be of different usage, much more like DNs were used in the sole USA in 1984). The "plug in functions" will probably be extended and made part of the OS once stabilized. This will result from a grassroots effort, documented further on as RFCs for information. So there is no need for a WG no one wants to reopen, for ICANN which has no impact (2 mails on the ICANN IDNA mailing list in one year), etc. but for relations with TLDs, Govs, Users Reps, Cultural organizations. >2. Am I stepping on someone's toes by creating nameprep.org? Feel free to >respond publicly or privately. Certainly not. You may accumulate an experience which will be precious to everyone. But understand no one is really happy with the IDNA. The imposed terms by "Powers Above" were unworkable. There has been a lot of efforts.Everyone tried his best. There is still the IRI to fully understand. There is e-mail to support. There are the babel names. There are the PADs to come. >3. If this is the right time to start work on drafts, who would like to >write some prose? Frankly I think this time it should be carried the other way around. To understand the real world. Then to put a solution together. To test it. Then once it starts working to document for information. But in the meanwhile we should do everything to keep a good image to IDNs. I do think that a multicolored URI support Draft could help in providing a way out from the current concern, and restoring credibility give a credibility to a new team. >4. Do we need to revive the IDN WG? Certainly not! Then what else? There are different point of views. Mine is that the real need is to consider the whole matter of the multilingual internet. Once the framework has been clearly understood, ML.ML DNs will be far easier to understand and discuss. But the IETF/IAB is obviously not interested (yet?). As RFC 3869 shows it. I had started writing a Draft on Multilingual Internet. My idea was to document how the existing Internet standard process can document the Multilingual Internet. The idea was to use RFC 3066 and the work of Paul Hoffman as a basis, adding a mutilingual considerations part in every RFC (like the security consideration, cf. RFC 3066), to extend the concepts in extending and structuring Paul Hoffman"s definitions lists, and to build an MLTF as there is a TFIPv6. To gather the concerned people and organizations. Its purpose would be to share into the standard process comment period, to help a culture to develop. The first thing was to document questions for an IAB guidance over the architectural aspects called by a MI. The recent saga of the RFC 3066 bis shown there is still work ahead before this can be considered. Your initiative could help to prepare the ground. >5. Any other process questions? Why not to work on practical functions and on real tools testing? You have seemingly good developer skills, we could help? jfc From owner-idn@ops.ietf.org Sat Feb 26 02:14:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29685 for ; Sat, 26 Feb 2005 02:14:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4w2E-0008gN-HF for idn-data@psg.com; Sat, 26 Feb 2005 07:06:42 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4w2C-0008ei-Eb for idn@ops.ietf.org; Sat, 26 Feb 2005 07:06:40 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D4w2B-0004aw-00 for ; Fri, 25 Feb 2005 23:06:39 -0800 Date: Sat, 26 Feb 2005 07:06:39 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] Re: process Message-ID: <20050226070639.GC14956~@nicemice.net> Reply-To: IETF idn working group References: <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050225113725.GA8820@nic.fr> <421F482B.1060909@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502251728.j1PHSADA055533@bartok.nlnetlabs.nl> <200502251707.j1PH7qb1055250@bartok.nlnetlabs.nl> <421F482B.1060909@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > Stephane Bortzmeyer wrote: > > >The issue has been discussed at length. See the "Security > >Considerations" of RFC 3490. > > It is true that some of the issues are pointed out by that section, so > the registries and application developers have to pay attention. But > one might argue that we have recently been discussing a new *class* > of homographs. The RFC mentions "multiple scripts" and one and l. > These two refer to letters such as Cyrillic small 'a' and digits > (the "one"). But the slash homograph recently raised on this list > might be considered to be a new class of homograph (punctuation), not > specifically indicated in the RFC. Not only is this type of character > different from letters and digits, it is arguably even more dangerous > than the script-based (Cyrillic) attack, since it can be done in a > domain label that is not under the control of the registries. We knew that punctuation could be hazardous, and we expected that it would be severely restricted by the registries. I don't think we understood that punctuation could be used to spoof top-level domains even if every top-level registry prohibited punctuation. As for application implementors, we made no attempt to mention every kind of hazard we had thought of; we just wanted to give a motivating example to start them thinking about what safeguards would be appropriate for their applications. Maybe the emerging UTR#36 will become the canonical reference for spoofing hazards, in which case any revision of the IDNA spec should certainly cite it. > No security issues such as string length increases or new allowed > values are introduced by the encoding process or the use of these > encoded values, apart from those introduced by the ACE encoding > itself. > > What does this mean, exactly? Are any new allowed values introduced > by the ACE encoding? This part could be clearer. It might mean that IDNA does not introduce any new ASCII domain names, it only introduces new non-ASCII domain names. In any case, that's true. > Also, O and 0 are mentioned, but is this technically correct? I mean, > aren't uppercase ASCIIs supposed to be lowercased? Nameprep (which includes case-folding) is used for encoding and comparing domain names, not for displaying them. At least, IDNA makes no suggestion that Nameprep be used for displaying domain names. If an IRI contains a mixed-case non-ASCII domain name, IDNA suggests applying ToUnicode to each domain label, which will internally use Nameprep before looking for the ACE prefix, but then, not finding the ACE prefix, it will return the original un-Nameprep'd input for display. The draft UTR#36, unlike the IDNA spec, recommends using Nameprep for displayed domain names, to simplify detection of confusable names. AMC From owner-idn@ops.ietf.org Sat Feb 26 02:24:28 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07327 for ; Sat, 26 Feb 2005 02:24:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4wEy-000At7-II for idn-data@psg.com; Sat, 26 Feb 2005 07:19:52 +0000 Received: from [207.115.63.98] (helo=pimout4-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4wEv-000Ast-C1 for idn@ops.ietf.org; Sat, 26 Feb 2005 07:19:49 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout4-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1Q7JiHb193694; Sat, 26 Feb 2005 02:19:45 -0500 Message-ID: <42202310.7080301@vanderpoel.org> Date: Fri, 25 Feb 2005 23:19:44 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: idn@ops.ietf.org Subject: [idn] related work References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <6.1.2.0.2.20050225185646.030e9900@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050225185646.030e9900@mail.jefsey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, Recently, we have been talking about creating a number of new documents. In order to avoid overlap with other documents, I thought it might be nice to have a list of related work, so I started a new section: http://nameprep.org/#related-work In particular, the Unicode Security document and John Klensin's registration guidelines are very relevant to our discussions. If you would like to add items to the list, please send them to me. Thanks, Erik From owner-idn@ops.ietf.org Sat Feb 26 03:23:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10731 for ; Sat, 26 Feb 2005 03:23:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D4xAV-000JiU-BL for idn-data@psg.com; Sat, 26 Feb 2005 08:19:19 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D4xAS-000Ji9-2Q for idn@ops.ietf.org; Sat, 26 Feb 2005 08:19:16 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D4xAP-0004rB-00 for ; Sat, 26 Feb 2005 00:19:13 -0800 Date: Sat, 26 Feb 2005 08:19:13 +0000 From: "Adam M. Costello" To: idn@ops.ietf.org Subject: Re: [idn] process Message-ID: <20050226081913.GD14956~@nicemice.net> Reply-To: IETF idn working group References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <421FCBD7.8000805@vanderpoel.org> <421FA55B.9000308@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Doug Ewell wrote: > Is it really possible that we spent a year and a half, two years on > putting together an IDN architecture, and during all that time nobody > ever gave the slightest thought to the possibility of someone using > IDNs for spoofing purposes, No, it was thought about, and it was decided that the IDNA protocol was not the place to address those issues; that they should be addressed in registries and user interfaces. IDNA could have addressed the easier portion of the problem (prohibiting punctuation and symbols) (and for a while I was arguing for that), but it still would have left the harder part of the problem (dealing with script mixtures and homographs among letters) for the registries and user interfaces to deal with, so why not let them deal with the easier part too? (Of course, one could then ask why that argument doesn't apply to all the invisible characters that IDNA does prohibit. I have no good answer at the moment. Maybe invisibility was the only disqualifying attribute that everyone could agree on.) John C Klensin wrote: > I hope that those who wrote the IDNA specs will agree with the > statement of those principles I'm about to make, or at least that they > are close... they may not. > > (1) To the extent possible, we should accommodate all Unicode > characters, excluding as little as possible. That (or something very similar) was a principle that went into the IDNA spec. I personally was inclined to define both internationalized domain names and internationalized host names, where the former would be completely general (allowing *all* Unicode characters, even the invisible ones), and the latter would be much narrower (excluding most punctuation and symbols). This would be an analogy to traditional domain names (which allow all ASCII characters, even control characters) and traditional host names (which allow only the ASCII letters, digits, and one punctuation mark, the hyphen-minus). On the other hand, there was an argument that the traditional distinction between domain names and host names was the source of endless confusion and debate, and was a mistake that should not be repeated with IDNs. I have some sympathy for that argument. In any case, we ended up with just one set of non-ASCII characters for IDNs, between the two extremes: only invisible characters are excluded. (I think there's one exception--a visible space character that is also excluded). > (2) When code points had been identified by UTC as the same as, or > equivalent to, others, we tended to map them together, rather than > picking one and prohibiting the others. This was more than a tendency; it was strictly followed. > This has caused more problems than most of us expected, with people > being surprised when they register or query using one character and > the result that comes back uses another. I think this happens only for the case-folding mappings. The normalization mappings should not surprise anyone. > It also creates a near-homograph problem that we haven't "discovered" > in the last couple of weeks: If we have character X mapping to > character Y, but X looks vaguely like Z, then there may be no Y-Z > homograph, but there may be an X-Z one. True. And again, I think it's just the case-folding mappings that do this, not the normalization mappings. > Curiously, if we followed existing precedents, we could even move > IDNA from Proposed to Draft and change the tables to eliminate many > mappings and characters: no change to the algorithm, just elimination > of some features that didn't work in practice. If we want to place further restrictions the set of characters used in IDNs, I think it would be pretty rude of us to simply add them to the set of prohibited characters in Nameprep. What about the guy who registered .com? What if people had already bookmarked that site, and created links to it? Are we just going to break those links? A less rude approach would be to recommend that domain labels containing certain characters not be displayed. Their ACE forms could still be display, and they could still be looked up. The domain holder in this example could register a new displayable domain name, and could put an HTTP redirector at the old site, and existing bookmarks and links would continue to work. Erik van der Poel wrote: > I believe it would be difficult to reach consensus on a relatively > narrow extension of the LDH rule. Just for starters, the hyphen used > to separate names and other strings in the Western world is not used > in Japan for Katakana, because Katakana uses a middle dot (U+30FB) to > separate 2 Katakana strings. In fact, this character is allowed in > .jp. But notice how seldom the hyphen-minus is actually used in domain names. People prefer to just run words together, even in languages that customarily use word breaks. Maybe the analogous characters in other scripts (like the katakana middle dot) would likewise be very seldom used in practice (especially in Japan where the lack of word breaks is the norm), and would not be missed if they were deprecated. > It may be possible to "tune" the tables, but nowhere in your email do > I find any reference to the ACE prefix. I think that we should also > figure out exactly which types of changes would absolutely require a > new ACE prefix, Coming up with the necessary and sufficient conditions will be tricky, but now that you've got me thinking about it, I think I can supply one sufficient condition: If the only changes you make are to add characters to the prohibited table, I don't think you need to change the ACE prefix. This would cause some valid IDN labels under the old spec to become invalid under the new spec, and would cause some valid ACE labels under the old spec to become bogo-ACE labels under the new space. (The bogo-ACE phenomenon already exists: there are labels that begin with the ACE prefix but don't validate during ToUnicode and therefore display as literal ASCII strings.) It would not cause anything to encode or decode to something different than it used to. But I don't advocate making such a change (see my argument above about rudeness). AMC From owner-idn@ops.ietf.org Sat Feb 26 14:53:36 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25393 for ; Sat, 26 Feb 2005 14:53:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D57sL-000AFJ-PA for idn-data@psg.com; Sat, 26 Feb 2005 19:45:17 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D57sI-000AEv-JR for idn@ops.ietf.org; Sat, 26 Feb 2005 19:45:14 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1QJj9pY415772; Sat, 26 Feb 2005 14:45:09 -0500 Message-ID: <4220D1C4.7000909@vanderpoel.org> Date: Sat, 26 Feb 2005 11:45:08 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: [idn] something a little lighter for the weekend References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> In-Reply-To: <20050226081913.GD14956~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Oh, this one's just priceless. I have to share it with you all: http://e.netpia.com/ Move your mouse over the "Why NLIA" near the top, and then read the words that appear. With apologies to Netpia, Erik From owner-idn@ops.ietf.org Sat Feb 26 23:36:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26351 for ; Sat, 26 Feb 2005 23:36:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5G2q-0000G5-1Y for idn-data@psg.com; Sun, 27 Feb 2005 04:28:40 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5G2n-0000Ff-T5 for idn@ops.ietf.org; Sun, 27 Feb 2005 04:28:38 +0000 Received: from if12m4-235.d2.club-internet.fr ([212.195.66.235] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D5G2m-0001jA-EM for idn@ops.ietf.org; Sat, 26 Feb 2005 20:28:36 -0800 Message-Id: <6.1.2.0.2.20050227050824.03d100c0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Feb 2005 05:13:54 +0100 To: idn@ops.ietf.org From: "JFC (Jefsey) Morfin" Subject: [idn] Mozilla? In-Reply-To: <20050226081913.GD14956~@nicemice.net> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk http://www.earthtimes.org/articles/show/1754.html Will people not associate IDN now with phishing. In a way it seems worst than saying we block IDNs? jfc From owner-idn@ops.ietf.org Sun Feb 27 14:15:16 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23276 for ; Sun, 27 Feb 2005 14:15:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5Tma-0009RK-7x for idn-data@psg.com; Sun, 27 Feb 2005 19:08:48 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5TmY-0009Qx-Ta for idn@ops.ietf.org; Sun, 27 Feb 2005 19:08:47 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1RJ8eSJ218144; Sun, 27 Feb 2005 14:08:40 -0500 Message-ID: <42221AB7.9070000@vanderpoel.org> Date: Sun, 27 Feb 2005 11:08:39 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: [idn] dichotomies References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> In-Reply-To: <20050226081913.GD14956~@nicemice.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > That (or something very similar) was a principle that went into the > IDNA spec. I personally was inclined to define both internationalized > domain names and internationalized host names, where the former would > be completely general (allowing *all* Unicode characters, even the > invisible ones), and the latter would be much narrower (excluding most > punctuation and symbols). This would be an analogy to traditional > domain names (which allow all ASCII characters, even control characters) > and traditional host names (which allow only the ASCII letters, digits, > and one punctuation mark, the hyphen-minus). > > On the other hand, there was an argument that the traditional > distinction between domain names and host names was the source of > endless confusion and debate, and was a mistake that should not be > repeated with IDNs. I have some sympathy for that argument. > > In any case, we ended up with just one set of non-ASCII characters for > IDNs, between the two extremes: only invisible characters are excluded. > (I think there's one exception--a visible space character that is also > excluded). Another bifurcation that could be considered somewhat analogous is that of http vs https. We might even want to consider bringing the topic of security into the ACE prefix discussion. One could imagine a world where two different ACE prefixes co-exist, one new prefix for "secure" domain labels, the other (old) prefix for less secure labels. The secure prefix would have similar encoding and decoding rules, but would not have the sometimes-confusing mappings currently found in nameprep, and would prohibit a rather large number of Unicode characters and/or character types (for future expansion). We might then choose "xn--s" as the prefix, so that the raw Punycode form would also be more secure since there would be an 's' next to whatever follows, rather than a hyphen, which looks more like a delimiter. E.g. xn--spypal-4ve instead of xn--pypal-4ve. Note that the spypal looks quite different from pypal. Of course, this example isn't very good since the beginning of pypal doesn't resemble the beginning of paypal. A better example would be one where the 2nd 'a' of paypal was a homograph. However, a 2nd ACE prefix might be fraught with difficulties. Just for starters, we might end up with FQDNs with 3 different encodings (if there are 3 or more labels), i.e. both ACE prefixes and the pure ASCII TLD name. And then there would also be the question of *which* ACE prefix to choose while encoding. We might just have to specify that *all* the labels use the same ACE prefix (or pure ASCII, e.g. for the TLD). This would be consistent with RFC 1591 and current conventions (except for TLDs that allow just about anything underneath them). E.g. the .jp registry might have a rule that says that *all* domain labels either use one prefix or the other, together with pure ASCII for the final ".jp" part (or any part). Co-existence is quite different from transition. Although migration typically requires the co-existence of the old and the new during the transition period, people normally intend to complete the transition by getting rid of the old (entirely or almost entirely). However, there are probably many examples of migrations that started with good intentions but ended up with rather long periods of co-existence. One that comes to mind is HTML vs XHTML. I don't know whether we will ever be able to exterminate HTML, regardless of our "good" intentions. Erik From owner-idn@ops.ietf.org Sun Feb 27 14:20:37 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23619 for ; Sun, 27 Feb 2005 14:20:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5Tsh-000A6j-5w for idn-data@psg.com; Sun, 27 Feb 2005 19:15:07 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5Tsg-000A5o-5p for idn@ops.ietf.org; Sun, 27 Feb 2005 19:15:06 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1RJF1pY064608; Sun, 27 Feb 2005 14:15:01 -0500 Message-ID: <42221C34.2060505@vanderpoel.org> Date: Sun, 27 Feb 2005 11:15:00 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF idn working group Subject: [idn] Re: dichotomies References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <42221AB7.9070000@vanderpoel.org> In-Reply-To: <42221AB7.9070000@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik van der Poel wrote: > Another bifurcation that could be considered somewhat analogous is that > of http vs https. We might even want to consider bringing the topic of > security into the ACE prefix discussion. One could imagine a world where > two different ACE prefixes co-exist, one new prefix for "secure" domain > labels, the other (old) prefix for less secure labels. Sorry, I forgot to say that a Web site would choose the new secure ACE prefix when they use https. In fact, they would make that choice for similar reasons, i.e. to allow the user agent to distinguish this site from a less secure one, similar to Mozilla's current choice of using the padlock icon and a different color near the URI at the top for https. Erik From owner-idn@ops.ietf.org Sun Feb 27 18:01:18 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12659 for ; Sun, 27 Feb 2005 18:01:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5XKT-0009Yf-Mu for idn-data@psg.com; Sun, 27 Feb 2005 22:56:01 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5XKS-0009YO-JH for idn@ops.ietf.org; Sun, 27 Feb 2005 22:56:00 +0000 Received: from lns-p19-1-idf-82-251-93-168.adsl.proxad.net ([82.251.93.168] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D5XKQ-0005HH-UD; Sun, 27 Feb 2005 14:55:59 -0800 Message-Id: <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sun, 27 Feb 2005 23:55:47 +0100 To: Erik van der Poel , IETF idn working group From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: dichotomies In-Reply-To: <42221C34.2060505@vanderpoel.org> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <42221AB7.9070000@vanderpoel.org> <42221C34.2060505@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk (I will correct Erik's "xn--s" proposed notation into "xs--" not to create havoc in punycode) One of the reason why I disagreed with IDNA is it creates a possibly conflicting left-to-right hierarchy while the DNS hierarchy is right-to-left. Erik's proposition makes a lot of sense. But it means that a label at the same time: - belongs to a DNS zone - belongs to a zone of encoding (ascii, punycode, his punysecure, new versions, tables, other transcoding, etc. ) - may belong to a zone of encoding different from the zone of encoding of other labels (ex.: "xn--abc.xs-def.tld"). This does not simplify understanding, management, security. Why not to just use DNS zones? I have not yet understood why it was opposed. IMHO the future of ML.ML names are in the form "name2.name.xx--chicom.com" where "xx-nn.com" will print as ".com" in Chinese and name, name2 etc. will all have to use codes from the Chinese Table of ".com". jfc At 20:15 27/02/2005, Erik van der Poel wrote: >Erik van der Poel wrote: >>Another bifurcation that could be considered somewhat analogous is that >>of http vs https. We might even want to consider bringing the topic of >>security into the ACE prefix discussion. One could imagine a world where >>two different ACE prefixes co-exist, one new prefix for "secure" domain >>labels, the other (old) prefix for less secure labels. > >Sorry, I forgot to say that a Web site would choose the new secure ACE >prefix when they use https. In fact, they would make that choice for >similar reasons, i.e. to allow the user agent to distinguish this site >from a less secure one, similar to Mozilla's current choice of using the >padlock icon and a different color near the URI at the top for https. > >Erik From owner-idn@ops.ietf.org Sun Feb 27 19:12:55 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17327 for ; Sun, 27 Feb 2005 19:12:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5YQj-000I2M-Li for idn-data@psg.com; Mon, 28 Feb 2005 00:06:33 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5YQg-000I1x-7B for idn@ops.ietf.org; Mon, 28 Feb 2005 00:06:30 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1S06JpY413290; Sun, 27 Feb 2005 19:06:23 -0500 Message-ID: <4222607A.80804@vanderpoel.org> Date: Sun, 27 Feb 2005 16:06:18 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "JFC (Jefsey) Morfin" CC: IETF idn working group Subject: Re: [idn] Re: dichotomies References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <42221AB7.9070000@vanderpoel.org> <42221C34.2060505@vanderpoel.org> <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com> In-Reply-To: <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit JFC (Jefsey) Morfin wrote: > (I will correct Erik's "xn--s" proposed notation into "xs--" not to > create havoc in punycode) You are right, of course. What was I thinking? Duh. Well, how about "xs--n", to differentiate it from "xn--", and to still have the advantage of a non-delimiter-like character before the rest of the string? > One of the reason why I disagreed with IDNA is it creates a possibly > conflicting left-to-right hierarchy while the DNS hierarchy is > right-to-left. I'm afraid I don't understand this. > This does not simplify understanding, management, security. Why not to > just use DNS zones? I have not yet understood why it was opposed. IMHO > the future of ML.ML names are in the form "name2.name.xx--chicom.com" > where "xx-nn.com" will print as ".com" in Chinese and name, name2 etc. > will all have to use codes from the Chinese Table of ".com". I think your proposal makes some sense. It is similar to my proposal in a way -- recall my .jp example, with the rule that *all* labels would have to use the same ACE prefix or pure ASCII. There isn't really any way to force the TLDs or zone administrators to follow any rules that we might come up with. The best we can do is write down some guidelines that are well thought out. And write them clearly. If registries and zone administrators fail to follow the guidelines, the applications may have to display their domain names differently, to indicate some level of risk. Also, we can't just suddenly switch a TLD from one encoding to another and then expect all the subdomains to follow suit the same night. Instead, we might have a rule specifying that all labels under the first new ACE prefix must use the same prefix. For example, suppose we have a new domain with the new prefix, called "xs--nfoo-abc.jp". Since the 2LD uses the new prefix, any 3LDs, 4LDs and so on would also have to use the new prefix. Does this make sense? Finally, regarding displaying ".com" in Chinese, there is currently no reason to display ".com" in ASCII. This could easily be displayed in Chinese if the application developers were only willing to modify their programs to be more user-friendly. Of course, this brings up all sorts of issues like what to do with copy and paste, educating users about the new kind of display, being able to type ".com" in Chinese in one application while being required to type it in ASCII in another, and so on. There are some issues, but theoretically, you *can* already display ".com" in Chinese. This is not so different from Punycode itself, which you wouldn't normally display as is. You first decode it and then show the Unicode to the user. Erik From owner-idn@ops.ietf.org Sun Feb 27 21:04:51 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25633 for ; Sun, 27 Feb 2005 21:04:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5a8V-0005KD-Ct for idn-data@psg.com; Mon, 28 Feb 2005 01:55:51 +0000 Received: from [128.32.132.165] (helo=nicemice.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5a8R-0005Ji-6D for idn@ops.ietf.org; Mon, 28 Feb 2005 01:55:47 +0000 Received: from amc by nicemice.net with local (Exim 3.35 #1 (Debian)) id 1D5a8P-0006pI-00 for ; Sun, 27 Feb 2005 17:55:45 -0800 Date: Mon, 28 Feb 2005 01:55:45 +0000 From: "Adam M. Costello" To: IETF idn working group Subject: Re: [idn] something a little lighter for the weekend Message-ID: <20050228015545.GA23896~@nicemice.net> Reply-To: IETF idn working group References: <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <4220D1C4.7000909@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4222607A.80804@vanderpoel.org> <4220D1C4.7000909@vanderpoel.org> User-Agent: Mutt/1.5.6+20040722i X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Erik van der Poel wrote: > Oh, this one's just priceless. I have to share it with you all: > > http://e.netpia.com/ > > Move your mouse over the "Why NLIA" near the top, and then read the > words that appear. That was extremely funny. And then, after I read more about this company, somewhat ominous. In a nutshell, they're setting up an alternate root for DNS, so that people unfamiliar with Latin characters won't have to deal with ASCII TLDs. It's a nice goal, but the means are worrisome to say the least. Maybe this is a sign that it's time to figure out a standard way to support non-ASCII TLDs. > Finally, regarding displaying ".com" in Chinese, there is currently > no reason to display ".com" in ASCII. This could easily be displayed > in Chinese if the application developers were only willing to modify > their programs to be more user-friendly. I don't thin it's that simple. The purpose of domain names is to serve as global identifiers. If non-ASCII synonyms for TLDs were left as a UI issue for each application to solve independently, two different applications could choose different Thai spellings for .uk (for example), and their users wouldn't be able to refer each other to sites; the domain names wouldn't be fulfilling their purpose as global identifiers. Therefore, the spellings of all the TLDs in all the scripts need to be standardized. That's about 300 TLDs times about 50 scripts, potentially around 15,000 localized TLDs. Such a table probably shouldn't be hard-coded into every application. It should be kept in an online database, like... the DNS! According to the Unicode standard, there are 52 scripts. Currently, all TLDs use the Latin script. I suggest that every country be allowed to register up to 51 additional TLDs, one per non-Latin script, in the root zone. Countries would choose abbreviations for themselves, which would need to be ratified by some review process to make sure they were reasonable, and not homographs of other TLDs. A similar policy could exist for gTLDs, except that .com and .$B>&(B [that's my guess at the analogue of .com in the Han script] would not necessarily be operated by the same registry; any accredited registry could apply to operate a synonym for an existing ASCII gTLD in a script that was not already in service, and the proposed new gTLD would be checked for being a reasonable synonym, but would not have to redo the arduous approval process that the original ASCII gTLD did. To be fair to early registrants of IDNs, perhaps every new non-ASCII gTLD should be required to initialize its zone with any names from the corresponding ASCII gTLD zone that satisfy the (possibly more restrictive) syntax rules of the new gTLD. The names should be added in order of seniority, in case the new gTLD has more restrictive name-blocking rules that prevent two admissible names from coexisting. The names in the new zone would inherit their owners and expiration dates from the old zone. After the initialization, the new zone would be independent of the old zone, and people could opt to register/renew names in one and not the other. Non-ASCII TLDs would be represented using IDNA, no different from labels at any other level. AMC From owner-idn@ops.ietf.org Sun Feb 27 21:18:32 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27094 for ; Sun, 27 Feb 2005 21:18:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5aRe-0007vK-3F for idn-data@psg.com; Mon, 28 Feb 2005 02:15:38 +0000 Received: from [207.115.63.102] (helo=pimout3-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5aRa-0007u5-Ou for idn@ops.ietf.org; Mon, 28 Feb 2005 02:15:35 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1S2FSpY401160; Sun, 27 Feb 2005 21:15:32 -0500 Message-ID: <42227EBF.9040703@vanderpoel.org> Date: Sun, 27 Feb 2005 18:15:27 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: idn@ops.ietf.org Subject: [idn] character tables References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> In-Reply-To: <421FCBD7.8000805@vanderpoel.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > However, one avenue that might be worth exploring some more is to check > each registry's character table (for those that have one) and see what > the Unicode category is for each character. The Japanese Katakana middle > dot U+30FB has the category "Pc" which means "punctuation, connector" > and LDH's hyphen U+002D has the category "Pd" which means "punctuation, > dash". > > http://www.unicode.org/Public/UNIDATA/UnicodeData.txt > http://www.unicode.org/Public/UNIDATA/UCD.html#General_Category_Values > > If it turns out that all or most of the registries that have tables are > using characters with only a small number of Unicode categories, then we > may wish to consider moving IDNA to that set of categories (disallowing > all others). This would keep the registries happy while keeping *some* > of the phishy characters out of DNS. Even if we do not end up prohibiting a larger number of characters in nameprep-bis, it might still be a good idea to have the results of the investigation proposed above, since these Unicode character categories could then be entered into the guidelines for the registries. So, these two sub-projects (nameprep-bis and registry table investigation) could proceed in parallel. I think it would be good to divide and conquer, since one person cannot do all of this. Perhaps we could invite volunteers to work on sub-projects? As I indicate at nameprep.org, I found some character tables at the IANA site, but I found even more at the GNU libidn site. One of the first things to do is to agree on a single machine-readable format. The tables do not all use the same format yet, it seems. Then we would also need to have the latest and most official tables from the registries themselves (instead of possibly out of date IANA tables and possibly embellished unofficial GNU libidn tables). http://nameprep.org/#related-work Erik From owner-idn@ops.ietf.org Sun Feb 27 22:03:40 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00985 for ; Sun, 27 Feb 2005 22:03:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5b7X-000EHy-FX for idn-data@psg.com; Mon, 28 Feb 2005 02:58:55 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5b7V-000EHZ-Cp for idn@ops.ietf.org; Mon, 28 Feb 2005 02:58:53 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D5b7V-000IgY-1j; Sun, 27 Feb 2005 21:58:53 -0500 Date: Sun, 27 Feb 2005 21:58:52 -0500 From: John C Klensin To: Erik van der Poel cc: idn@ops.ietf.org Subject: [idn] Re: character tables Message-ID: <45781B7428C6AA07C3B283BD@scan.jck.com> In-Reply-To: <42227EBF.9040703@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Sunday, 27 February, 2005 18:15 -0800 Erik van der Poel wrote: >... > As I indicate at nameprep.org, I found some character tables > at the IANA site, but I found even more at the GNU libidn > site. One of the first things to do is to agree on a single > machine-readable format. The tables do not all use the same > format yet, it seems. Then we would also need to have the > latest and most official tables from the registries themselves > (instead of possibly out of date IANA tables and possibly > embellished unofficial GNU libidn tables). Erik, I'm been mildly resisting standard-format, machine-interpretable, tables at IANA for a few reasons. The two most important ones are: (i) ICANN is still assuming that this is a registry issue. As such, if someone else starts guessing at what a registry is doing, we may get into trouble, especially since the tables may not show all of the relevant registry rules and restrictions. (ii) We've got at least two models for processing a proposed IDN. One compares the proposed label against a list of characters for the selected language as maintained by that registry and, if it passes, registers it if it isn't already taken. The other involves the JET "variant" model, or some relative of it, to determine what labels, or sets of labels, are permitted. The first plan requires a simple list of characters; the second requires a three (or two, or four) column table. Also please note that the IANA tables make no attempt to be authoritative for any given language. They are just documentation of what characters a given registry permits to be associated with a given "language" for their registry. To have three different, and incompatible, tables --associated with three different registries-- for "the same language" is not only possible, but likely. john From owner-idn@ops.ietf.org Sun Feb 27 22:22:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02416 for ; Sun, 27 Feb 2005 22:22:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5bR4-000H1r-I4 for idn-data@psg.com; Mon, 28 Feb 2005 03:19:06 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5bR2-000H1d-Vk for idn@ops.ietf.org; Mon, 28 Feb 2005 03:19:05 +0000 Received: from lns-p19-1-idf-82-251-93-168.adsl.proxad.net ([82.251.93.168] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D5bR1-0005Zs-6N; Sun, 27 Feb 2005 19:19:04 -0800 Message-Id: <6.1.2.0.2.20050228014024.02d4e920@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Feb 2005 04:18:51 +0100 To: Erik van der Poel From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: dichotomies Cc: idn@ops.ietf.org In-Reply-To: <4222607A.80804@vanderpoel.org> References: <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <42221AB7.9070000@vanderpoel.org> <42221C34.2060505@vanderpoel.org> <6.1.2.0.2.20050227203118.02f22eb0@mail.jefsey.com> <4222607A.80804@vanderpoel.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk On 01:06 28/02/2005, Erik van der Poel said: >JFC (Jefsey) Morfin wrote: >>(I will correct Erik's "xn--s" proposed notation into "xs--" not to >>create havoc in punycode) > >You are right, of course. What was I thinking? Duh. Well, how about >"xs--n", to differentiate it from "xn--", and to still have the advantage >of a non-delimiter-like character before the rest of the string? No need to have 4 and 5 characters. xs-- would be enough. >>One of the reason why I disagreed with IDNA is it creates a possibly >>conflicting left-to-right hierarchy while the DNS hierarchy is right-to-left. > >I'm afraid I don't understand this. The DNS hierarchy are 1st level, 2nd level, etc. from right to left. The scripting hierarchy introduced by the ACE prefix (on the left of the name) decides if the label is ASCII or not. This is a local hierarchy in the label. But using Tables, permitting other versions as you proposes is creating a de facto lame hierarchy with various Tables applying or not. In the same URI..... >>This does not simplify understanding, management, security. Why not to >>just use DNS zones? I have not yet understood why it was opposed. IMHO >>the future of ML.ML names are in the form "name2.name.xx--chicom.com" >>where "xx-nn.com" will print as ".com" in Chinese and name, name2 etc. >>will all have to use codes from the Chinese Table of ".com". > >I think your proposal makes some sense. It is similar to my proposal in a >way -- recall my .jp example, with the rule that *all* labels would have >to use the same ACE prefix or pure ASCII. ACE prefix: I suppose you mean the same table. Please understand there are three layers: - internationalization: the scripts, the strcuture, etc. what is discussed by IDNA. This is the basis. But it does not make a service. - multilingualization: the support of languages. IDNA is poor at that because it has not analyzed enough the structure of naming and that ASCII is just another lingual support using the ASCII Table which IS defined (by default) and forgot to structurally require the other tables to be defined. (".com" is actually ".ascii.com" - what helps you to understand that ".chinese.com" is NOT ".ascii.com" or ".com", not the same zone while IDNA makes them the same. - vernacularization: what permits the users to use the system (ex. the colors, etc.). They not only refused to consider but did not work out the tools permitting it to be built (like a compression method to distribute Tables, etc.). >There isn't really any way to force the TLDs or zone administrators to >follow any rules that we might come up with. The best we can do is write >down some guidelines that are well thought out. And write them clearly. We have no _rule_ at all to write for anyone. If you edict a rule you must be able to enforce it. You can only describe the way things should work and hope people will adhere. So you have to keep it as simple, unique and logic as possible. The strength of the DNS is to be such. This results from the zones. When you manage a zone you are the master in your zone but you _cannot_ affect the layer above. With IDNA you can: because if you enter an ACE prefix in your zone, the whole FQDN becomes a FQIDN. For 22 years there is only one version of the DNS, the ACE prefix does not change that because it is unique. But if there are several prefixes the DN becomes complex. >If registries and zone administrators fail to follow the guidelines, the >applications may have to display their domain names differently, to >indicate some level of risk. The error (IMHO) of IDNS is to require "guidelines". The DNS has no "guidelines". It has functions. You use them correctly and it works, you don't and it does not. >Also, we can't just suddenly switch a TLD from one encoding to another and >then expect all the subdomains to follow suit the same night. Instead, we >might have a rule specifying that all labels under the first new ACE >prefix must use the same prefix. For example, suppose we have a new domain >with the new prefix, called "xs--nfoo-abc.jp". Since the 2LD uses the new >prefix, any 3LDs, 4LDs and so on would also have to use the new prefix. >Does this make sense? No. Because today we have already two rules. 1. a hierarchy on zones. From right to left. If I have ".com" TLD, the SLD will obey the ".com" rules, etc. 2. a local ACE prefix is _local_ to the label. Even if as I said above it has an impact on the whole FQDN creating a lame bottom-up hierarchy. Now, what you propose is that if you put an "xn--" label somewhere it will "pollute" the whole FQDN into an FQIDN to be entirely read in using punycode without ACE prefix. This would be mad. Each label can be read/used separately, the ACE prefix is part of the punycode transcoding. Important point: once the FQDN has been properly declared a FQIDN (through the top level information) you can have all the possible transcoding (with as many xn/xs/zq/etc-- ) you want and stay consistent: the right to left hierarchy has been respected. >Finally, regarding displaying ".com" in Chinese, there is currently no >reason to display ".com" in ASCII. This could easily be displayed in >Chinese if the application developers were only willing to modify their >programs to be more user-friendly. No. Here is the confusion between the internationalization and the multilingualization layer. What Adams called the host name (which becomes too complex in reality due to the probable extensive use of aliases - another topic). ".com" in Chinese does not make sense: who is going to say that it is to be printed in Chinese? as a Chinese name chosen by who? or in ASCII? ".com" is a default for ".ascii.com". Once you have understood that, there is no more problem of any kind. The DNS is something very powerful because it is simple. It knows very little: labels and dots. IDNA says that applications can transcode labels at the application level. But they did not address the top level. . This was partly corrected with the Tables: but there is no mechanical relation between the TLD and a given Table as in the ASCII Domain Name. In the ASCII Domain Name, the Table is ASCII, you cannot use EBCDIC. This information MUST be provided. The way the DNS (actually the global naming) does it is through a zone. This zone can be a primary zone (a _new_ Chinese .com equivalent having Chinese Table as a default) or lingual primary zone (a .chinese.com) zone. In that zone names will then have to be IDN labels using the .com Chinese Table (or other Chinese accepted codes). If there is no Table, there cannot be any name registered. Just remind this very simple ".com" actually is an abreviation for ".ascii.com" using the ANSI Table. This means that the transcoding must be adapted. - nameprep can know the table and check the IDN consistency. - read/present the ".chinese.com" sequence in Chinese as the Chinese ".com" label. > Of course, this brings up all sorts of issues like what to do with copy > and paste, educating users about the new kind of display, being able to > type ".com" in Chinese in one application while being required to type it > in ASCII in another, and so on. There are some issues, but theoretically, > you *can* already display ".com" in Chinese. >This is not so different from Punycode itself, which you wouldn't normally >display as is. You first decode it and then show the Unicode to the user. I am not sure about what you discuss here. If you punycode a TLD you create a new TLD? jfc From owner-idn@ops.ietf.org Sun Feb 27 22:54:08 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04830 for ; Sun, 27 Feb 2005 22:54:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5bvI-000KWh-Pt for idn-data@psg.com; Mon, 28 Feb 2005 03:50:20 +0000 Received: from [63.247.74.122] (helo=montage.altserver.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5bvH-000KWS-Eb for idn@ops.ietf.org; Mon, 28 Feb 2005 03:50:19 +0000 Received: from lns-p19-1-idf-82-251-93-168.adsl.proxad.net ([82.251.93.168] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1D5bvE-0005hr-CK; Sun, 27 Feb 2005 19:50:17 -0800 Message-Id: <6.1.2.0.2.20050228042227.02d41cc0@mail.jefsey.com> X-Sender: jefsey+jefsey.com@mail.jefsey.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Mon, 28 Feb 2005 04:50:04 +0100 To: John C Klensin , Erik van der Poel From: "JFC (Jefsey) Morfin" Subject: Re: [idn] Re: character tables Cc: idn@ops.ietf.org In-Reply-To: <45781B7428C6AA07C3B283BD@scan.jck.com> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> <45781B7428C6AA07C3B283BD@scan.jck.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 03:58 28/02/2005, John C Klensin wrote: >To have three different, and incompatible, tables --associated with three >different registries-- for "the same language" is not only possible, but >likely. There are 260 TLDs. There are 7260 languages, some of them having 2 or even 3 scripts. There are around 13000 dialects of some importance (one consider that a language needs 100.000 people speaking it to survive. e-colonization (dominance of an e-culture) should probably lead to the initial deprecation of some languages, but recent history shows a cultural resistance and resurgence after such a chock.So one can consider that Internet will most probably help languages to survive and develop: a 50.000 people minium might be a good rule of thumb (think of trade, community idioms). So roughly one can consider that 50.000 languages with possible 260 variants (at TLD level) are to be considered when planning a solution able to scale. Obviously most of them will try to use the same script as much as they can for the TLDs. But this cannot be considered as systematic all throughout a language. So one has to consider 10 millions possibilities most of them synonyms or not implemented. I am just talking of the legacy: PADs may introduce 10 times this. This looks an impossible task in following the IDNA internationalization concepts. I do not think it is a big deal for the DNS concepts if respected and real life constraints. jfc NB. The problem discussed was the phishing permitted by IDNA. Not to (re)build a consistent global namespace support by the DNS. The current grassroots process of which NETPIA is only one of the participants will necessarily address it, only because 86% of the people need it. IMHO if we wanted the IETF to do something positive in that area, we should start in making a review of all the existing solutions, projects, trends, and probable possibilities and try to give them some common guidance towards a common consistency. From owner-idn@ops.ietf.org Sun Feb 27 23:25:24 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07308 for ; Sun, 27 Feb 2005 23:25:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5cNQ-000Otc-90 for idn-data@psg.com; Mon, 28 Feb 2005 04:19:24 +0000 Received: from [207.115.63.77] (helo=pimout1-ext.prodigy.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5cNN-000OtK-59 for idn@ops.ietf.org; Mon, 28 Feb 2005 04:19:21 +0000 Received: from [10.1.1.2] (adsl-64-174-147-206.dsl.sntc01.pacbell.net [64.174.147.206]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j1S4J9SJ246782; Sun, 27 Feb 2005 23:19:14 -0500 Message-ID: <42229BBC.8020608@vanderpoel.org> Date: Sun, 27 Feb 2005 20:19:08 -0800 From: Erik van der Poel User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John C Klensin CC: idn@ops.ietf.org Subject: Re: [idn] Re: character tables References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> <45781B7428C6AA07C3B283BD@scan.jck.com> In-Reply-To: <45781B7428C6AA07C3B283BD@scan.jck.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John C Klensin wrote: > > (i) ICANN is still assuming that this is a registry > issue. As such, if someone else starts guessing at what > a registry is doing, we may get into trouble, especially > since the tables may not show all of the relevant > registry rules and restrictions. Hmmm... GNU libidn already seems to be trying to use machine-readable tables. I had a look at the GNU libidn page: http://www.gnu.org/software/libidn/ It has a copy of an expired Internet Draft by Paul Hoffman: http://josefsson.org/cgi-bin/rfcmarkup?url=http://josefsson.org/cgi-bin/viewcvs.cgi/*checkout*/libidn/doc/specifications/draft-hoffman-idn-reg-02.txt This draft seems to be talking about bundling and blocking, which your draft talks about too. What happened here? Did Paul decide to let his expire? Anyway, my only reason for trying to get machine-readable tables was to figure out which Unicode character categories were being used. Another way to get this info is to simply ask the registries. Or, we can suggest a list of categories and see if they would be happy with a nameprep-bis that limits the characters to those categories. Erik From owner-idn@ops.ietf.org Sun Feb 27 23:37:48 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08292 for ; Sun, 27 Feb 2005 23:37:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5cbe-0000Zq-CK for idn-data@psg.com; Mon, 28 Feb 2005 04:34:06 +0000 Received: from [208.184.76.39] (helo=above.proper.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5cbd-0000Zd-Gq for idn@ops.ietf.org; Mon, 28 Feb 2005 04:34:05 +0000 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S4Xvxx088369; Sun, 27 Feb 2005 20:33:58 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42229BBC.8020608@vanderpoel.org> References: <421B8484.3070802@vanderpoel.org> <20050223072837.GA21463~@nicemice.net> <421D8411.9030006@vanderpoel.org> <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <421FA55B.9000308@vanderpoel.org> <421FCBD7.8000805@vanderpoel.org> <42227EBF.9040703@vanderpoel.org> <45781B7428C6AA07C3B283BD@scan.jck.com> <42229BBC.8020608@vanderpoel.org> Date: Sun, 27 Feb 2005 20:33:54 -0800 To: Erik van der Poel , John C Klensin From: Paul Hoffman Subject: Re: [idn] Re: character tables Cc: idn@ops.ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk At 8:19 PM -0800 2/27/05, Erik van der Poel wrote: >What happened here? Did Paul decide to let his expire? Yes. It turned out to be a bad idea that got more complicated and less justifiable (that is, worse) with each rev, so I let it die. Others (notably JET) tried different things. --Paul Hoffman, Director --Internet Mail Consortium From owner-idn@ops.ietf.org Mon Feb 28 11:31:27 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06344 for ; Mon, 28 Feb 2005 11:31:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5nhJ-000NtM-SH for idn-data@psg.com; Mon, 28 Feb 2005 16:24:41 +0000 Received: from [68.168.78.202] (helo=mta10.adelphia.net) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5nhI-000NsU-10 for idn@ops.ietf.org; Mon, 28 Feb 2005 16:24:40 +0000 Received: from DEWELL ([68.66.2.217]) by mta10.adelphia.net (InterMail vM.6.01.04.01 201-2131-118-101-20041129) with SMTP id <20050228162438.THJ6134.mta10.adelphia.net@DEWELL> for ; Mon, 28 Feb 2005 11:24:38 -0500 Message-ID: <003101c51db1$d8a16580$030aa8c0@DEWELL> From: "Doug Ewell" To: "IETF idn working group" References: <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <4220D1C4.7000909@vanderpoel.org> <20050228015545.GA23896~@nicemice.net> Subject: Re: [idn] something a little lighter for the weekend Date: Mon, 28 Feb 2005 08:23:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Adam M. Costello wrote: > According to the Unicode standard, there are 52 scripts. There may be 52 scripts currently encoded in Unicode, but I am sure Unicode does not claim that is the total number of scripts in the world. Others can and will be encoded. -Doug Ewell Fullerton, California http://users.adelphia.net/~dewell/ From owner-idn@ops.ietf.org Mon Feb 28 13:17:31 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18445 for ; Mon, 28 Feb 2005 13:17:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5pOn-000DjZ-UQ for idn-data@psg.com; Mon, 28 Feb 2005 18:13:41 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5pOl-000Dgh-Pa for idn@ops.ietf.org; Mon, 28 Feb 2005 18:13:39 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 10:13:35 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 28 Feb 2005 10:13:32 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 28 Feb 2005 10:13:34 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 28 Feb 2005 10:13:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [idn] something a little lighter for the weekend Date: Mon, 28 Feb 2005 10:13:38 -0800 Message-ID: Thread-Topic: [idn] something a little lighter for the weekend thread-index: AcUdsq1aI9mYCVtlTiy3HnK2Q7OxuQADfxSw From: "Michel Suignard" To: "Doug Ewell" , "IETF idn working group" X-OriginalArrivalTime: 28 Feb 2005 18:13:34.0235 (UTC) FILETIME=[3739B6B0:01C51DC1] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 VGhlIDIgY3VycmVudCBhbWVuZG1lbnRzIG9mIElTTy9JRUMgMTA2NDYgKFRoZSBJU08gc2libGlu ZyBvZiBVbmljb2RlKSBiZWluZyBwcm9jZXNzZWQgYXJlIGFkZGluZyBhYm91dCAxMCBuZXcgc2Ny aXB0cy4gQW5kIGEgbmV3IGFtZW5kbWVudCB3aWxsIGJlIGluaXRpYXRlZCBpbiBTZXB0ZW1iZXIg d2l0aCBmZXcgbW9yZSBzY3JpcHRzLiBBbnkgc2NoZW1lIGJhc2VkIG9uIGEgZmluaXRlIG51bWJl ciBvZiBzY3JpcHRzIGlzIGRvb21lZC4NCg0KTWljaGVsIA0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogb3duZXItaWRuQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLWlkbkBv cHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEb3VnIEV3ZWxsDQoNCkFkYW0gTS4gQ29zdGVsbG8g PGlkbiBkb3QgYW1jIHBsdXMgMCBhdCBuaWNlbWljZSBkb3QgbmV0IGRvdA0KUmVtb3ZlVGhpc1dv cmQ+IHdyb3RlOg0KDQo+IEFjY29yZGluZyB0byB0aGUgVW5pY29kZSBzdGFuZGFyZCwgdGhlcmUg YXJlIDUyIHNjcmlwdHMuDQoNClRoZXJlIG1heSBiZSA1MiBzY3JpcHRzIGN1cnJlbnRseSBlbmNv ZGVkIGluIFVuaWNvZGUsIGJ1dCBJIGFtIHN1cmUgVW5pY29kZSBkb2VzIG5vdCBjbGFpbSB0aGF0 IGlzIHRoZSB0b3RhbCBudW1iZXIgb2Ygc2NyaXB0cyBpbiB0aGUgd29ybGQuDQpPdGhlcnMgY2Fu IGFuZCB3aWxsIGJlIGVuY29kZWQuDQoNCi1Eb3VnIEV3ZWxsDQogRnVsbGVydG9uLCBDYWxpZm9y bmlhDQogaHR0cDovL3VzZXJzLmFkZWxwaGlhLm5ldC9+ZGV3ZWxsLw0KDQoNCg0K From owner-idn@ops.ietf.org Mon Feb 28 13:54:47 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21718 for ; Mon, 28 Feb 2005 13:54:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5pxw-000IFH-P0 for idn-data@psg.com; Mon, 28 Feb 2005 18:50:00 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5pxu-000IEv-L4 for idn@ops.ietf.org; Mon, 28 Feb 2005 18:49:58 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D5pxu-000PQ3-1s; Mon, 28 Feb 2005 13:49:58 -0500 Date: Mon, 28 Feb 2005 13:49:57 -0500 From: John C Klensin To: Doug Ewell , IETF idn working group Subject: Re: [idn] something a little lighter for the weekend Message-ID: In-Reply-To: <003101c51db1$d8a16580$030aa8c0@DEWELL> References: <421E0D0C.2000309@vanderpoel.org> <421E30F2.1040408@vanderpoel.org> <0E7F74C71945B923C52211F3@scan.jck.com> <421EA0C9.1010500@vanderpoel.org> <00a401c51af3$7863aae0$030aa8c0@DEWELL> <20050226081913.GD14956~@nicemice.net> <4220D1C4.7000909@vanderpoel.org> <20050228015545.GA23896~@nicemice.net> <003101c51db1$d8a16580$030aa8c0@DEWELL> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Monday, 28 February, 2005 08:23 -0800 Doug Ewell wrote: > Adam M. Costello RemoveThisWord> wrote: > >> According to the Unicode standard, there are 52 scripts. > > There may be 52 scripts currently encoded in Unicode, but I am > sure Unicode does not claim that is the total number of > scripts in the world. Others can and will be encoded. At least as important, those are "scripts" with regard to typographic relationships, more or less. The issue that started ICANN (and others) down the "language" path is that, if one wants to avoid homographs _as seen by a user who is not familiar with a different script or part of a script_, one often needs to make more constrained lists of characters than those that appear to be "scripts" from the Unicode standpoint. And, as Michel points out, the Unicode list is growing and will probably continue to grow. john From owner-idn@ops.ietf.org Mon Feb 28 21:20:41 2005 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04093 for ; Mon, 28 Feb 2005 21:20:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.44 (FreeBSD)) id 1D5wrp-000IXv-Fw for idn-data@psg.com; Tue, 01 Mar 2005 02:12:09 +0000 Received: from [209.187.148.211] (helo=bs.jck.com) by psg.com with esmtp (Exim 4.44 (FreeBSD)) id 1D5wrm-000IXR-7K for idn@ops.ietf.org; Tue, 01 Mar 2005 02:12:06 +0000 Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1D5wri-00029Y-Ss; Mon, 28 Feb 2005 21:12:02 -0500 Date: Mon, 28 Feb 2005 21:12:02 -0500 From: John C Klensin To: Erik van der Poel cc: idn@ops.ietf.org Subject: Re: [idn] Re: character tables Message-ID: <1D715880C7A8824037DACAA7@scan.jck.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,URI_REDIRECTOR autolearn=ham version=3.0.1 Sender: owner-idn@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit --On Sunday, 27 February, 2005 20:19 -0800 Erik van der Poel wrote: > John C Klensin wrote: >> >> (i) ICANN is still assuming that this is a registry >> issue. As such, if someone else starts guessing at what >> a registry is doing, we may get into trouble, especially >> since the tables may not show all of the relevant >> registry rules and restrictions. > > Hmmm... GNU libidn already seems to be trying to use > machine-readable tables. I had a look at the GNU libidn page: > > http://www.gnu.org/software/libidn/ > > It has a copy of an expired Internet Draft by Paul Hoffman: > > http://josefsson.org/cgi-bin/rfcmarkup?url=http://josefsson.or > g/cgi-bin/viewcvs.cgi/*checkout*/libidn/doc/specifications/dra > ft-hoffman-idn-reg-02.txt > > This draft seems to be talking about bundling and blocking, > which your draft talks about too. What happened here? Did Paul > decide to let his expire? Yes. Paul more or less gave up (he can explain that decision; I won't try to do it for him), then generously consented to the inclusion of some of his text and definitions, and even more of his concepts, into my draft. A different way of looking at this is that we found our drafts converging and I got the short straw for producing a consolidated version and trying to walk it through the works. Paul gets considerable credit but bears no responsibility or blame, for the result, but I hope we still are in at least broad agreement. > Anyway, my only reason for trying to get machine-readable > tables was to figure out which Unicode character categories > were being used. Another way to get this info is to simply ask > the registries. Or, we can suggest a list of categories and > see if they would be happy with a nameprep-bis that limits the > characters to those categories. As has been pointed out in other contexts, this is probably a fool's errand. If a registry declines to register something, then is isn't present and there isn't much value in guessing whether a lookup fails because the name was not registered or because its registration was prohibited. Conversely, if a registry either has no rules or declines to follow the rules it does have, knowing what those rules were supposed to be is not terribly useful. If a browser wants to apply sanity checks before it attempts a DNS lookup, that is really a separate set of issues and constraints. And, again, knowing the rules a registry would have applied if its authority reached down more than a level or two probably isn't a big help. john