headers
Tina Dam | 21 Sep 02:43
Picon

Revised IDN Guidelines Open for Public Comments

I wanted to let you know that we posted the draft revised version of the IDN
Guidelines, for public comments.

http://icann.org/announcements/announcement-20sep05.htm

ICANN has opened a 30-day public comment period on a draft revised version
of the Guidelines for the Implementation of Internationalized Domain Names
("IDN Guidelines"). This draft reflects the experiences of the IDN
registries in the implementation of Version 1.0 of the guidelines.
Particular attention has been paid to concerns that have arisen about the
deceptive use of visually confusable characters from different scripts in
individual IDN labels.

As mentioned previously, following the comment period and any appropriate
amendments, the final version of the IDN Guidelines will be submitted to the
ICANN Board for endorsement.

Best regards,

Tina Dam
Chief gTLD Registry Liaison
ICANN

Office: +1-310-301-5838
Cell: +1-310-862-2026
Permalink | Reply | 1 comment |
headers
Gervase Markham | 22 Jul 18:12
Picon
Favicon
Gravatar

IDN Implementation Status Update

This is a message to tell interested parties the current status of the 
mozilla.org changes to Firefox regarding IDN.

We have implemented a TLD whitelist system, which currently contains 21 
TLDs for which we correctly display IDN domain names in the UI.
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
Any IDN domain name in a non-whitelisted TLD displays as punycode. This 
is a security feature and so there is no user interface for adding or 
removing TLDs.

Any registry which wishes to be added to the whitelist should follow the 
instructions on that page. In terms of what constitutes a homograph, we 
are being guided by the Unicode Consortium's confusables list:
http://www.unicode.org/draft/reports/tr36/data/confusables.txt
and by common sense. Our policy in this area is still somewhat in flux - 
in particular, we are not yet sure whether we should require that 
registries to consider two characters which differ only in accent 
(sometimes by the shade of a single pixel at normal font sizes) as 
homographic. In the mean time, we strongly advise that registries do this.

We have implemented a character blacklist, which will soon contain 
'DIVISION SLASH' (U+2215) and 'FRACTION SLASH' (U+2044). After that, we 
may extend it to forbid more characters which may be used to spoof URL 
punctuation.
https://bugzilla.mozilla.org/show_bug.cgi?id=301694
This is not meant to prejudice the outcome of the current IAB-IDN 
discussions on potentially reducing the number of characters permitted 
in IDN, but we feel the danger posed by the use of such characters in 
3rd and 4th level domains is great enough to require an immediate ban. 
Any domain name which contains one or more of these characters displays
(Continue reading)

Permalink | Reply | 0 comments |
headers
Harald | 14 Jul 11:44
Picon

Re:

+----------------------------------------------------+

Panda GateDefender has detected malicious content (Virus) in the following file: [New_MP3_Player.c
pl]
W32/Bagle.AH.worm

The file has been deleted to protect the network.
07/14/2005 08:38 +0100

www.pandasoftware.com

+----------------------------------------------------+

>Screen and Music


Permalink | Reply | 2 comments |
headers
JFC (Jefsey) Morfin | 11 May 16:21

RE: a way toward homograph resolution ? (was "improving WG operation")

On 15:29 11/05/2005, Hallam-Baker, Phillip said:
> > This cacologic however might be a good way to solve the IDN
> > homograph issue and the phishing problem.
>
>I have been spending most of my time on the phishing problem for three
>years. I have yet to see a phishing gang use the DNS IDN loophole for a
>phishing attack.

Dear Allan,
I am afraid you are right due to the low interest in the IDN solution 
(however punycode is of interest). Why not to document your experience to 
ccTLDs? We are very concerned about this because we can do nothing about it 
and people believe we can.

What what "techies" say is "don't worry" we know the problem for a long 
:-). True this is one of the reason why I objected to IDNA. But IDNA is 
still here? Help welcome!

>This is probably because the issue was an administrative one, the cert
>should never have issued and in the wake of the paper the CAs I have
>talked to have all corrected the issue.

CA?

>The lookalike DNS name problem was known before the design of SSL
>started, remember Micros0ft.com?
>
>Today the phishing gangs use bigbank-security.com or bigbank-corp.com or
>something similar. They are not going to use IDN DNS names until the
>application support is much much more comprehensive by which time the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik van der Poel | 5 May 23:34

homographs in TrueType fonts

I have written a small program that parses a number of TrueType font 
tables to determine which pairs of Unicode codepoints end up using the 
same glyphs. The ASCII part of the table is included below. Each line 
has a codepoint, its glyph, the other codepoint of the pair, and the 
number of fonts in which that pair is identical.

U+2044 and U+2215 use the same glyph as the slash (U+002F) in a few East 
Asian fonts. Note also that the capital letters I and O have homographs, 
although some apps present domain names in lower case, so those 
homographs would stand out in those apps. For the complete table, see:

http://nameprep.org/tt-hg.html

Erik

