Subject: Re: [idn] IDN security and ACE leakage

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

I think ACE is convenient utf8-replacement to improve  universal
verifiability of  internet identifiers, since it can be restored to
 its utf8 (sometimes undisplayable or unrecognizable or
 undistinguishable) string and also provides ascii compatible 
(ugly but always verifiable ) labels while assuring backward 
compatiblities to existing DNS infrastructures.

We cannot enforce all the peoples in the world to learn every 
scripts/glyphs in unicode code charts. 
They are not all geniuses for languages.

I believe ACE will  be not deprecated and will remain forever as an
auxiliary common-denominator display format of internet 
identifiers as well as one of viable zone file formats and 
wire formats.  shorter ACE labels always benefit.

ACE is another "utf-8" for identifiers, not an inferior interim 
encoding. It deserves its overhead for improving  identifier  security.

Soobok Lee

----- Original Message -----
From: "Soobok Lee" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 16, 2001 10:26 AM
Subject: Re: [idn] IDN security and ACE leakage

>
> ----- Original Message -----
> From: "Martin Duerst" <[email-masked]>
> > >How can we distinguish  katakana 'ro-to.com' and hangul 'ma.com'
> > >if we haven't learn japanese and korean ?
> >
> > Well, the main point will be spacing. There are also other font
> > differences. But these are made for people who write katakana or
> > hangul, not for those that don't.
> >
> In most cases, the problems come from the similarities, not from spacing.
>
> katakana 'ka' and chinese letter 'power(U+529B)' look the same.
> Bengali numeral '4'  and latin '8' look the same.
>
> What if japanese or korean customers send us with their IDN-email
> addresses  and we don't know japanese and korean letters and their
> spacing semantics ?
>
> Still I cannot distinguish between Bengali numeral '4' and latin '8'.
>
> How can we prevent malicious attempts to
> forge similiarly-looking but different domains ?
>
>
>
> >
> > Regards,   Martin.
> >
>

---

From: Martin Duerst <[email-masked]>
Date: Mon, 16 Jul 2001 14:36:15 +0900

>They are not all geniuses for languages.

Agreed. It is impossible to require e.g. from average
Koreans or Japanese to be able to use Arabic domain names,
exactly the same way it is impossible to ask them to
read an Arabic newspaper or an Arabic email or web page.

ACE is a very bad fallback for all these purposes.
Ideally, every person should at least have one purely
ASCII-only email address, and every machine should have
at least one purely ASCII-only domain name, not consisting
of characters that look like they come from a random generator.

Regards,   Martin.

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 16 Jul 2001 15:06:12 +0900

I believe IDN is not only for local use, but also
for international exchange of identities and infor-
mations. I  believe most of them will surely use 
only IDN email addresses.

Enforcing dual email addresses 
(one using LDH domain and the other using IDN ) 
may be a (costly) remedy for such situations.

How can we enforce them?  Is it possible ?
How can they decide when and to whom they
should choose IDN email addresses over LDH ones?

They may   inadvertently or intentionally 
send emails using their Arabic email addresses 
while email contents are  in english or japanese.

Soobok Lee

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 16 Jul 2001 18:41:23 +0200

> of characters that look like they come from a random generator.

I don't agree.

If people said this about some arabic script to me, I would not be able to
know the difference between a random generated string in arabic compared to
something which makes sense to people which know arabic (something I don't
do).

I much rather be able to use my name, which I have chosen, in my script, in
applications I have chosen, and then some magic which is implemented in the
network which makes it possible for others to reply to my email.

If I have upgraded my software to be able to handle whatever IDN is coming
up with, I should never have to see the encoded characters which are passed
in the protocols -- regardless of if it is UTF-8 or ACE or whatever.

As a user I don't care.

I want it to work. And to make it to work for users, we engineers have to
be extremely conservative, and as you have understood by now, I don't care
if some of you think I am stupid asking for something as stupid as ACE when
UTF-8 is better. I am conservative, belive nameprep is by far more
important than what encoding we use, and IF we should do something smart,
we should use neither UTF-8 nor ACE in DNS, but instead something much more
efficient given the binary labels we already have in the DNS protocol.

