[idn] Re: stringprep: PRI #29

[Simon Josefsson <[e-mail]>]

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

>> 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?

I haven't seen much evidence of that.  The SASL and Kerberos specs
that use StringPrep haven't been published yet.  Few, if any,
implementors are speaking about this issue in those WG's.  Presumably
the specs are pushed out before the ideas have been implemented and
tested in practice.

>> 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.

I think it may be better to try and reach that consensus within the
IETF.  The expertise on this are supposed to be here.

>> 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?

Right.  I was assuming implementors will implement a sanely updated
spec, and that this in combination would solve the problem.

>> 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?

The spec could suggest that all problem sequences are to be rejected.

> 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.)

Here too, the spec could suggest to reject all problem sequences.  The
NFKC implementations could continue to work as the Unicode 3.2
algorithm description suggest, but since the problem sequences are
rejected, you wouldn't notice the difference in practice.

Assuming PR#29 is correct on that these strings doesn't occur
naturally, rejecting them doesn't appear to have any interoperability
consequences.

Regards,
Simon