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

["Matt Miller (mamille2)" <[e-mail]>]

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.

> 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, which were mapped to U+0020 in RFC 4013.

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

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.

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.


- m&m

Matt Miller - <[e-mail]>
Cisco Systems, Inc.