Leaving out scripts (Re: Unicode versions (Re: Criteria for exceptional characters))

[Mark Davis]

I tend to agree with Michael on the usefulness of disallowing mixed scripts.
All security is a matter of degree, and once we have removed some of the
symbols and punctuation that are confusable with syntax characters,
disallowing mixed scripts swamps almost every other mechanism in terms of
reducing spoofing opportunities. (The other big one is flagging (eg showing
punycode for) any script that the user doesn't know, the IE7 approach.)

I am not yet, however, so sure that it should be baked into the protocol.
This is a pretty big hammer, and it may be better to leave it to the
registrars and/or the user-agents, which have a lot more flexibility. It is
very simple for a user-agent to have a mixed-script test, and then loosen it
for particular languages where the spoofing opportunities don't arise (eg
mixing Latin and Devanagari).

Mark

On 12/20/06, Michael Everson <everson at evertype.com> wrote:
>
> At 17:32 -0800 2006-12-19, Kenneth Whistler wrote:
> >  > If you allow
> >  > script-mixing, then of course, someone might try
> >  > to spoof Danish å by using a THAANA SUKUN.
> >
> >Or of course using a COMBINING LATIN SMALL LETTER O,
> >which *doesn't* involve script mixing.
> >
> >Or with LATIN SMALL LETTER A WITH DOT ABOVE,
> >which doesn't involve script mixing.
> >
> >Or with <LATIN SMALL LETTER ALPHA, COMBINING RING ABOVE>,
> >which doesn't involve script mixing.
> >
> >>  So don't allow it.
> >
> >Trying to put disallowance of script mixing into the
> >protocol doesn't really solve the problem you are trying
> >to solve.
>
> It solves *one* of our particular problems. Your
> exclusion list (within each script as it were)
> solves *another*.
>
> >And it would make the protocol more complicated,
> >which likely would cut down its acceptance and make it
> >more likely to be implemented with mistakes, which has
> >its own security risks attached.
>
> I guess that is a matter for whoever it is who "owns" the root.
>
> >If we can just focus on eliminating as much of the undesireable
> >cruft and unnecessary stuff from the inclusions table as
> >possible at *this* point, the implementation of
> >StringPrep will be much cleaner, the implementations will
> >be simpler and easier to understand, the output will have
> >many fewer types of problems in it.
>
> I agree, but I think a script-mixing ban is
> nevertheless of great potential benefit.
>
> >I really think you are being overly optimistic,
> >even quixotic, in thinking "just say no to
> >script mixing" in the protocol is going to be
> >the magic bullet to solve these problems.
>
> *One* of our bullets. I'm not so exclusivist.
> --
> Michael Everson * http://www.evertype.com
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20061220/e35888db/attachment.html