But, as applications take the uncompressed data in the DNS protocol and
"just" use it here and there, we need to see that that data is safe in
whatever (stupid) application there is. If I have upgraded my applications,
I am done. I will never see this encoding stuff anymore. Just like with
quoted-printable in MIME. Do you see QP somewhere? Maybe in headers of
email? Maybe even this email? Then you have broken software, but is that my
fault? Maybe because I did choose to use a charset you can not support, and
that is a valid issue, but if you DO handle the charset, or if you don't,
how do your client handle that situation? _Those_ situations are what we
should talk about and not this smalltalk about "my software is better than
yours".

   paf

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 17 Jul 2001 08:24:50 +0900

----- Original Message -----
From: "Patrik F?tstr?" <[email-masked]>

> should talk about and not this smalltalk about "my software is better than

Could NAMEPREP elminate all the script/glyph ambiguities across
languages?

katakana 'ka' and chinese letter 'power(U+529B)' look the same.
When we normalize them in either directions, there may be conflict of
interests between  Japan and China.

Soobok Lee

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 17 Jul 2001 06:06:04 +0200

--On 01-07-17 08.24 +0900 Soobok Lee <[email-masked]> wrote:

>> should talk about and not this smalltalk about "my software is better
>> than yours".
> 

I have not claimed nameprep do solve all problems, but, we have agreed on
this list that what is needed for interoperability is that everyone uses
the same algorithm when doing nameprep, and that that should be applied
before strings are compared.

Now, if you are unhappy with the current definition of nameprep, please
come with suggestions on how it can be approved.

  paf

---

From: Martin Duerst <[email-masked]>
Date: Tue, 17 Jul 2001 17:52:16 +0900

>something which makes sense to people which know arabic (something I don't

Your example of Arabic may apply to some cases of people not having any
idea about Latin, but in general, Greek is a much better example.
Your knowledge of Greek letters is most probably much closer to
the average knowledge of Latin by somebody who doesn't use it as
their everyday script. If you had to use Greek in your email,
would you prefer it to use some appropriate letters, or would you
not care and just think random is as good as anything?

>network which makes it possible for others to reply to my email.

If it's just about email replies, then MIME may already be enough
(assuming it's really implemented; not like what my mailer is doing :-(.
[For the web, the eqivalent is following a link.]

The main problem is getting the email address from the business card
to the MUA, or getting the web address from the product pamphlet,...
to the browser. For that, you may want to have an Arabic email address
if you are doing business in the Arabic region, even if you don't
speak a word of Arabic. And you will be wise to at least have an
ASCII-only email address, so that your business partners don't have
to try to get the special characters right. That's just a matter
of courtesy and common sense, and I don't think that will change
much with idn.

>in the protocols -- regardless of if it is UTF-8 or ACE or whatever.

Agreed, except for wording. You would never want to see anything except
the encoded characters, regardless of whether the encoding is UTF-8 or
ACE or whatever.

>important than what encoding we use,

I think you take nameprep a tiny bit too serious. See my other mail.

>and IF we should do something smart,

Something like gzip on top of SCSU on top of frequency reordering
or so? Squeezing the last drop of inefficiency out of these labels.
Having the WG spend a few more years on the 'who's ace is better'
game? Or did I misunderstand you?

>should talk about and not this smalltalk about "my software is better than

MIME was a pain for a long time. Where it still is a pain (including
my mailer), that may be blamed on the implementation. But the years it took
to reasonably deploy MIME cannot be blamed on any implementation, they have
to be blamed on MIME itself.

What you are saying is that because we have suffered with MIME, we can
suffer another time. We are in a much better position now (Unicode and
UTF-8 wasn't really an option when MIME was created), and that we should
not repeat the mistakes we know from the past. Just sending something
off and not caring about whether the recipients can really see it
or not (which is the basic idea behind ACE) is not a good idea.
If a specific protocol wants to work on that base, we may just
close our eyes. But to make it the central assumption on the
central infrastructure is a bad idea.

Regards,   Martin.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 17 Jul 2001 11:44:20 +0200

--On 01-07-17 17.52 +0900 Martin Duerst <[email-masked]> wrote:

>> If I have upgraded my software to be able to handle whatever IDN is
>> coming up with, I should never have to see the encoded characters which
>> are passed in the protocols -- regardless of if it is UTF-8 or ACE or
>> whatever.
>> 
>> As a user I don't care.
> 

My point is that as a user, I think there are two things that should work:

(a) When I have upgraded my own applications, I should see the real glyphs
on my monitor, my cut and paste should work, and I should be able to input
domainnames with whatever mechanism I choose. I don't care what encoding is
used for the glyphs when they are moved over the wire.

(b) When I send an email to someone which have NOT upgraded their software,
or via someone which have not upgraded their software, that other person
should get the email, and should be able to reply.

>> we should use neither UTF-8 nor ACE in DNS, but instead something much
>> more efficient given the binary labels we already have in the DNS
>> protocol.
> 

You exaggerate. We _do_ have problems with the size of the DNS packets.
Especially when we are trying to do DNSSEC. Because of this, what is stored
in the DNS packet, if the larger packet should be flagged with EDNS0.5
stuff for new content or whatever else is something I feel is not a task of
this wg to decide on.

I.e. that you as a member of this group didn't acknowledge the lack of
space in DNS packets show that probably someone else should look at this
problem?

So, in some form you are correct, I am talking about doing a more efficient
encoding as what is used there most certainly not will be used in
application layer protocols (at least not to start with). Some protocols
can be changed to use UTF-8 pretty quickly, but maybe other rather use
something else.

> my mailer), that may be blamed on the implementation. But the years it
> took to reasonably deploy MIME cannot be blamed on any implementation,
> they have to be blamed on MIME itself.

Point of clearification: I didn't pick mime just because I know your mailer
is not upgraded Martin.

> suffer another time.

No, what I am saying is that email works even though software is still not
upgraded just because MIME is 100% backward compatible.

> We are in a much better position now (Unicode and

Well, you seem to argue for "just send UTF-8" and do not care about whether
the recipient can even do a reply to the mail.

I.e. both you and I use the same argument here, but for different "layers".

You say that something is broken if the recipient do not see the correct
glyphs. I say that something is broken if the recipient can not do reply
(or even see the email), but think that things work if the recipient see
the ACE encoding.

The good thing with IDNA and ACE is that it is 100% compatible with what is
in use today, and nothing will break. It is then up to each and every
individual to upgrade her software so the correct glyphs are displayed, and
so she can enter the correct glyphs.

If you choose something which is not, then we (a) have to go to the dnsext
wg and ask then to please come up with a solution for encoding Unicode in
DNS labels and (b) to every protocol wg and ask them for a transision plan
for moving to UTF-8, a plan which most certainly might include ACE
encodings when one communicate with old software.

   paf

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Jul 2001 09:39:11 -0400

> to be blamed on MIME itself.

perhaps, but it's irrelevant to your argument.

the time required for MIME deployment has nothing to do with charset issues, 
and everything to do with the large installed base of RFC 822 text-only mailers, 
and the design decision for MIME to provide for carriage of a tree-shaped 
structure of arbitrary, labelled body parts.

even if you think that supporting multiple charsets delayed MIME further,
there was no universal charset available at the time that MIME was defined.
would you have delayed the work on MIME until 10646 was finalized
(several years later)?

Keith

---

From: Martin Duerst <[email-masked]>
Date: Tue, 17 Jul 2001 23:40:04 +0900

>even if you think that supporting multiple charsets delayed MIME further,

Well, probably there was some synergy effect, so in part it may have
made things faster. But there are still some mailers that do quite
a good job on multiparts but a bad job on charset issues, so in part
indeed things have been slower.

>would you have delayed the work on MIME until 10646 was finalized

I acknowledged that. But now the situation is different.

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Tue, 17 Jul 2001 11:47:06 -0400

> indeed things have been slower.

There are so many things required of a good MIME implementation that 
it's not surprising that an implementation does a better job with
some parts than others.  But again, this isn't the fault of MIME unless
you believe that MIME should have solved *only* the charset problem and 
not bothered with attachments and the structure thereof.
 
> I acknowledged that. But now the situation is different.

so is the problem.  However, the current IDN question and MIME do have one
significant thing in common - the need to avoid unnecessary disruption of
the installed base.

Keith