John C Klensin <john-ietf(_at_)jck(_dot_)com> writes:
Vulgar Fraction One Half (U+00BD)
Acute Accent (U+00B4)
Diaeresis (U+00A8)
That is important data. It seems to me that it implies:
* if entropy in passwords and/or properly reflecting
keyboards is more important than password
interoperability (whatever that means), then we should
be moving away from NFKC and, hence, from the current
version of SASLprep.
I believe NFKC is sub-optimal for password processing. It reduces
entropy for many non-ambigious characters. For example NFKC('ª') = 'a'
which seems like a clear example of an unwanted conversion.
* if entropy in passwords is less important than
interoperability with any Latin-based (or
Latin-character-containing) keyboard one happens to
encounter, then NFKC should be mandatory. However, one
needs to think about how far to carry that argument
because, if it is taken very far, there is a strong case
for restricting passwords to the basic, undecorated,
Latin letters that appear on all such keyboards.
I don't believe there is a good case for this. Improving entropy in
passwords is important. There shouldn't be any _technical_ reason in
authentication protocols why users cannot use 'ª' in a password to
provide more entropy to the system than using 'a'.
There are many environments where non-ascii characters are a bad idea
from technical or social reasons, but those environments should not
restrict less limited environments. It is fine for a system to validate
passwords against [A-Za-z0-9] if that is required, and that system will
be able to use SCRAM too.
And, of course, it would be possible to decide that we are stuck
with the decisions made in SASLprep. If so, it pretty strongly
suggests to me that we had better get a lot more careful and
conservative about whatever coding decisions we make in the
future.
For SCRAM I believe we are stuck with SASLprep because there are no
drafts to provide a replacement that are close to being mature.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf