Re: [precis] Stephen Farrell's No Objection on draft-ietf-precis-saslprepbis-17: (with COMMENT)

[Peter Saint-Andre - &yet <[e-mail]>]

On 5/27/15 7:21 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-precis-saslprepbis-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - 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.

Truly, the diff is so large that it's more sensible to read this 
document anew.

> - 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."

Is it really the place of this document to discourage the use of 
passwords? I'm all in favor of the sentiment, but it seems to me that a 
BCP on the topic would have a lot more force and could claim IETF consensus.

> - 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.

+1

> - 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.

We might do this:

OLD
        (at the time of this writing, the algorithm is specified in
        Chapter 3 of [Unicode7.0])

NEW
        (at the time of this writing, the algorithm is specified in
        Chapter 3 of [Unicode7.0], but the chapter number might change
        in a future version of the Unicode Standard)

The idea behind including the Unicode7.0 reference was to enable the 
reader to quickly find the relevant discussion as of today, but we know 
that the exact pointer might change.

> 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.

I see your point. Do you have a sense of what kind of systems today 
allow zero-length passwords? Given that RFC 4013 prohibited zero-length 
passwords and that they provide no security whatsoever, I don't see a 
compelling reason to modify the recommendation. However, as you say this 
document doesn't provide general guidance on password strengthy anyway, 
so I suppose I'd be fine with changing it to SHOULD NOT as long as we 
provide some text about why zero-length passwords are acceptable in some 
existing systems.

Peter

-- 
Peter Saint-Andre
https://andyet.com/