L2/05-353

Source: Mark Davis
Date: 2005-10-28
Subject: Feedback on UTR #36

I had an interesting and productive discussion with Gervase Markham (of 
Mozilla) on the security issues. Among other things, there are a couple 
of suggestions he had that we should raise in the UTC. This was floated 
by the security subcommittee, and there are a couple of additional 
comments from Marcos.


1. http://www.unicode.org/reports/tr36/tr36-4.html#Syntax_Spoofing

As Michel and others have raised, it is difficult to separate out the 
core part of the domain name. Gervase suggested highlighting (in some 
way in the UI) the entire domain name. That gets around the problem of 
determining the core part, and essentially solves the same problem, of 
highlighting to the user the difference between

http://www.paypal.com/us/cgi-bin/webscr?cmd=p/req/index-outside
and
http://www.paypal.com-us-cgi-bin.webscr.com?cmd=p/req/index-outside


2. 
http://www.unicode.org/reports/tr36/tr36-4.html#Security_Levels_and_Alerts

Having too many levels makes it difficult for users. We already say that 
L5 is not recommended for IDN, and L1 is basically just turning IDN off, 
so what is at issue for IDN is really the differences between #2, #3, 
and #4.

The main case of mixed-script use in the world is Latin + other script, 
so we would probably solve the 99% case if we removed #4, and changed #3 
to be:

   * Allow /Latin/ with other scripts

   * Otherwise, the same as *Highly Restrictive*

Comments from Marcos:

We have to keep in mind that this distinction of different restriction 
levels should be valid for all kind of identifiers, not only for domain 
names. Input from the domain area must be considered, but it must not 
leave wholes in the specification: after such a change, how to categorize 
a mixture of Greek + Cyrillic?

My suggestion is: let implementations of software collapse two of these 
levels into one, if they feel it's more practicable for their users, but 
leave the theoretical description intact.



3. We could then tie in the recommendations
   
http://www.unicode.org/reports/tr36/tr36-4.html#Recommendations_User_Agents
by saying that the default in the user agent should be highly 
restrictive if the registry does not implement the registry 
recommendations, and moderately restrictive if it does.

(Note: Gervase's current thinking is that we just turn IDN off (eg go to 
L1) if the registry doesn't implement the recommendations, but he'd be 
open to considering the possibility of using the highly restrictive 
recommendations instead.)

Note: eventually if we can get ICANN to work out good guidelines, then 
we can point to those from 2.10.4 instead of having our own.

Comments from Marcos:

I have to repeat my ceterum censeo: I think that the registry 
recommendations in UTR36 are an error, out of our competence, and 
discredit the otherwise technically correct and policy-free rest of the 
document.