[idn] Re: Re: [idn] San Diego Meeting Notes

[Paul Hoffman / IMC <phoffman@imc.org>]

At 8:32 PM +0900 1/25/01, dlee@icu.ac.kr wrote:
>I don't think it's a right approach focusing on a short term solution without
>clear understaning/evaluation on what a long term solution would be.

Could you clarify your reason for this? As long as the short term 
presentation-layer solution doesn't force any design change for the 
long-term solution, it seems that the two can be unrelated. Further, 
having a short-term solution in place gives people more time to 
figure out what the long term solution should be, and will also give 
some valuable data about the attributes of the names that need to be 
handled in the long term solution.

>  Moreover, the proposed decision should be made after thorough 
>analysis of possible problems when non-ACE is used (e.g. UTF-8) 
>which I suggested at the San Diego meeting.

To be specific, the proposals are all for non-marked UTF-8, and many 
of the proposals are for non-marked UTF-8 without nameprep. That 
analysis has already appeared on this mailing list. Today's 
applications allow you to enter DNS names in many encodings, not just 
UTF-8. People from companies that take advantage of this sad fact are 
quite active in this WG. For non-marked UTF-8 (with or without 
nameprep), non-uniqueness of names due to different names in 
different encodings having the same octet sequences raises so many 
security issues that it seems silly to even consider it.

Any proposal for marked UTF-8 with nameprep immediately takes on all 
of the presentation issues that IDNA has, and further forces many 
changes to other IETF protocols and to many non-protocol services 
that currently do DNS name validation. The purpose of using an ACE 
encoding instead of a marked UTF-8 encoding is to allow IDN to be 
used more quickly by more users. It seems unlikely that this group 
would choose a marked encoding that forces more changes in protocols 
and applications before it can be reliably deployed.

Does it seem useful for this group do more analysis even in the face 
of those issues? Put another way, the IETF generally does not create 
proposals with known massive security holes in them. Is it OK for IDN 
to be designed with known security problems?

--Paul Hoffman, Director
--Internet Mail Consortium