John C Klensin <john-ietf@xxxxxxx> writes: >> For highest interoperability the document could do MUST use >> UTF-8 and MUST use SASLprep. I understand that some people >> will not implement SASLprep, and I agree with them that there >> are valid reasons for not implementing SASLprep (such as it >> being based on obsolete Unicode versions), so I would be >> equally happy with MUST use UTF-8 and SHOULD use SASLprep. I >> don't think the requirement on SASLprep can be relaxed further >> without breaking the requirements in RFC 4422. Personally, in >> the long term I would prefer to deprecate SASLprep in favor of >> Net-UTF-8 (i.e., RFC 5198) for use in SASL applications. I >> believe "SHOULD use SASLprep" in SCRAM is a reasonable >> trade-off considering these factors. > > For whatever it is worth, I agree with this analysis. I'm not > sure that RFC 5198 is an adequate substitute for SASLprep, but > it is far better than unrestricted UTF-8 (which, IMO, we should > no longer be recommending in any protocol that requires > comparison of strings). Yes, agreed. > Because of the unrestricted UTF-8 problem, and without taking a > position on deprecating SASLprep, my inclination would be to > strengthen Simon's proposed requirement a bit to "MUST use UTF-8 > and SHOULD use SASLprep or at least Net-UTF-8" or its > equivalent. I share Kurt's concern that this opens up for several classes of implementations that may not interoperate well. > Alternately, I believe that any string that would successfully > come out of SASLprep would conform to Net-UTF-8, i.e., that the > set of valid SASLprep strings is a proper subset of the set of > valid Net-UTF-8 strings. If that were true -- and someone with > significant Unicode normalization and SASLprep > knowledge/experience would need to verify it-- then "MUST use > Net-UTF-8 [RFC 5198] and SHOULD use SASLprep" would be an even > better formulation (perhaps with a note about that subset > relationship). Something along those lines may work, but I think there are serious risks to get the details wrong with a quick fix like that here. If someone has time to study your question that would be useful input nonetheless. Pending something more baked than SASLprep and Net-UTF-8-in-SASL, I continue to believe that "MUST UTF-8 and SHOULD SASLprep" is a reasonable compromise. Finally, I strongly believe that deferring publication of SCRAM significantly to address this issue in a more thorough way does more harm than good. The state-of-the-art SASL mechanism today either transfer passwords to servers without hashing them first, or they use MD5 for the hash, and neither is acceptable. If we don't publish SCRAM, the SASL framework will be unusable for new protocols. /Simon _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf