[idn] Re: Fwd: Unicode letter ballot

[Simon Josefsson <jas@extundo.com>]

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

> Simon Josefsson <jas@extundo.com> wrote:
>
>> 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.
>
> This is very curious.  You say 2a is your favorite, and 1a is a
> disaster, but to me they appear to have the very same characteristics.
> Could you give a scenario that illustrates why 1a is so much worse than
> 2a?

One class of scenarios are software checking ACLs, such as an
application authentication proxy (application level firewall, if you
wish).  To take the example of SASL (which doesn't have a stringprep
profile, but might get one), connecting in with administrator
credentials to an employee account on an IMAP server with SASL.

Detailed example:

Authentication identity "admin", authorization identity U+4711,
password X.  For the argument, let's say U+4711 decomposes into U+1234
in Unicode 3.2 but is later changed to U+4321.

The SASL library, acting as a proxy in front of the application
software, implements the current libstringprep correctly.  It checks
that admin's password is X and that he is authorized to log in as
U+1234 (which is the result after stringprep of U+4711, which was sent
because the client hadn't been updated to use stringprep, which should
cause no problem) and says OK to the application.

Now, in 1a the application is using updated tables from a more recent
stringprep that incorporates the fixed decomposition mapping, causing
it to admit the user to an account U+4321.  This is bad.

In 2a, the application sees that the characters are deprecated due to
its decomposition mapping changed, and rejects the user.  This is
good.

This example might seem contrived, but this kind of proxying and
username forwarding handles alot in practice if you think about it, it
does not have to be as explicit as an admin-logon.

> (Reminder: 1a means the decomposition mappings are changed and
> Stringprep tracks the update.  2a means characters are deprecated and
> added, and Stringprep tracks the update.)

[I used the word "disaster" carelessly, btw. This problem only
concerns a small number of characters.  It is a problem, but it does
not have disastrous proportions.]