[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] IDN rechartering rev 3




Dave Crocker wrote:
> 
> At 08:53 AM 11/19/2001 -0600, Eric A. Hall wrote:

> >I am referring to DECODES and the enthusiastic display of a charset
> >with combining characters without consideration of the results.
> 
> The string that you so mistrust comes from the DNS.  Hence the security
> question is whether strings from the DNS can be trusted.

Only in some usage scenarios. For protocol and application data which
contains sequences that are decoded for display, this is not true, yet
those encodings must be validated (as legitimate sequences, not as having
legitimate sources which is the DNS problem) before they are trusted.
DNSSEC does nothing to prevent a transliterated URL from pointing to a
site which is different from the displayed domain name.

Unfortunately the scope of this work is such that it cannot be handled by
this WG. In short, the only way that this problem can be adequately
addressed is to reject transliteration for any data that is not lookup
oriented, and to defer tranliteration of protocol or application data
(include mail headers, URLs, everything that is NOT lookup oriented) to
the governing documents where they can be managed as appropriate to their
context. EG, URLs MUST NOT be decoded for display until the URL spec
defines valid characters and sequences, the proper disposition of invalid
sequences, etc.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/