Re: [precis] Review of draft-melnikov-precis-saslprepbis-03

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/21/12 8:55 AM, Matt Miller (mamille2) wrote:
> 
> On Sep 17, 2012, at 14:03, Peter Saint-Andre wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> On 9/17/12 12:21 PM, Alexey Melnikov wrote:
>> 
>>> On 17 Sep 2012, at 19:09, "Matt Miller (mamille2)" 
>>> <[e-mail]> wrote:
>> 
>> [I agree with the other points that Matt raised. Thanks for the 
>> review!]
>> 
>>>> * 3.2 (Passwords - Preparation) :: I do wonder about the 
>>>> rationale for step 2) (map all non-ASCII space to ASCII 
>>>> space). I myself have not run into conditions where this
>>>> would matter, but I mostly deal with US-based consumers with 
>>>> passwords almost exclusively in the ASCII range.  On the 
>>>> surface, it seems a bit contradictory in principle to the
>>>> "no bidi rule" rationale that is included. I'm not advocating
>>>> for retention or removal of step 2), but rather for providing
>>>> a rationale (one way or the other).
>>> 
>>> This rule was always in SASLPrep, so this is trying to preserve
>>>  some sort of backward compatibility. Whether it is a good
>>> enough reason to keep the rule - I don't know.
>> 
> 
> I just thought it a bit odd that there's a nice big paragraph 
> explaining how a bidi rule would reduce entropy, but the mapping
> of all non-ASCII space to ASCII space (which would also reduce
> entropy, theoretically) is a single sentence.
> 
> However, I'm willing to more than happy to suspend my perceptions 
> over this if others are content with the current text.

The bidi rule would be an addition to the rules, beyond what was in
RFC 4013. The mapping of non-ASCII space to ASCII space was in RFC
4013 all along. That doesn't make it right, but it does make it a
precedent and we'll need to figure out if we think it's right to
follow that precedent or break with it.

>> This rule applied to stringprep via Appendix B.1 in RFC 3454:
>> 
>> http://tools.ietf.org/html/rfc3454#appendix-B.1
>> 
>> In the interest of full disclosure, the code points involved
>> were:
>> 
>> U+00AD SOFT HYPHEN U+034F COMBINING GRAPHEME JOINER U+1806 
>> MONGOLIAN TODO SOFT HYPHEN U+180B MONGOLIAN FREE VARIATION
>> SELECTOR ONE U+180C MONGOLIAN FREE VARIATION SELECTOR TWO U+180D
>> MONGOLIAN FREE VARIATION SELECTOR THREE U+200B ZERO WIDTH SPACE
>> U+200C ZERO WIDTH NON-JOINER U+200D ZERO WIDTH JOINER U+2060 WORD
>> JOINER U+FE00 VARIATION SELECTOR-1 [...other variation selectors
>> here...] U+FE0F VARIATION SELECTOR-13 U+FEFF ZERO WIDTH NO-BREAK
>> SPACE
>> 
>> As far as I can see, we have two alternatives for SASLprep-bis:
>> 
>> 1. Continue to map those code points to nothing.
>> 
>> 2. Disallow those code points by subclassing the FreeClass.
>> 
>> I don't have a strong feeling either way, although mapping to 
>> nothing has always struck me as a wimpy approach and I'd
>> probably prefer to explicitly disallow unwanted code points...
>> 
> 
> Well, about the first 1/3 of those are also listed in Appendix
> C.1.2,

My count differs from yours. As far as I can see, the only code point
listed in both B.1 and C.1.2 was U+200B ZERO WIDTH SPACE.

> which were mapped to U+0020 in RFC 4013.

Good point. I don't know why RFC 4013 invoked both B.1 and C.1.2.

> Specifically:
> 
> U+00A0 NO-BREAK SPACE U+1680 OGHAM SPACE MARK U+2000 EN QUAD
> U+2001 EM QUAD U+2002 EN SPACE U+2003 EM SPACE U+2004 THREE-PER-EM
> SPACE U+2005 FOUR-PER-EM SPACE U+2006 SIX-PER-EM SPACE U+2007
> FIGURE SPACE U+2008 PUNCTUATION SPACE U+2009 THIN SPACE U+200A HAIR
> SPACE U+200B ZERO WIDTH SPACE U+202F NARROW NO-BREAK SPACE U+205F
> MEDIUM MATHEMATICAL SPACE U+3000 IDEOGRAPHIC SPACE

It's unclear to me how software that complied with RFC 4013 would have
handled the code points that appeared in both B.1 and C.1.2 of RFC
3454 (i.e., U+200B).

> For the purposes of passwords, I don't really know if mapping {Zs} 
> code points to U+0020 is a good idea or not.  On one side, more
> code points means more options (good IMO), but on the other hand I
> doubt these are values most "password" text entry widgets make easy
> (or even possible) to input in a predictable manner.

Yes, and I think that's the stronger argument than the argument from
precedent. To a large degree, these code points are used for things
like typography and are not easily accessible for input purposes in
IMEs or password widgets. Another argument is that these space-ish
code points are not easily perceivable either as you are typing them
or inputting them. However, let's not forget that that typically you
can't see what you're typing or inputting in a password field anyway,
because of the perceived threat of over-the-shoulder attacks. That
makes this advice in RFC 3454 somewhat off-tangent:

   Space characters can make accurate visual transcription of strings
   nearly impossible and could lead to user entry errors in many ways.

After all, typically we're not visually transcribing passwords.

> As for the rest of B.1, I'm more inclined to disallow (which I
> think is the case for FreeClass now) than map to nothing.

That's my take, too.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBch5AACgkQNL8k5A2w/vyswQCfSEYzf0XH+gVBqTusDuZ+tvHo
k+kAoMWn96U9GRB2ZEus/KOG6aVlohcf
=gnVC
-----END PGP SIGNATURE-----