Subject: [precis] Fwd: I-D Action: draft-melnikov-precis-saslprepbis-03.txt

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 14 Sep 2012 10:25:15 -0600

Sorry, in -02 we had neglected to update the spec regarding Pete
Resnick's feedback about bidirectionality of passwords. Alexey and I
have addressed that now, thus the quick -03 release (changing one
paragraph at the end of Section 3.2).

Peter

- -------- Original Message --------
Subject: I-D Action: draft-melnikov-precis-saslprepbis-03.txt
Date: Fri, 14 Sep 2012 09:22:08 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Preparation and Comparison of Internationalized
Strings Representing Simple User Names and Passwords
	Author(s)       : Peter Saint-Andre
                          Alexey Melnikov
	Filename        : draft-melnikov-precis-saslprepbis-03.txt
	Pages           : 11
	Date            : 2012-09-14

Abstract:
   This document describes how to handle Unicode strings representing
   simple user names and passwords, primarily for purposes of
   comparison.  This profile is intended to be used by Simple
   Authentication and Security Layer (SASL) mechanisms (such as PLAIN
   and SCRAM-SHA-1), as well as other protocols that exchange simple
   user names or passwords.  This document obsoletes RFC 4013.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-melnikov-precis-saslprepbis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-melnikov-precis-saslprepbis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-melnikov-precis-saslprepbis-03

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 14 Sep 2012 13:50:15 -0400

It would be good to have members to review this document. Any takers?

Marc.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 14 Sep 2012 17:59:20 +0000

I've got it open to review now (-:

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

On Sep 14, 2012, at 11:50, Marc Blanchet wrote:

> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 17 Sep 2012 18:09:33 +0000

This was started as a review of draft-melnikov-precis-saslprepbis-02.  -03 already addresses most of the questions and concerns I had with -02 (-:

regarding -03:

* 2.3 (Simple User Names - Migration) :: It would be tremendously helpful to have examples for each point raised.

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

* 3.3 (Passwords - Migration) :: It would be tremendously helpful to have examples for each point raised.

* I wonder if each migration section ought to be merged into something larger.  I do think that more needs to be said about the migration not just of the data upon which the software operates on, but also of the software itself.  It is not common for client- and server-based software to be updated in lockstep, and I can see questions coming up about it.

- m&m

On Sep 14, 2012, at 10:25, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlBTWmsACgkQNL8k5A2w/vzKAgCfcJVptes7qR3TrlAtixpNkhNy
> Y7kAoIH4CTjhL/9qBqPwVo/r/bWq55Xr
> =F64+
> -----END PGP SIGNATURE-----

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 17 Sep 2012 19:21:57 +0100

Hi Matt,

Sent from my iPad

> * 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…

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 17 Sep 2012 14:03:38 -0600

> <[email-masked]> 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.

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

Peter

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 21 Sep 2012 14:55:01 +0000

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

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 21 Sep 2012 09:28:16 -0600

On 9/21/12 8:55 AM, Matt Miller (mamille2) wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>> 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).
>>> 
>>>  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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 24 Sep 2012 21:07:41 +0100

> 1. Continue to map those code points to nothing.
Did you mean "continue to map them to U+0020"?

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 25 Sep 2012 13:26:00 -0600

On 9/24/12 2:07 PM, Alexey Melnikov wrote:
>>>> 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.

No, but I might not have said what I meant. :)

RFC 4013 specified two mappings:

1. Map non-ASCII space characters to U+0020. This applied to the code
points listed in Appendix C.1.2 of RFC 3454, i.e.:

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

I think that mapping continues to make sense for passwords (it doesn't
apply to usernames because the PRECIS usage for the SASL builds on
NameClass). However, the reasoning provided in RFC 3454 might lead us
to conclude that non-ASCII space characters are acceptable in passwords:

I don't see a strong reason to allow the non-ASCII space characters
(we've got plenty of entropy as it is), but I wouldn't object if
people wanted to allow them.

2. Map the "commonly mapped to nothing" characters to nothing (i.e.,
delete them from the input string). This applied to the code points
listed in Appendix B.1 of RFC 3454, i.e.:

U+00AD SOFT HYPHEN

(Strangely, as noted, U+200B ZERO WIDTH SPACE shows up in both of
those lists.)

I think that mapping continues to make sense for usernames and
passwords because, as noted in Section 3.1 of RFC 3454, some of those
characters "are only useful in line-based text, and are otherwise
invisible and ignored" whereas the others "affect glyph choice and
glyph placement, but do not bear semantics".

Peter

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