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