Browser IDN display policy: opinions sought

John C Klensin klensin at
Tue Dec 13 11:34:40 CET 2011

--On Monday, December 12, 2011 21:10 -0500 Andrew Sullivan
<ajs at> wrote:

> Sorry, I managed to send this before I intended to.  The rest
> is below.
> On Mon, Dec 12, 2011 at 06:59:37PM -0500, Andrew Sullivan
> wrote:
>> No, because you can check those rules yourself in your
>> resolution context: look at what you are looking up and
>> compare it to the rules to see whether it conforms.  Indeed,
>> if that's not good enough, you have this problem anyway.

But you cannot check if the rules involve similarity with what
is present in the zone.  Certainly you can check for
mixed-script labels but (ignoring the complexities of the
various exception cases), that is a useless check to make
against a determined attacker because the recommendation to make
such checks is just too widely known and understood (yes, it
would give some protection against really dumb attackers,
but...).  To do a more sophisticated check, you'd need to be
able to ask the DNS server to return all of the labels that
might be confused with the one you are thinking about looking
up.  That would be a useful function for many purposes,
especially if one could ignore the issues associated with
perception and doing it algorithmically.   But it requires two
things of DNS servers (presumably all of them): that they be
able to convert IDNs back to Unicode code points so they could
do similarity searches on them and that they be able to do
similarity (fuzzy and/or distance measure) searches on those
converted strings.  Actually a third: the ability to return a
rather long list of labels, something that is not supported by
any existing DNS query other than zone transfers.  Or, I
suppose, one ignore the security issues and could just do the
zone transfer oneself and then perform the conversions,
searching, and matching locally.  Ignoring the questions of
which DNS this could be implemented in and how long it would
take to deploy, I can imagine Gerv's implementers and
performance folks who won't tolerate changes with far lower
performance consequences having ROFL responses or worse.

>> > 	-- all registrars are good guys, with neither motivation
>> > 	nor will for getting around the rules.
> This is a problem we already have, for _any_ of these rules.
> What's special about the current approach that solves that?

At some level, that is exactly my point.  Whether he gets the
list right or not, Gerv's "Type B" is based on a whitelist of
well-behaved registries, where well-behaved includes (even if
indirectly) assuring the good behavior of registrars.  In a
world in which stating policies and ignoring them is ok (because
there are no effective sanctions) and, as Tina indirectly points
out, having guidelines that are ignored by some registries is ok
(again, no consequences), then Gerv needs to run his registry
evaluation system anyway.  It makes it a little easier for him
to find the rules that make up part of the evaluation, but the
"do they actually follow those rules" part is unchanged.

Ignoring the performance issues, etc., there is another problem
with saying "lets put a pointer to the rules in the DNS".  If
those rules are going to be machine-processed, there must be an
agreed-upon format.  The diversity of the possible types of
rules and some experience with similar format discussions might
make the time needed to develop and agree upon the required
format, keywords, operators, etc., compare unfavorably with the
design, development, and deployment time for DNSng.  And that
assumes the IETF did the work; if the obvious other organization
tried it, I'd assume it would take that long before the
committees stopped delegating work to other committees and
actually sat down to do something.

>> > 	-- if either of the above fail, there is someone with
>> > 	both the authority and willingness to require that the
>> > 	rules be enforced and to enforce that requirement (or to
>> > 	enforce the rules itself, but that is even more
>> > 	farfetched).
> We also already don't have this.  On the contrary, what we
> have right now is a case where rules are inconsistent among
> registries, there is no way at all to find out the rules in
> zones not near the root, those near-root zones are treated
> according to at least three different display conventions, and
> one of those conventions entails using a _different_ set of
> more or less arbitrary rules established under conventions
> also not strictly rooted in the behaviour of anyone operating
> the zones.  How is this better?

And you left out "many of the rules that do exist are just
ignored in practice".  All I was suggesting was that your
proposal wouldn't help much.  Pointers to rules that are ignored
helps no one.  Pointers to rules that cannot be parsed and
accurately understood don't help with lookup-time processing,
even there were no performance issues.

Unless this situation is rationalized sufficiently by some
entity that has the authority to enforce it on some domains and
create, by example, a model that inspires (or creates pressure
on) others, then either: 

	Gerv (and many others) are wrong and confusable names
	will never amount to much as an attack vector except
	against the dumbest of users ... or ...
	IDNs don't have much future outside isolated,
	single-language communities because these
	blunt-instrument tools will exclude too much  and/or
	enough people will be victimized to create a general
	sense of fear.

> If the goal is, "Protect people from bad actors," my
> suggestion is, "Don't use the DNS.  It's a worse match for
> that task than the hundreds of others people seem to want to
> throw into it." 

Strongly agree.  But you know that already.

> But if the goal is to know whether there is
> something resembling a policy that allows you to make
> slightly-informed guesses about whether it is sane to treat
> U-labels in a zone as U-labels, I'm suggesting that we can do
> better than either "SWAG about the language this label is
> supposed to be in" or "I know who the bad guys are, trust me."

And I'm suggesting that any system that makes the rules easier
to find will ultimately come down to your second choice above
unless some entity starts enforcing (at least) conformance to
declared rules and preferably a minimum set of rules as well.


More information about the Idna-update mailing list