Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE label version 0.2

From: "James Seng/Personal" <[email-masked]>
Date: Sat, 28 Jul 2001 12:16:27 +0800

Lets do a test. This email is written in UTF-8.

U+529B in UTF-8 is 力
U+30AB in UTF-8 is カ

Does it look similar? Well, to a non-native maybe. To me, given that i
know some kana and some chinese (hopefully), it is not the same.

Perhaps some may say it "looks" totally different depending what UTF-8
fonts you have. Not to mention there are different written forms of
Chinese ideograph which ends up with different fonts. (For those
interest, should read z-Variant section of the Unicode book).

Now to make it more interesting, lets take this Chinese ideograph

U+65E5 in UTF-8 日
U+66F0 in UTF-8 曰

Same? Well, they are actually very very different meaning...and used in
different ways. (Notice the first one is 'thinner'? Yes, that is how it
is written, one fatter and one thinner)

Or make how about U+6046 and U+6052? Different? Well, they are used
similarly at least when we refer to hang shang bank of HK. (Depending
what IME you use, they produce U+6046 or U+6052).

And these are not even a complete list. Lets not forget about other
languages too.

Bottomline: This is not an easy task. We need to ask ourselves in IDN WG
if we have the right expertise to do this. Honestly, if you are saying
we normalized U+529B and U+30AB, neither Chinese nor Japanese would be
very happy about it.

-James Seng

>  For example, Katakana 'ka' (U+30AB) and Chinese letter 'power'
(U+529B).
>  look the same. We can assign  likenessindex 0 and 1 to 'ka' and
'power',
>  respectively.

---

From: David Hopwood <[email-masked]>
Date: Sat, 28 Jul 2001 04:06:25 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Soobok Lee wrote:
>   Let's assume we have a unicode  look-alike normalization NFLA in the
>   future version of the unicode standard.

That's a big assumption. AFAIK there are no plans to develop such a
normalisation format. Even if there were, waiting for it would unreasonably
delay deployment of IDNs, IMHO.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 27 Jul 2001 23:51:17 -0400

Soobok,

Your example of U+30AB and U+529B is clear, but as you mention, most
Han/Hangeul do not have look-alike characters.

Consider a hypothetical proposal to place distinct abstract character
repertoires in disjoint blocks in some equally hypothetical standard
coded character set, and assume that some character(s) have "look-alike"
correspondences in multiple disjoint blocks.

In particular, assume that in blocks i, j, and k, there exists code-points
for the characters A(i), A(j), and A(k), and that A(i) "looks-like" A(j)
and A(j) "looks-like" A(k).

Further assume that for this property of "similarity" or "borrowing" (at
least of the visual form) in each of these blocks is unlike the case in
Han/Hangeul (sparce), and most do have look-alike characters (dense). Is
there some point at which the "non-rarity" of "look-alike" would make a
scheme such as the one you've proposed cumbersome? If so, this could be
a constraint upon future modifications of a particular CCS.

Thanks for taking the time to think about this, I know it isn't what you
had in mind when taking on the Latin/Greek and Han/Hangeul similarities.

Eric

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 28 Jul 2001 11:43:44 +0900

Hi,
I post this new I-D to this mailing list to be reviewed  before
14/AUG. This I-D is somewhat half-baked, but helps to solve
the problems of look-alike characters with some pains.
I will repost the revised one next week.

Welcome any criticisms and supports for further discussions.

Regards,

Soobok Lee, [email-masked]

=========================================================================
Internet Draft                                              Soobok Lee
draft-lsb-lookalike-00.txt                        Postel Services, Inc
28 Jul, 2001
Expires in six months

        Safely Encoding of likeness information into ACE label
                        version 0.2

Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.

    Distribution of this document is unlimited.  Please send comments to
    the author [email-masked]

Abstract

  For a unicode character which has one or more other look-alike characters,
  we define both its look-alike normalization form and a likeness index and
  suggest new ACE prefixing rule for likeness indices which are encoded using
  a sequence of mixed-case latin alphabets. The likeness index is used to
  restore the pre-normalization form of the ACE-decoded label and in the same
  time does not affect case-insensitive label comparison 
  in existing applications and DNS servers.

