Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
draft-ietf-precis-saslprepbis-18
Yes
(Barry Leiba)
(Ben Campbell)
No Objection
(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
Note: This ballot was opened for revision 16 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -16)
Unknown
Ben Campbell Former IESG member
Yes
Yes
(for -17)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -17)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -17)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -17)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -17)
Unknown
Deborah Brungard Former IESG member
No Objection
No Objection
(for -17)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -17)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -17)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -17)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2015-05-27 for -17)
Unknown
- Unsurprisingly, the diff between this and RFC4013 isn't useful, so I read from scratch. If I'm commenting on something that was already true of 4013, just tell me and that'll be fine. - intro: given the unsolved i18n issues and the fact that passwords are crap (security wise) would it be fair to ask that you add a sentence here to encourage folks to not use passwords at all but some better form of authentication, when that's possible? (Which is sadly not nearly common enough for user authentication.) Maybe something like: "While this document specifies how to handle passwords to the best of our current abilities, those designing and implementing protocols would be much better off if they can avoid any use of passwords. Using passwords means having to deal with the inherent insecurity of passwords, and of password verifier databases, and also the i18n issues described here. Authentication schemes based on digital signatures or other cryptographic mechanisms are, where usable, far preferable." - nitty nit: intro, 2nd last para on p3: once a password is chosen, there are no more entropy changes so you cannot maximise entropy *during* authentication. Maybe s/during/for/ works though. - 3.2.2, bullet 3: I read this as saying to use the latest Unicode default case folding and not to stick with v7.0 even if a new and in this sense different version is published. This is just to check that that is what you intended and that I've not misread the text. 4.1: zero length password - I think you're wrong on that one but it is arguable. This was a discuss until you told me that 4013 prohibited 'em too so probably no point in changing now if it's just my opinion. There are situations where an empty password is ok (say when I'm not "protecting" something but just want to know what user's profile to use, e.g. for weather) and that is supported in many systems (that hence won't be able to exactly adopt this) and insisting on a non-empty password could be more damaging than allowing a zero-length password, whenever a user re-uses a password for something for which no password is really needed (and which hence is less likely to be well protected) and where that password is also used to protect something of significantly higher value. The zero-length password is also not an interesting subset of the set of stupid passwords really so doesn't deserve to be called out as such (and you say that in the draft when you talk about length-1 passwords.) So I think allowing zero length passwords is better overall, and more consistent with implementations.