John C Klensin <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf