Re: [idn] IDN security and ACE leakage

[Martin Duerst <duerst@w3.org>]

At 18:41 01/07/16 +0200, Patrik F$BgM(Btstr$B‹N(B wrote:
>--On 01-07-16 14.36 +0900 Martin Duerst <duerst@w3.org> wrote:
>
> > 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.
>
>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).

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?


>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 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.


>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.

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.


>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,

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


>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.

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?


>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".

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.