Re: [idn] Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt

["Masahiro Sekiguchi" <seki@jp.fujitsu.com>]

> The basic attack: Alice runs on host that uses Latin-1 for
> input/output and enters www.µbank.com (where µ is 8859-1 0xB5).  The
> domain is registered using U+00B5, but Alice's application transcode
> the string using U+03BC.  Either Alice can't connect (if the other
> domain doesn't exist) or she ends up talking to someone else (if the
> other domain does exist).

I agree the case you described is a problem.  However, I don't
agree on the point you state is the cause, i.e., I don't think
it is a transcoding problem.

Please imagine that we are living in a ideal Unicode-only world.

Assume the bank registers its domain name using Unicode U+00B5,
intending "micro-bank."  Alice *may* type a key for U+00B5 is
she is a computer engineer, but she may type U+03BC in if she is
a Greek linguist, because her keyboard (or input mapper) will be
optimized for Greek typing, or because her thinking is biased by
her Greek familiarity (She probably read the name as "mu bank",
being puzzled what it means.)

Someone might say this is a Unicode problem.  Well, partly.  For
this particular case, Unicode could have eliminated one of
U+00B5 and U+03BC.  However, there are a lot of similar cases: l
and 1, 0 and O, ´ and ', or ° and o, even in the 8859-1 range.
We can't eliminate all of these similar lookings.

Hence, I consider the basic problem is in our writing systems
and I don't think it's feasible to fix them.

> Suggested modified security consideration below.  It essentially says
> that unless everyone switches to UTF-8, IDNA will enable new attacks
> that has security implications.

Mentioning the security implications is good.  Blaming it on
transcoding is irrelevant.  Revilutionalize the world to use
UTF-8 only doesn't completely eliminate the problem, IMHO.

> -Domain names are used by users to connect to Internet servers. The
> -security of the Internet would be compromised if a user entering a
> -single internationalized name could be connected to different servers
> -based on different interpretations of the internationalized domain name.

> +Domain names are used by users to identify and connect to Internet
> +servers. The security of the Internet is compromised if a user
> +entering a single internationalized name is connected to different
> +servers based on different interpretations of the internationalized
> +domain name.  When all systems use ASCII or Unicode, different
> +interpretations are not allowed in this specification.
> +
> +When involved systems use non-ASCII and non-Unicode characters (such
> +as ISO-8859-1 and ISO-2022-JP, which are common on the Internet),
> +however, this specification leaves the transcoding problem up to the
> +application.  Thus there can not be any assurance that two
> +applications will not implement different transcoding rules. When two
> +applications implement different transcoding rules, they will
> +(assuming both domains exists) contact different servers.  Note that
> +the problem can not just easily be solved by using a security protocol
> +such as TLS to identify and authenticate to end points, unless these
> +protocols have already solved the problem which IDNA is trying to
> +solve.

Comparing these two wordings, I support the original one, although
the best would be something in between.