0021(!);01C3;2
0022(");02BA;4
0022(");05F4;12
0027(');0060;1
0027(');02B9;4
0027(');05F3;12
0027(');2032;6
0028(();FD3E;3
0029());FD3F;3
002C(,);201A;9
002D(-);2010;12
002D(-);2012;1
002D(-);2013;2
002F(/);2044;3
002F(/);2215;4
(Continue reading)

Permalink | Reply | 1 comment |
headers
Erik van der Poel | 28 Mar 19:15

Re: Mac OS X Safari and IDN spoofing

I wrote:

 > The Japanese have been pushing very hard for IDN.
 > If you take a look at jprs.jp, ...

It has been pointed out to me that there is no "the Japanese" in this 
area, and that some of the individuals at JPRS may have opinions that do 
not necessarily match the opinions of some other Japanese people.

Also, JPRS appears to be distributing VeriSign's i-Nav IDN plug-in for MSIE.

Erik
Permalink | Reply | 0 comments |
headers
Paul Hoffman | 22 Mar 22:19
Picon
Gravatar

Mac OS X Safari and IDN spoofing

Another browser vendor's solution: 
<http://docs.info.apple.com/article.html?artnum=301116>.

--Paul Hoffman, Director
--Internet Mail Consortium
Permalink | Reply | 7 comments |
headers
Erik van der Poel | 18 Mar 19:39

list: productive discussion

All,

Apparently a mailing list called ietf-stringprep was started at one 
point, but there wasn't much discussion there, and most people just 
discussed it here (on the idn list) instead. Since there probably isn't 
enough interest in Stringprep to fork this list, I suppose I could 
continue discussing Stringprep here. In order to make it clear that I'm 
talking about Stringprep, I will insert "stringprep:" in the Subject 
header. Other insertions I will use are:

list: to discuss the use of the mailing list itself (like this email)

idna: to discuss IDNA and related topics (i.e. Nameprep, Punycode, 
registration/application/Unicode issues)

off-topic: to discuss other issues such as PAD, keywords, Real Names, 
Petnames, directories, searching, handles, etc

I will try not to talk about "off-topic" topics, since it is not a very 
productive use of this mailing list. The IDN Working Group has 
"concluded" and this mailing list is not moderated, so my Subject header 
insertions are purely a personal choice. It would be great if others 
used the same insertions, but of course that is a personal choice.

Thanks,

Erik
Permalink | Reply | 0 comments |
headers
Adam M. Costello | 16 Mar 23:13

IDNA section 3.1 requirement 3

Consider a domain name containing a slash-homograph.

As it stands, IDNA section 3.1 requirement 3 tells applications that
they "SHOULD" display the non-ACE form.  The security considerations
section, much later, "suggests" that applications provide visual
indications of various anomalies (from which one could extrapolate that
the slash-homograph would benefit from a visual indication).

I think we've seen that these security concerns need to be less buried,
that "visual indications" are too burdensome on implementations, and
that in some cases (like this one) the recommendation to display the
non-ACE form ought to be withdrawn, or even reversed (that is, recommend
the ASCII form).

There I propose a technical change to IDNA section 3.1 requirement 3.
For reference, here it is as it stands now in RFC-3490 (with one typo
corrected):

   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).
      Given an internationalized domain name, an equivalent domain name
      containing no ACE labels can be obtained by applying the ToUnicode
      operation (see section 4) to each label.  When requirements 2 and
      3 both apply, requirement 2 takes precedence.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Erik van der Poel | 16 Mar 19:40

Re: Re: stability

JFC (Jefsey) Morfin wrote:
> What are the objections (and BTW were to find described the consquences 
> for a Registry) to Adam and Simon positions?

In order to reach a rough consensus on any changes we make to the specs 
to address PRI #29, we should consider the consequences for the 
registries. PRI #29 claims that only a handful of characters are 
involved, but we may wish to confirm that. It may also be a good idea to 
write a program that the registries could use to see whether any labels 
containing such character sequences might have been Nameprepped and 
registered.

Erik
Permalink | Reply | 0 comments |
headers
Erik van der Poel | 16 Mar 19:11

Re: Re: stability

JFC (Jefsey) Morfin wrote:
> At 02:53 16/03/2005, Erik van der Poel wrote:
> 
>> Martin v. Löwis wrote:
>>
>>> What is much more relevant is how further constraints in the registry
>>> (beyond those imposed by IDNA) get implemented. Only when that is
>>> sufficiently settled and deployed, considering *updates* to IDNA
>>> should start.
>>
>> I disagree. The IETF should not wait for any of the registries to do 
>> anything before publishing new drafts or RFCs. The registries are not 
>> the only other players here. We have application developers and zone 
>> administrators depending on our work too.
> 
> Fully true. But we are in a real world. If you propose anything again 
> without the support of the Registries you will have a lack of 
> understanding, adherence and support. Also what you will propose will be 
> less reviewed from different point of view and will have more risks to 
> have its own flaws. You will not be able to tell the Registries they 
> shared in the mistake they have to share in the fix. 

I agree, and I can see why you react in this way to my email, but please 
look again at Martin's email. If we followed Martin's advice, we would 
wait quite a long time before even *considering* updates to IDNA. I 
think it's reasonable to *consider* changes and even to write drafts 
*before* the registries deploy further constraints.

Of course, we must involve the registries in the draft review process.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane