Re: [idn] IDN security and ACE leakage

[Patrik Fältström <paf@cisco.com>]

--On 01-07-17 17.52 +0900 Martin Duerst <duerst@w3.org> 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.
> 
> 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.

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.

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

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.

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

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

> What you are saying is that because we have suffered with MIME, we can
> 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
> 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.

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