Re: [idn] nameprep2 and the slash homograph issue

["JFC (Jefsey) Morfin" <[e-mail]>]

John,
your proposition makes more sense than Adam as kludges do not escalate, and 
when you start censoring you never know where you will have to stop, and I 
do not know how you can enforce it.

But your proposition is not the panacea.

1) it is meant only for registration. So it is for TLD Registry Managers or 
goodwill registrants (for 3+LD). They are ignorant, lazzy, opposed or 
accepting, but they do not oppose. So the real problem is not with them but 
with phishers.
2) your poposition is to have an oline correction of the problem. Some 
Registry may like it, some not. I would have strong objections because it 
complexifies the user support. But we can try it. This is why I asked the 
solution I asked and asked if a Perl program existed to test a correction 
at registration.

Actually I repeat that all the propositions to change what the user can see 
is user hurting. The need for the click to send a request which the one the 
user want, not the one the phisher want. IMHO one does not increase 
security in hiding the existand of the danger, one increases the risks.
jfc


At 09:39 23/02/2005, John C Klensin wrote:


>--On Wednesday, 23 February, 2005 07:28 +0000 "Adam M. Costello"
><[e-mail]> wrote:
>
> > Erik van der Poel <[e-mail]> wrote:
> >
> >> Another argument against banning the slash homograph is that
> >> any new banning would require a new ACE prefix, which is a
> >> lot of work, and, as John said, there should be a high
> >> threshold for any demonstration that tries to show that a new
> >> prefix is necessary.
> >
> > An alternative, rather than banning the character, is to
> > recommend that it not be shown; the ACE form could be shown
> > instead.  This would effectively make the character useless in
> > domain names (for both phishers and honest folks) without
> > requiring a new ACE prefix.
> >
> > We could push ToUnicode down inside a wrapper function,
> > ToDisplay. Applications would never call ToUnicode directly
> > anymore.  Whenever they wanted to display a domain name,
> > they'd call ToDisplay, which would call ToUnicode, check the
> > result, and if it didn't like it, call ToASCII.  (Of course,
> > since ToUnicode typically calls ToASCII, there are
> > opportunities to optimize that logic.)
>
>Adam, there are two problems with this.  First, it effectively
>dictates UI behavior, which is generally a bad idea.  It is a
>particularly bad idea in this case because you are proposing the
>sort of UI behavior that generates a lot of very confused
>questions and trouble reports, which is something no sane
>implementer wants. And "won't display" is not the right answer
>on the registration side of the process, even if it were right
>on the lookup side.   The second problem is that it is a kludge,
>and that inserting kludges into critical protocols or procedures
>--and IDNs are certainly critical-- almost always turns out to
>be a seriously bad idea sooner or later.
>
>If we find a need to start banning characters that we could not
>agree on banning the first time around, there is another
>approach, also unpleasant but IMO less problematic, that could
>be considered.  Just as RFC 2822 moved past a lot of legacy
>nonsense by having two separate "create" and "accept" syntaxes,
>we could define an additional profile, say "NameRegisterPrep".
>It would look a lot like Nameprep but would ban the characters
>you are now suggesting banning, plus, based on what I think is
>growing experience in the registries, ban any character that
>mapped to anything else.  The effect would be to permit only
>those code points as input to the registration process that
>could be output into punycode and the DNS.  Several registries
>have adopted the latter part of that model already: basically
>what you register is ToASCII(string) and/or
>ToUnicode(ToASCII(string)), but never "string".  The lookup
>process would remain the same, with no changes to Nameprep being
>made at all.  And, by eliminating all of the mapping tables and
>replacing them with prohibitions, it would make the question
>"can this character appear in an IDN" a great deal less
>complicated, which would certainly be an advantage.
>
>This type of registration restriction is rather different from
>our asking/expecting ICANN and the registries to adopt rules
>about, e.g., mixed-script registrations that would help people
>stay out of trouble.  For better or worse, ICANN has a great
>deal less trouble asking (or demanding) that people conform to
>the protocols than it does with making up a somewhat fuzzy
>guideline and enforcing it.  In the most extreme of cases,
>violating a protocol in a significant way is one of those "not
>acting in the best interests of the local users and the Internet
>community" that RFC 1591 warns against and indicates could be
>grounds for redelegating a registry.
>
>It would leave the registries and ICANN stuck with the problem
>of what to do about anything that was now registered which
>violated the new rules, but that problem would exist for _any_
>substantive change we made.
>
>     john