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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 27 May 2015 06:21:09 -0700

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.

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 08:58:06 -0600

> https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

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

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

> s/during/for/ works though.

+1

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 May 2015 16:12:53 +0100

Hiya,

> BCP on the topic would have a lot more force and could claim IETF

Perhaps. But I'd still argue that this is a good place, even
if not *the* place. I'm thinking that realising just how i18n
is horrible might be the straw that breaks the camel's back
and causes some coders to go use crypto instead:-)

But, we probably shouldn't spend effort debating it, so I'd
say best is if you folks decide to include something or not
and I'll be fine with whatever you decide.

> that the exact pointer might change.

I'm not sure NEW is that different and seems like I did get
the right message from OLD, so you're probably fine with no
change.

> provide some text about why zero-length passwords are acceptable in some

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.

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.

Cheers,
S.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 09:28:21 -0600

> and causes some coders to go use crypto instead:-)

Hope does spring eternal, eh? Yet somehow I don't think i18n (which no 
one cares about) is going to push those coders over the edge, when 
multi-billion dollar breaches of password databases haven't done the job 
already.

> and I'll be fine with whatever you decide.

I'm inclined to leave it out. But would you like to work together on 
that I-D about why passwords must die a horrible death? ;-)

> the right message from OLD, so you're probably fine with no

Can't hut to be crystal clear!

> the WG are ok with that change from 4013.

Most definitely.

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

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 09:44:29 -0600

>>>> draft-ietf-precis-saslprepbis-17: No Objection

<snip/>

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 May 2015 16:46:51 +0100

>> Ah, true. That seems preferable to me.
Agreed.
>       length password after canonicalization.
Yes, this looks great. Thank you!

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 May 2015 17:06:29 +0100

> Yes, this looks great. Thank you!

Same here. That's a fine addition I think.

Cheers,
S.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 27 May 2015 10:19:15 -0600

> Same here. That's a fine addition I think.

OK, we'll submit a revised I-D after the telechat.

Peter

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