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/
