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 9:28 AM, Peter Saint-Andre - &yet wrote:
> On 5/27/15 9:12 AM, Stephen Farrell wrote:
>>
>> On 27/05/15 15:58, Peter Saint-Andre - &yet wrote:
>>> 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

<snip/>

>>>> 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.
>>
>> I think most operating systems either allow empty passwords
>> or else try insist on what they think is "strong" or else
>> give some strength feedback to the user. Many CLI tools allow
>> for empty passwords in case they're used in a script and
>> the same goes for passwords needed by servers that might
>> ever need to restart without a human. (And yes in most cases
>> such tools provide a way to input a password from e.g. a
>> file, but that's often no more secure than no password
>> given how filesystem access control works.)
>>
>> I'll leave it to you folks to decide if you think a SHOULD
>> NOT is ok or not, but I suspect you might want to check that
>> the WG are ok with that change from 4013.
>
> Most definitely.
>
>> I suppose an alternative might be to just note some of
>> the issues above and say that in a bunch of cases an
>> application will have to accept as input either <empty-string>
>> or <password>. I guess that's what's done now in any case
>> and I'd be fine with handling it that way too if you prefer.
>
> Ah, true. That seems preferable to me.
>
> Let's see if Alexey and I can formulate some text...

How's this? (I haven't checked it with Alexey yet but he can reply here.)

OLD
       Note: The prohibition on zero-length passwords is not a
       recommendation regarding password strength (since a password of
       only one byte is highly insecure), but is meant to prevent
       applications from omitting a password entirely.

NEW
       Note: Some existing systems allow an empty string in places where
       a password would be expected (e.g., command-line tools that might
       be called from an automated script, or servers that might need to
       be restarted without human intervention).  From the perspective of
       this document (and RFC 4013 before it), these empty strings are
       not passwords but are workarounds for the practical difficulty of
       using passwords in certain scenarios.  The prohibition on zero-
       length passwords is not a recommendation regarding password
       strength (since a password of only one byte is highly insecure),
       but is meant to prevent applications from mistakenly omitting a
       password entirely, since when internationalized characters are
       accepted a non-empty sequence of characters can result in a zero-
       length password after canonicalization.

Peter

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