Re: Legacy charset conversion in draft-ietf-idn-idna-08.txt

"James Seng" <[email protected]> writes:

>> I can't find offical mappings for, e.g., ISO-2022 (RFC 1468) online.
>>
>> > - IDNA already specify (or suggested) that if the apps is using legacy
>> > encodings, it should transcode to Unicode first.
>>
>> Yes, but I cannot find where it says how to do it, or where it cites a
>> reference that explains how to do it.  That's why I think the security
>> consideration should be more clear that the standard will enable
>> trivial attacks that have security consequences if the document is
>> implemented, because the details of legacy transcoding is left
>> unspecified.
>
> No. ISO-2022 specify a mechanism for encoding reportairs using code
> switching. The transcoding varies depending on the reportairs (up to 4) you
> select. And it is not a 1-to-1 mapping with Unicode.
>
> Do you mean you want IDNA to specify transcoding algoirthm too? Then how
> many do you want to support? And why only these set? What if some one
> creates another encoding?
>
> IDNA already say we start from Unicode. How you do the trancoding from your
> encoding to Unicode is up to you so long you have the right Unicode to start
> with, ie, the original legacy encoding is irrelevant from IDN perspective.
>
> If you did not do your transcoding from legacy to Unicode, then there is a
> security problem. But the beast you describe is not IDNA. IDNA specifically
> say it operates from/to Unicode only.

But the Internet is not Unicode only.  I don't want to get into the
design of IDNA, I only want the security consideration to accurately
reflect reality, whatever it may be.

My interpretation of reality is that IDNA has a limitation (that it
does not define mapping tables for legacy encodings) that can be
exploited on hosts that do not use ASCII/Unicode for user
input/output.

>> If there is no standard way to translate ISO-2022-JP into Unicode,
>> won't different applications implement it differently?
>
> There are many ways to implement an algorithm. It does not matter how you do
> it, so long the end results is the same.

Yes!  But since it isn't specified, different applications may
generate different output, which in turn could be exploited.

>> Many machines use legacy encodings, how IDNA ends up being implemented
>> on such systems seems to be up to the implementor right now.
>
> Yes and yes. And Toolkits are available for implementors to transcode, MS
> APIs, ICU, Java I18N API etc. Lets leave the implementation issues to the
> implementors.

Fine.