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

[Alexey Melnikov <[e-mail]>]

On 27/05/2015 16:44, Peter Saint-Andre - &yet wrote:
> 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.
Agreed.
>> 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.
Yes, this looks great. Thank you!