IDNs in the root

[Andrew Sullivan]

On Fri, Jan 23, 2009 at 01:05:31AM -0800, Tina Dam wrote:
> I completely agree Patrick, in fact I can't see why an submission to
> 'Last Call' can't be done right away!

I can.

Mark Davis's list of open items points out the issue of local
mappings, which is to me one of the most serious problems we currently
have.  I'm unhappy that I don't have a solid idea of how to make
IDNA2008 work according to plan without the loose local mapping rules
in it today.  But those loose local mapping rules are, to my eye, flat
out dangerous.

My reading of the current proposals is that, at registration time, a
registry MAY map forbidden characters to permitted characters.  It
should (not SHOULD) be done conservatively, &c., but in the end the
only actual protocol-word rule there is that the registry is allowed
to do such mapping.  (I know someone is going to tell me that 2119
words are not magic, and that implementers are supposed to read the
protocol as a whole.  If you are tempted to respond that way, I
encourage you to talk to more naïve implementers.)  Note that the
suggestion that the transformed label be displayed to the user is not
much help in a TLD context, because for many TLDs, the "user" is
another machine -- the registrar's system.  There's no language in
here to require acknowledgement by a human, and I don't know how we
could require such a thing anyway.  The Chair has ruled strong policy
advice to registries to be out of charter, so we can't fix it with a
policy advice document.

My reading of the current proposals is that, at lookup time, the only
real restriction is that local mappings MUST NOT convert from one
legal codepoint to another.  Anything else is explicitly on the table,
with a caveat that one ought to be careful.  Maybe I've missed
something important, but as near as I can tell, at lookup time if a
character is not legal, it may be mapped to _anything_ legal.  That
gives me heartburn.  

The thing is, I understand why the document is written this way.  I
think John has captured, as well as can be, the point that we want the
protocol to be flexible enough to allow for the broad range of
localizations that we know are on the Internet, and yet still have
output that can be used in the strictures of the DNS.  The goal is to
be as accommodating as possible.  

But I am deeply conflicted about this, because it looks to me like a
vector for endless games -- and games which will be legal under the
protocol.  I don't even know how to begin to model the attacks
possible under this scenario, because I don't have anything like the
knowledge of all the possible and likely localizations such that I
could form a good picture of what the attacks might be.  And anyway, I
don't think we could special-case them all in any practical sense.

Many people complained bitterly about the phishing holes opened by
IDNA2003, such that rules about IDNA deployment at the top level
became important.  I fully agree that we can do nothing about those
cases, any more than we can prevent people clicking on hyperlinks that
actually hold only IP addresses behind them.  But this business of
local mappings opens a completely new way to mess things up, because
it's fundamentally indeterminate. 

The only suggestion I have for this is to tighten the rules more.  One
way of tightening them is to do as Mark suggested, and say "mapping
for IDNA2003:IDNA2008, and nothing else" (I think that's what he said;
apologies if I put words in his mouth).  An alternative would be to
put together a registry of known mappings, and say, "These are
acceptable, and everything else MUST fail."  The icky thing about
that, of course, is that it puts us back in the business of deciding
"legal" characters, and that's supposed to be a policy decision.

I'm unhappy that we have decided to change the wire protocol without
changing the ACE prefix (and I supported the decision anyway, note).
But I'm absolutely certain we have to do something about the local
mapping case, or the protocol will be too dangerous to recommend as
specified.  

It's quite correct that compromise is needed in order to come to some
final protocol.  I don't think that compromise can extend to
"fundamentally dangerous but still ok".

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.
xmpp: ajs at jabber.shinkuro.com or ajsaf at jabber.org