John C Klensin <john-ietf@xxxxxxx> writes: >> For SCRAM I believe we are stuck with SASLprep because there >> are no drafts to provide a replacement that are close to being >> mature. > > Here we disagree _very_ slightly. Following part of the theme > of draft-iab-idn-encoding, I have become convinced that having > many Unicode profiles is a significant cost and involves > significant disadvantages. I agree. > Replacements for Stringprep profiles, or updates to Stringprep itself, > should be, IMO, required to justify the costs and complexity they > represent relative to "just use NFC" or the nearly-equivalent "just > use RFC 5198". In this case, if maturity of alternate specifications > were the issue, one could base SCRAM on NFC alone (which is _very_ > mature) if one wanted to start moving away from per-protocol profiles. > I really don't know if that is the right choice at this stage, but it > certainly is a feasible one. I don't think using NFC is feasible at this point. Noone (or?) have evaluated whether NFC alone is a good chose for preparing passwords. So in that way, NFC is not at all mature. RFC 4422 suggests use of SASLprep. SASLprep is mature in that it exists and have been evaluated for appropriateness. Just because SASLprep is not perfect doesn't mean something else, NFC included, will not be worse. Personally (speaking as one of few SASLprep implementers) I believe using NFC alone would be better from many perspectives than SASLprep for passwords. But I can't point to any substantial document to support that belief, and there are obvious disadvantages with the NFC-approach (less stability because of versioning differences) that would need to be addressed. Given that SCRAM is in last call now, I'm not sure it is feasible to develop a document that analyze NFC from this perspective that we can have good confidence in and gain wide support for. I'd be happy to help work on a document that analyzed the consequences of replacing SASLprep with just-use-RFC5198 in SASL. But I don't think SCRAM should wait for something like it to materialize. Finally a general observation. I believe username and passwords are different beasts when it comes to string preparation. What makes sense for usernames does not always make sense for passwords, and vice versa. Usernames are typically transported in the clear, and thus it makes little sense to enforce strong normalization like NFKC on it. What may be useful is to enforce weaker rules, like NFC, when comparing two username strings for equivalence. Passwords should not be transported in the clear, and are often input to hash functions, and thus it is motivated to require normalization. I'm not convinced NFC is sufficient here. I think conflating username string preparation with password string preparation is one problematic part of SASLprep. /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf