John C Klensin <john-ietf(_at_)jck(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf