ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-sasl-scram

2009-09-25 08:01:25
<Pasi(_dot_)Eronen(_at_)nokia(_dot_)com> writes:

John C Klensin wrote:

Looking http://en.wikipedia.org/wiki/Keyboard_layout, it seems
the Finnish/Swedish layout is not special in any way, and many
other European keyboards would also have some small number of
characters  where NFC!=NFKC.

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 don't know about the East Asian width variants, but for the ones in the
Finnish/Swedish layout, there is basically no entropy loss.  For some
of the characters, there's only one way to enter the NFKC form (so no
entropy is lost); and the number of characters affected is small, and
they're rarely used anyway (so the effect on entropy is extremely small).

Latin-1 0xAA ('ª') and 0xBD ('½') are easy to type on Finnish/Swedish
keyboards (AltGr-A and Shift-§) and the NFC and NFKC forms differs.

There might be other reasons, but the complaint about SASLprep I've
heard most often (implementation complexity -- unless the platform
already has a normalize() call always available, many programmers will
"just use UTF-8") applies equally to NFC, too. So I'm not sure if
moving to NFC would really solve anything here...

Agreed.

But "just use UTF-8" probably won't lead to good interoperability
when the passwords are hashed (as opposed to sent and compared, like
usernames).

I'm hesitant to bring this up because it has so many other concerns, but
if you are looking for alternatives, another one is to flag the
normalization algorithm used in the protocol.  E.g., add a flag
'c=saslprep' or 'c=net-utf-8' or 'c=utf-8'.  This makes it possible to
apply a better heuristic on the server side.  Or treat normalization
like the hash algorithm, since it is also an continuously evolving and
apparently never-perfected technology, and make the mechanism name
SCRAM-SHA-1-SASLPREP or SCRAM-SHA-1-NET-UTF-8.  (You can figure out the
problems with this approach as good as I can, so I won't go into them..)

/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf