Hi Simon,
Thanks for taking the time to reply to my email.
Simon Josefsson wrote:
I don't see how RFCs can force an implementation to accept strings that may cause security problems.
I agree. If an implementor discovers a problem in a spec, they may wish to address that problem in their implementation.
My SASL implementation reject the PR-29 sequences, as will my Kerberos implementation, and I suggest that everyone implement similar precautions.
I haven't been involved with this issue for very long. Would you say that a lot of the implementors have already heard of your approach, and that they are either using the same approach or considering it?
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?
Well, my feeling is that it will take too long to publish a new version of the Stringprep RFC, and that implementors should get together to try to reach a rough consensus and make changes before the new RFC is published. PRI #29 has been published, with a fair amount of info for the implementors to make a decision.
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.
I can see that your approach is ultra-conservative, given that there is some evidence that the affected character sequences are rare.
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.
Why would a mere spec update make the concern go away? Didn't you say that the differing implementations were the concern?
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.
OK, let's suppose just for the moment, that we decide to have Stringprep point to version 24 or higher of UAX #15. Can you think of a migration plan that would satisfy ultra-conservative implementors like yourself?
Or, if you wish, suppose that we do _not_ have Stringprep point to a newer version of UAX #15. Can you think of a good migration plan for that? (Given that some implementations implement UAX #15 differently.)
Erik
