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

Reply via email to