Contents

 Overview
 ACE comparison
 Maximum length of ACE label
 Implication of restoring pre-normaliation forms
 More works to be done
 Security considerations
 References
 Author

Overview

 The Unicode Standard has many sets of look-alike characters that are not
 documented in detail yet. But introducing the unicode characters set
 into IDN, the primary internet identifier, require some rigorous works
 to be done in this area near future for security reasons.

 ACE algorithms such as [DUDE],[AMC-ACE-Z], preserve the case information
 in the original IDN label by augmenting base32 latin digits to their
 uppercase ones, which do not affect case-insensitive label comparison
 operations in applications and DNS servers, while preserving the case
 information.

 This draft is based on such case-preserving and case-insensitive nature
 of IDNA architecture and extends them to fullful the need to map
 look-alike letters into a unified one while retaining the information
 about the pre-unification letter for later rendering of ACE-decoded
 labels for end users.

  Let's assume we have a unicode  look-alike normalization NFLA in the future
  version of the unicode standard.

  For certain unicode points a1,a2,a3 that satisfy
     NFLA(a1) ==NFLA(a2)  == NFLA(a3) == a1.
  let's define a function LA_SET(uc) so that:
     LA_SET(a1)={a1,a2,a3}

  In this case
     the size of LA_SET(a1) is 3, is called 'current minimal likeness size',
 
  We shoud define 'maximal likeness size' for each unicode point. 
  For that, we define a function LikeSize(uc) so that
     LikeSize(a1) = 4, LikeSize(a2)= 4, LIkeSize(a3)=4.

  It is wise to choose 4 instead of 3  to make room for future additions 
  to UNICODE repertoire of scripts that may contain new look-alike characters.
  We need to look carefully into proposed or approved new scripts to be added
  unicode standards near future.

  We can express a1,a2,a3  as  these binary tuples
   a1=(a1,0)
   a2=(a1,1)
   a3=(a1,2)
  The each second index value of these tuples is called 'likeness index',
  for which we define a function so that
    LikeIndex(a1) =  0,
    LikeIndex(a2) =  1,
    LikeIndex(a3) =  2.

  Let's define a function
    LA_TUPLE(uc) = ( NFLA(uc), LikeIndex(uc), LikeSize(LA_SET(uc))  ).

  Let's define a restoring function LA_CHAR(uc,i)  so that:
    LA_CHAR(a1,0)=a1,
    LA_CHAR(a1,1)=a2,
    LA_CHAR(a1,2)=a3.

 The main idea of this draft is to incorporate the ascii encoded likeness
 index and likeness size of a ambiguous character of a IDN label
 using a sequence of uppercase and lowercase latin alpahbets inserted after
 ACE prefix.

 For example, for an cyrillic IDN label <cyrillic a><cyrillic zhe><cyrillic o>:
 we have a ACE label without looka-like normalization of

    dq--{<cyrillic a>}{cyrillic zhe}{<cyrillic o>}

 Only cyrillic 'a' and 'o' has latin look-alikes, so that we can make
 new ACE label WITH  looka-like normalization

    dq--AaCcC--{<latin a>}{cyrillic zhe}{<latin o>}

 The uppercase letters in "aAcCc" denote bit '1' and
 lowercase letters denote bit '0' and these sequence of uppercase and lower
 case letters of a alphabet form a bitstring to denote the likeness index.
 The alpabet (a-z) denotes the offset index of the corresponding unicode
 character in the IDN label character sequence.

 In the example above, "aA" denote a likeness index value 1 and a likeness
 size 4. "cCc" denote a likeness index value 2 and a likeness size 8.
 "aA" supplements to <latin a> to form <cyrillic a> and
 "cCc" supplements to <latin o> to form <cyrillic o>.
 <cyrillic zhe> has no case information since it is assumed to have no
lookalike..

 2^(The number of repeated alphabets) is identical to the likeness size and
 shall be large enough not to be changed in future version of unicode
 look-alike normalization.

 If the offset index of a long IDN label needs to exceed 26, we can insert
 un-used digit '9' to mark a milestone from which the offset is added by 26
 and the alphbet should begin with 'a' again.

 If applications and dns server would not casefold ACE label, this
 look-alike information would be retained throught the process to
 restore the pre-normalization native-script.

 The restoring process is as follows:

  First,
   we ACE-decode the label part of our new ACE label and get
   a sequence of unicode points LABEL.

  Second,
   from likeness indices part of our new ACE label, we construct
   a array of binary tuples of likeness index and offset index of
   target character into the decoded label LABEL.

  Third,
   for each binary tuple (i,offset), we replace each target
   code point in the decoded label LABEL with the restored original
   character LA_CHAR(LABEL[offset],i).

ACE comparison

  We have three IDN labels like these:

    IDN1 =  <cyrillic a><cyrillic zhe><cyrillic o>
    IDN2 =  <latin a><cyrillic zhe><cyrillic o>
    IDN3 =  <latin a><cyrillic zhe><latin o>

    ACE(IDN1)  =  dq--aAcCc--{<latin a>}{cyrillic zhe}{<latin o>}
    ACE(IDN2)  =  dq--aacCc--{<latin a>}{cyrillic zhe}{<latin o>}
    ACE(IDN3)  =  dq--aaccc--{<latin a>}{cyrillic zhe}{<latin o>}

  IDN1,IDN2,IDN3 are equivalent modulo look-alike normalization,
  but these three ACE labels have differently-cased likeness indices,
  but are regarded as the same domain in case-insensitive comparison
  in applications and dns servers.

  If a IDN has no ambiguous characters, we can omit '--' in some ACEs.

   IDN4 =  <cyrillic zhe><cyrillic zhe>
   ACE(IDN4)  =  dq--{<cyrillic zhe>}{cyrillic zhe}

  And if an IDN is look-alike normalized into all-latin LDH domain,
  it should not be registered as a IDN but as an LDH domain, and in
  this case, we cannot provide likeness preservation.

Maximum length of ACE label

 This new scheme comes with some overheads in ACE label :
   additional "--" and encoded likeness informations.

 If we assume the mean average of likeness size to be 2 (1 bit):
   overhead  = 2 + 1 * (number of ambiguous characters in a label)

 Since most Han/Hangeul letters have no other look-alike characters,
 Overall ACE label efficiency for han/hangeul would not be affected.

 Latin,Greek,Cyrillic,Katakana and many Indian scripts have
 many look-alike characters.

 Efficient ACE-encoding of IDN label is required for this scheme.

Implication of restoring pre-normalization forms

 This new ACE prefixing scheme retains the look-alike information,
 so that we can restore the original native-script labels before
 look-alike normalization even when they contain  look-alike characters
 across scripts.

 For example, Katakana 'ka' (U+30AB) and Chinese letter 'power' (U+529B).
 look the same. We can assign  likenessindex 0 and 1 to 'ka' and 'power',
 respectively.

 If we normalized 'ka' into 'power' without encoded case information,
 we could not restore 'ka' anymore. We could not avoid font-rendering
 problems and conflicts of interests between related countries.

 But, with this encoded likeness information, we can restore 'ka'
 and we have no such problem.

More works to be done

 Some sequences of characters look similiar to a character or
 other sequences of characters.

 Most of these sequences are normalized and unified in KC
 Normalization in NAMEPREP. But still some visual similarities
 are not completely eliminated.

 We need more elaborations on this subject.

Security Consideration

 These scheme suggests ACE labels to be prefixed  by additional
 look-alike information encoded in sequences of cased alphabets
 and does not introduce any security hole into IDN.

References

    [UNICODE] The Unicode Consortium, "The Unicode Standard",
    http://www.unicode.org/unicode/standard/standard.html.

    [IDNA] Patrik Faltstrom, Paul Hoffman, "Internationalizing Host
    Names In Applications (IDNA)", draft-ietf-idn-idna-03.

    [NAMEPREP03] Paul Hoffman, Marc Blanchet, "Preparation
    of Internationalized Host Names", July 19, 2001
    draft-ietf-idn-nameprep-05.

    [DUDE02] Mark Welter, Brian Spolarich, Adam Costello,
    "DUDE: Differential Unicode Domain Encoding", 2001-May-31,
    draft-ietf-idn-dude-02.

    [AMCACEZ] Adam Costello, "AMC-ACE-z version 0.2.1",
    2001-May-31, draft-ietf-idn-amc-ace-z-00, latest version at
    http://www.cs.berkeley.edu/~amc/charset/amc-ace-z.gz

Author

    Soobok Lee <[email-masked]>
    Postel Services, Inc.
    http://www.postel.co.kr
    Tel: +82-11-9774-2737

---

From: "Soobok Lee" <[email-masked]>
Date: Sun, 29 Jul 2001 15:50:54 +0900

----- Original Message ----- 
From: "James Seng/Personal" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; <[email-masked]>
> U+65E5 in UTF-8 ??
> U+66F0 in UTF-8 ??

Even If we normalize U+6046 into U+6052 ( or U+30AB -> U+529B ),
my I-D's likeness encoding will allow recover U+6046 (or U+30AB) 
as long as applications do not casefold the produced ACE label.

Likeness encoding prohibits  look-alike domains to be registered automatically
, while it allows  multiple representations of an IDN to be typed in and 
interchanged and displayed. 

With likeness encoding, look-alike normalization is not so expensive.
 
> if we have the right expertise to do this.   

I agree it will take much time.  
But I oppose to give birth to "immuno-deficient" premature IDN standard.
We or other relevant organizations should hurry up for it. 

Soobok Lee

---

From: "James Seng/Personal" <[email-masked]>
Date: Mon, 30 Jul 2001 12:26:45 +0800

Okay folk.

I have recieved some offline comments that this topic on "look-alive" is
way out-of-scope for the IDN WG, which I agree, I have to kill this
topic on the wg. I think it is inappropriate to continue this discussion
given that it is not within the Pool and beyond the charter for this wg.
We should focus on what is in the Pool and to build consensus around it.

Therefore, I would appreciate if this discussion would be carried
off-line with the author or to some other forum (suggestion: try Unicode
Consortium) on the topic of normalization of "look-alive" characters.

The portion of this work that does related to IDN is probably the
security concern of "look alike" characters. If the authors is still
interested to pursue this within the idn wg, then I would suggest the
draft to be modified to be an investigation of the security impacts.

Thanks!

-James Seng

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 30, 2001 12:01 PM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into
ACE label version 0.2

> Soobok Lee <[email-masked]> wrote:
>
> > Even If we normalize U+6046 into U+6052 ( or U+30AB -> U+529B ), my
> > I-D's likeness encoding will allow recover U+6046 (or U+30AB) as
long
> > as applications do not casefold the produced ACE label.
>
> Today's ASCII domain names already allow visually similar characters
> that don't match (0O 1lI 2Z 5S 6G) and people have lived with it for
> a long time, so I don't think we should feel obligated to eliminate
> this problem in IDNs, especially if it means significantly increasing
> complexity and decreasing efficiency, which it appears to do.
>
> AMC
>

---

From: "Adam M. Costello" <[email-masked]>
Date: Mon, 30 Jul 2001 04:01:19 +0000

Soobok Lee <[email-masked]> wrote:

> I-D's likeness encoding will allow recover U+6046 (or U+30AB) as long

AMC

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 30 Jul 2001 13:41:30 +0900

----- Original Message -----
From: "Adam M. Costello" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 30, 2001 1:01 PM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

> complexity and decreasing efficiency, which it appears to do.
Choosing a disambiguating  font may eliminate such similarities. But,
We should not forget the problem around borrored glyphs that look identical.
Cherokee 'A' and Latin 'A' and latin 'a' and cyrillia 'a' look identical than
look similiar.
I haven't ever seen any identifier system that has duplicate  atoms (in BNF):
  IDN   :=  (atom)+
  atom :=   'a'|'a'|'a'|'b'|'b'|'c'|'c' ......

Soobok Lee

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 30 Jul 2001 19:51:10 +0900

----- Original Message -----

>. If the authors is still

Security impacts of premature IDN on the global  internet  may  be
Deep and Disastrous.

1) facillitate  DNS spoofing

    Anyone can get  <russian a>ol.com  from the registry if lucky and make a
spoofing site easily.
    they no more  need to  hire a hacker for rocket-science DNS hijacking .

2) easy impersonation attack on  email addresses

    From: V<cherokee i>ntCerf@ic<Cyrillic a>nn.org
    To:  [email-masked]
    Subject:  I oppose MD!

    From: m<greek o>[email-masked]
    To:   [email-masked]
    Subject: i am your mom.  I lost my creditcard, let me know your card#.

3) defeat anti-spoofing efforts like DNSSEC

   anyone can get  the valid certificate issued  for his scam email address/site
name.

4) more on my next draft

Soobok Lee

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 31 Jul 2001 08:58:07 +0900

Hi, Eric

For pure Han labels (150,000 sample domains),
  the mean average # of distinct code points is roughly the same as
  # of code points in the label. i.e. most of letters are distinct.

For Latin (European ) labels ( in 44000 sample domains)
  the mean average # of distinct code points is roughly HALF of
  # of code points.
  We need only one lookalike encoding for a distinct code point.
  I guess only half or two-thirds of them are look-alike ones.

This will partly answer for some of your questions.

Look into ATOM# columns of the next statistics if you have time. :-)

Soobok Lee
------------------------------------------------------------------------

For .Latin

N:            length of a domain label ( # of code points)
FREQ:         number domains of length N
N*FREQ:       sum of # of code points of domains of length N
SUM OF AMCZ:  sum of lengths of AMCZ labels
X:            SUM OF AMCZ / N * FREQ
SUM OF LAMCZ: sum of lengths of LAMCZ labels
Y:            SUM OF LAMCZ / N * FREQ
COMP:         (SUM OF LAMCZ - SUM OF AMCZ) / SUM OF AMCZ * 100
ATOM#:        MEAN AVERAGE of # of DISTINCT ATOMS

|  N|    FREQ|    N*FREQ|  SUM OF AMCZ(X)| SUM OF LAMCZ(Y)| COMP| ATOM#

|  1|      85|        85|       169(1.99)|       169(1.99)|0.00|1.00
|  2|    1026|      2052|      4031(1.96)|      4031(1.96)|0.00|1.96
|  3|     993|      2979|      4954(1.66)|      4954(1.66)|0.00|2.84
|  4|    1730|      6920|     10440(1.51)|     10440(1.51)|0.00|3.81
|  5|    3089|     15445|     22020(1.43)|     22020(1.43)|0.00|4.75
|  6|    3760|     22560|     30529(1.35)|     30529(1.35)|0.00|5.57
|  7|    4134|     28938|     37669(1.30)|     37669(1.30)|0.00|6.32
|  8|    4405|     35240|     44532(1.26)|     44532(1.26)|0.00|7.02
|  9|    4286|     38574|     47653(1.24)|     47653(1.24)|0.00|7.73
| 10|    4027|     40270|     49106(1.22)|     49106(1.22)|0.00|8.33
| 11|    3523|     38753|     47178(1.22)|     47178(1.22)|0.00|8.89
| 12|    2777|     33324|     40538(1.22)|     40538(1.22)|0.00|9.43
| 13|    2325|     30225|     36672(1.21)|     36672(1.21)|0.00|9.96
| 14|    1928|     26992|     32752(1.21)|     32752(1.21)|0.00|10.44
| 15|    1537|     23055|     27801(1.21)|     27801(1.21)|0.00|10.86
| 16|    1276|     20416|     24422(1.20)|     24422(1.20)|0.00|11.24
| 17|    1029|     17493|     20741(1.19)|     20741(1.19)|0.00|11.68
| 18|     776|     13968|     16438(1.18)|     16438(1.18)|0.00|12.05
| 19|     588|     11172|     13057(1.17)|     13057(1.17)|0.00|12.40
| 20|     429|      8580|      9956(1.16)|      9956(1.16)|0.00|12.67
| 21|     296|      6216|      7146(1.15)|      7146(1.15)|0.00|12.93
| 22|     177|      3894|      4476(1.15)|      4476(1.15)|0.00|13.20
| 23|     116|      2668|      3032(1.14)|      3032(1.14)|0.00|13.59
| 24|      65|      1560|      1772(1.14)|      1772(1.14)|0.00|13.40
| 25|      67|      1675|      1899(1.13)|      1899(1.13)|0.00|14.16
| 26|      36|       936|      1054(1.13)|      1054(1.13)|0.00|13.53
| 27|      29|       783|       880(1.12)|       880(1.12)|0.00|15.00
| 28|      10|       280|       317(1.13)|       317(1.13)|0.00|14.60
| 29|      10|       290|       321(1.11)|       321(1.11)|0.00|18.30
| 30|       7|       210|       231(1.10)|       231(1.10)|0.00|14.14
| 31|       7|       217|       243(1.12)|       243(1.12)|0.00|19.00
| 32|       9|       288|       321(1.11)|       321(1.11)|0.00|15.67
| 33|       4|       132|       146(1.11)|       146(1.11)|0.00|18.50

For .Unihan

N:            length of a domain label ( # of code points)
FREQ:         number domains of length N
N*FREQ:       sum of # of code points of domains of length N
SUM OF AMCZ:  sum of lengths of AMCZ labels
X:            SUM OF AMCZ / N * FREQ
SUM OF LAMCZ: sum of lengths of LAMCZ labels
Y:            SUM OF LAMCZ / N * FREQ
COMP:         (SUM OF LAMCZ - SUM OF AMCZ) / SUM OF AMCZ * 100
ATOM#:        MEAN AVERAGE of # of DISTINCT ATOMS

|  N|    FREQ|    N*FREQ|  SUM OF AMCZ(X)| SUM OF LAMCZ(Y)| COMP| ATOM#

|  1|    3735|      3735|     14940(4.00)|     14940(4.00)|0.00|1.00
|  2|   42793|     85586|    322222(3.76)|    289658(3.38)|10.11|1.99
|  3|   28033|     84099|    295183(3.51)|    256250(3.05)|13.19|2.98
|  4|   54607|    218428|    740073(3.39)|    608569(2.79)|17.77|3.98
|  5|   12591|     62955|    208185(3.31)|    167839(2.67)|19.38|4.97
|  6|    7680|     46080|    149606(3.25)|    116532(2.53)|22.11|5.95
|  7|    2761|     19327|     61992(3.21)|     47043(2.43)|24.11|6.94
|  8|    1336|     10688|     33890(3.17)|     25154(2.35)|25.78|7.83
|  9|     641|      5769|     18131(3.14)|     13383(2.32)|26.19|8.86
| 10|     298|      2980|      9260(3.11)|      6821(2.29)|26.34|9.72
| 11|     137|      1507|      4712(3.13)|      3330(2.21)|29.33|10.79
| 12|      57|       684|      2114(3.09)|      1569(2.29)|25.78|11.40
| 13|      25|       325|      1008(3.10)|       760(2.34)|24.60|12.44
| 14|       6|        84|       259(3.08)|       187(2.23)|27.80|13.17
| 15|       6|        90|       272(3.02)|       199(2.21)|26.84|14.50
| 17|       1|        17|        49(2.88)|        33(1.94)|32.65|16.00

|   |  154707|    542354|   1861896(3.43)|   1552267(2.86)|16.63|

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Saturday, July 28, 2001 12:51 PM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 30 Jul 2001 20:56:28 -0400

I agree with the co-chair's conclusion that the subject matter itself is
outside of the scope of the working group.

Fundamentally, the issue that is the subject of "look-alike" discussion is
elements of an abstract character repertoire within a coded character set,
which have a property of visual similarity. From a broad scripts frame of
reference, e.g., "Han Unification", to a macro-scale "things that look like
circles", to the micro-scale of individual characters, this is the work of
bodies which create abstract character repertoires and coded character sets.

It would hardly matter if such a draft was "in the pool" or not.

I don't agree with the suggestion made by the co-chair that perhaps there
is a security concern for "look-alike" characters.

In the requirements draft, section 3 (Security Considerations) there is the 
hopeful statement that "a solution" not be "less secure" than the current
DNS. Skipping over the minor problem that this may be an underspecification,
hostname-based authentication is historic (and inachievable, hence dnssec),
and invocation of identd is ... unusual in the normal course of app/resolver
/transport/nameserver/transport/app sequences.

The existance of "misleading identifiers" formed with an extended repetoire
(independent of whether elements of the extended repetoire are transported
in encapsulated, or native forms) appears to require that two or more "near"
(Hamming distence) identifiers exist.

A protocol that is capable of signaling the existence of name proximality
is something other than the DNS. That protocol, whatever it is, can have a
"Security Considerations" section that treats the subject of minimal Hamming
distance (or any other form of similarity metric), hence some property that
relates to authentication et al, and "misleading identifiers", hence of
"look-alike" characters.

So, after all this (which I'm sorry to say took me much longer to write than
for many to read), I think "safely encoding" is not "safe", and we should
not do "encoding".

Eric

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 31 Jul 2001 13:10:07 +0900

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, July 31, 2001 9:56 AM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

> /transport/nameserver/transport/app sequences.
DNSSEC is low-level protocol, hidden from human eyes.
HTTPS and SMIME depends on end users' spontaneous association of
verified signature with the displayed i18n-identifier which could contain
misleading <cyrillic a>ol.com.

> relates to authentication et al, and "misleading identifiers", hence of

Yes, some parents who give birth to premature babies, should have employ
machine incubators for protecting their babies from infections by bacteria.

Then, let's make a IDN incubator protocol... :-))

> for many to read), I think "safely encoding" is not "safe", and we should
I don't care for that... The half-baked I-D only took a few hours
from conception to finalization....

Thanks for your criticisms.

Soobok Lee

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 31 Jul 2001 08:07:33 -0400

Soobok,

There is a difference between altering the assocation between a name and an
address, whether this operation is performed with global or local scope, and
creating an association beteen a name and another name.

The first is an integrity problem for the DNS, the second is a disambiguation
problem for something other than the DNS.

Eric

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 31 Jul 2001 22:04:06 +0900

Eric,

 If my favorite internet  phone company ever  issue two  internet phone numbers:
   1)   254-5628   ( all latin digits )
   2)   254-5628   (8  is Bengali '4'  )
 for two distinct entities,
 We can say the integrity of the number system is already severely flawed , even
before
 the first  innocent victim takes 2) for 1) and actually makes a dangerous phone
call.

 Uniqueness of identifiers depends partly on human mental distinction between
names.
 For the blind, even the 'a.com' and 'x.com' displayed on the screen , do not
provide
 any clues for mutual distinction.

 DNS contains the core internet identifier system which MUST provide  name
 uniqueness to audiences from diverse cultural and educational backgrounds ,
 while the global network of DNS protocol implementations adds universality .

Soobok

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 31, 2001 9:07 PM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 31 Jul 2001 09:40:04 -0400

Soobok,

I'm glad you mentioned the access issue (visual impairment, aka "blind"), as
this is an area where the W3C has some interesting work.

Eric
(wearing a W3C hat)

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 31 Jul 2001 06:56:47 -0700

This is a pipe-dream. See my messages of
Wednesday, July 18, 2001 09:45
Thursday, July 19, 2001 08:20

One might be fooled by how easy it is to come with with a simple list
between two scripts, such as Greek and Latin. But then the complications
arise: are rho and p to be considered confusable? Then there are extended
characters, like Latin small letter open e (ɛ) and epsilon (ε).  You rapidly
(I almost wrote "rabidly") slide off into gray areas even with just two
scripts. When it comes to comparing all the characters of the world, in many
combinations of fonts, the problem quickly becomes intractible.

We have had a lot of experience dealing with huge numbers of characters. It
is harder than it looks.

Mark
—————

πάντων μέτρον ἄνθρωπος — Πρωταγόρας
[http://www.macchiato.com]

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 31, 2001 06:04
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

> Subject: Re: [idn] new I-D: Safely Encoding of likeness information into
ACE

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 31 Jul 2001 10:25:46 -0400

> Thursday, July 19, 2001 08:20

Those were good reading. I enjoyed the font example. I look forward to
stuffing 1x1 pixel gifs into <urk> HTMLized </urk> email, particularly
around what appear to be domain names.

...
> We have had a lot of experience dealing with huge numbers of characters.

The "We" here is the UTC, and other character standards body participants and
character rendering/processessing implementors. Not the run-of-the-mill IETF
contributors. Which is my first point:
	this is the work of bodies which create abstract character
	repertoires and coded character sets

> It is harder than it looks.

And it isn't DNS. We could be playing this game with:

	a) any system using all of ASCII, (What do unprintable characters
	   look like?)
	b) any system using all of 8859-*, (Ditto plus Latin/Greek)
	c) any system using just about any 8-, 15-, or 16-bit encoding,
	   whether of propriatary, national, or international origins,
and
	d) any system that "discovered" and "negociated" encodings, e.g., 
	   any of a), b), and c) above,
as well as
	e) Unicode.

Which is my second point:
	A protocol that is capable of signaling the existence of name
	proximality is something other than the DNS.

Eric

P.S. Someone, in the spirit of i18n-friendliness, changed the sanity check
     in Solaris 2.3 syslogd from isprint() to isascii(). I unpatched it. 
     I'll pay one beer to the first person who correctly identifies the
     real bug. Hint: Its a real security bug, has little to do with any
     specific Un*x, and is related to C0 Controls.

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 31 Jul 2001 23:31:15 +0900

Mark,

How about recommending a disambiguaing  full-unicode-wide reference font set
for IDN
with the best font size in IETF implementation guidelines for IDN-aware
OS/application vendors ?
The font set will help to reduce the list of pairs of ambiguous characters to be
compared,
and encourge all application vendors to adopt  it as the default IDN font.
For example, Greek 'rho' and latin 'p' may  look very different in that font,
while
Cyrillic 'a' (borrowed from latin 'a') and Latin 'a' may still look identical.
Then
we need normalize only 'a' s.

Do think this is feasible ?

 I found  http://www.unicode.org/charts already uses such good font. Is the font
for public domain?

Soobok

----- Original Message -----
From: "Mark Davis" <[email-masked]>
To: "Soobok Lee" <[email-masked]>; "Eric Brunner-Williams in Portland Maine"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 31, 2001 10:56 PM
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 31 Jul 2001 08:31:06 -0700

Such a disambiguating font is certainly possible, and one of the possible
approaches to GUI-assists. What we could do is add text to IDNA to recommend
that domain names be displayed in such a way as to disambiguate confusibles.

Mark
—————

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: "Mark Davis" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, July 31, 2001 07:31
Subject: Re: [idn] new I-D: Safely Encoding of likeness information into ACE
label version 0.2

ACE
> > We have had a lot of experience dealing with huge numbers of characters.
It

---

From: "Soobok Lee" <[email-masked]>
Date: Wed, 1 Aug 2001 00:48:46 +0900

In summary, I suggest two principles:

  -  disambiguate as many look-alike letters as possible
       only by assistance of  reference fonts and GUIs

  -  normalize as few look-alike letters as possible :
      - only these cases for _identical_ glyph:
        - borrowed glyph
        - sibling glyphs from the same origin

Any constructuve modfication wanted...

Soobok Lee