[idn] Re: stringprep: PRI #29

[Simon Josefsson <[e-mail]>]

Erik van der Poel <[e-mail]> writes:

>> A third way, which is what I am deploying, is to use the Unicode 3.2
>> NFKC together with a filter to reject the PR-29 problem sequences.
>> This is in line with the RFC's, it solves problems related to PR-29
>> problem sequences, and is simple to implement.
>
> I don't think this is in line with the RFCs. You are rejecting sequences 
> that are not rejected by the RFCs.

I don't see how RFCs can force an implementation to accept strings
that may cause security problems.  My SASL implementation reject the
PR-29 sequences, as will my Kerberos implementation, and I suggest
that everyone implement similar precautions.

Until this problem is addressed in an update of RFC 3454, rejecting
the problem sequences appear to be the most conservative approach to
me.  What would you propose to do instead?

If the situation is as you claim, that there are multiple StringPrep
implementations out there that implement NFKC in different ways, it
seems hazardous to permit the strings through when you don't know how
other components will behave.  This is especially true if you perform
authentication or authorization on an internationalized authentication
or authorization identity, and then pass it on to another component
that may run another NFKC implementation on the string, before it is
used by a component that assume the identity has been properly
authenticated or authorized earlier.

> More importantly, when you continue to ship your implementation as is, 
> more and more installations of your popular library will occur, making 
> it more difficult for the world to adjust if and when the affected types 
> of character sequences are introduced, either with the current 
> characters or new characters.

The problem sequences doesn't normally occur in the wild, at least
that is what PR-29 says, so it is unlikely to ever be a practical
problem.  It remains a security concern though, and that concern won't
go away until the spec's are updated, regardless of what I do in my
implementation.

> You are in a position to make a difference. You already have. Please 
> reconsider.

This isn't up to individual implementors.  RFC 3454 need to be updated
to address the problem.  Everyone can submit their own update of RFC
3454 to the IETF and advocate for their proposal.  I don't care
strongly which solution is chosen, if there is a good migration plan
to the new idea.  Meanwhile, implementors will route around the damage
and pick their own solutions.

Regards,
Simon