Re: stringprep: PRI #29

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