[idn] Re: Fwd: Unicode letter ballot

[Simon Josefsson <jas@extundo.com>]

"Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord> writes:

> Let's consider the possible scenarios:

This was a useful summary.

> 1. The decomposition mappings are changed.
>
>   1a. Stringprep/Nameprep track the update, breaking their promise of
>       backward compatibility.
>
>       If someone registers a name using a CNS 11643 string in
>       combination with the old Nameprep, and later someone tries to look
>       up the name using the very same CNS 11643 string in combination
>       with the new Nameprep, it won't match (if it contains any of the
>       five characters in question).  As more clients upgrade to the new
>       Nameprep, the name will become less and less accessible.

During the time frame when clients upgrade to the new stringprep
(which will be a year or more big) you will also be able to fool
security software that matches stringprep processed strings for
equality, because the security software may use different
decomposition tables than user applications.

> The biggest difference I can see between case 1 and case 2 is that if
> the deprecate/add approach is taken (case 2), IDNA's only choices are
> to track Unicode updates (2a) or not track them (2b), all or nothing.
> But if the fix-decompositions approach is taken (case 1), IDNA has a
> third option (1c) of tracking all Unicode updates except changes to
> decompositions, via the NormalizationCorrections.txt file.

1c is a compelling option, but it essentially means forking the
Unicode NFKC tables.  Forking non-IETF standards in IETF has not been
a good idea historically.  But since NormalizationCorrections.txt will
be short and documented, and the rationale clear, I kind of like it.

> I find this result to be counter-intuitive.  My initial gut feeling was
> that the deprecate/add approach was more conservative, and safer.  But
> apparently not.

I seem to disagree.  To me, case 1a seems to be a disaster as far as
security is concerned.  All other cases are better.  I prefer 2a,
followed closely by 1c.

(Note that I intentionally talk about stringprep and not nameprep, as
the same issues apply to non-IDN applications using stringprep too.
There are several security protocols considering using stringprep.)