Subject: Re: [precis] Last Call: <draft-ietf-precis-framework-15.txt> (PRECIS Framework: Preparation and Comparison of Internationalized Strings in Application Protocols) to Proposed Standard

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 May 2014 16:08:02 -0600

My previous reply to this message was sent in a hurry right before the 
relevant IESG telechat. This reply provides, I hope, a more measured 
response.

On 4/23/14, 10:17 PM, John C Klensin wrote:

> Recommendation: Hold this document until the various categories
> are exercised by at least a sampling of applicable profiles.

As mentioned, we have 5 such profiles in somewhat advanced states:

1. draft-ietf-xmpp-6122bis (defines two profiles to replace two 
stringprep profiles) - completed WGLC in the XMPP WG

2. draft-ietf-precis-nickname (defines one profile for use by both MSRP 
and XMPP) - completed WGLC in the PRECIS WG

3. draft-ietf-precis-saslprepbis (defines one profile for usernames and 
one for passwords) - awaiting WGLC but widely discussed in the PRECIS 
and KITTEN working groups, IMHO it could undergo WGLC fairly soon

> Make the problems with excessive profiles explicit;

Would the following text help?

###

    If input strings that appear "the same" to users are programmatically
    considered to be distinct in different systems, or if input strings
    that appear distinct to users are programmatically considered to be
    "the same" in different systems, then users can be confused.  Such
    confusion can have security implications, such as the false positives
    and false negatieves discussed in [RFC6943].  One starting goal of
    work on the PRECIS framework was to limit the number of times that
    users are confused (consistent with the "principle of least
    astonishment").  Unfortunately, this goal has been difficult to
    achieve given the large number of application protocols already in
    existence, each with its own conventions regarding allowable
    characters (see for example [I-D.saintandre-username-interop] with
    regard to various username constructs).  Despite these difficulties,
    profiles should not be multiplied beyond necessity.  In particular,
    application protocol designers should think long and hard before
    defining a new profile instead of using one that has already been
    defined, and if they decide to define a new profile then they should
    clearly explain their reasons for doing so.

###

Suggestions for improvement are welcome. Right now I'm of the opinion 
that such text belongs in the security considerations, but perhaps it 
makes sense to place it much farther up in the document, even in the 
introduction.

While thinking about this further in the middle of the night, I began to 
wonder if anyone has done usability studies on user astonishment in 
relation to internationalized strings. Do you know of any research we 
can reference here?

> impose
> requirements on additional profiles that include an explanation
> of why they are needed given the user-level interoperability and
> astonishment problems that can result from even three of them

Do you think we need text beyond that quoted above?

> and require a higher level of review and consensus for creating
> new ones than "expert review".

In RFC 5226 terms, are you suggesting specification required, RFC 
required, or IETF review? I get the sense that you'd prefer the latter.

> Modify the Security
> Considerations section to identify user astonishment and
> consequent confusion about what rules are being applied in a
> given PRECIS-User protocol as a risk and possible attack vector.

Again, would the text quoted above suffice or do we need a more detailed 
description of the security implications?

> [3] Not only should multiple profiles be discouraged for this
> type of case by the Law of Least Astonishment, but general IETF
> experience indicates that profiles are a bad idea and that
> protocols that depend on them (and use a significant variety)
> tend to be less successful than those that do not.

I continue to have difficulty imagining how we can do without something 
like profiles, given the large number of identifiers already in the 
field. One possible way to overcome part of that problem would be to 
work on something like draft-saintandre-username-interop in the PRECIS 
WG and to strongly encourage (force?) applications to use that, at least 
for usernamey constructs.

> [5] There are issues with the two classes that are defined in
> this document that have not, I believe, been carefully addressed
> in the WG.  At a minimum, they need to be considered more
> carefully in context with specific examples without preempting
> the choices to be made for those examples.  The following are
> examples, not an exclusive list:
>
> (i) The "Contextual Rule" categories of IDNA2008 have proven to
> be extremely problematic, confusing, and controversial enough to
> be one of the key issues in the UTR 46 battles that have impeded
> IDNA2008 adoption in some important communities.  While I still
> believe that the IDNA2008 decision was the right one, inclusion
> of those characters as Valid for both classes [4] should, given
> those bad experiences, require significantly more explanation
> and/or justification than this draft appears to provide.  If the
> intent of incorporating this list in PRECIS is to provide for
> compatibility with IDNA2008, the list should be incorporated by
> reference (either to RFC 5892 and its successors or to a
> separate documents that updates and replaces the list in RFC
> 5892 as well as being used for PRECIS),  not be provided as a
> list of code points that could cause the two definitions to
> diverge if changes are made to one or the other.  The issue may
> apply more generally to the other characters listed in Section
> 7.6 and to other IDNA-derived elements of Section 7.

As mentioned right before Section 7.1:

    The first ten categories (A-J) shown below were previously defined
    for IDNA2008 and are copied directly from [RFC5892].

Those are merely referenced here. Some of them are used here and some 
are not. Would it help to say that these definitions might change in the 
future if RFC 5892 is updated?

> (ii) Characters with compatibility equivalents are problematic,
> in large measure because of a Unicode issue that has been
> extensively discussed in the past.  Basically the compatibility
> equivalency category mixes several unrelated and incompatible
> (sic) groups of things under a single label.  One extreme is
> occupied by characters used with East Asian scripts that are
> distinguished only by their widths.  If the Unicode design
> principles of "characters, not glyphs" and "plain text" had been
> followed, these different-width variations would never have been
> assigned different code points.  As a contrasting example, the
> relevance of, and distinctions among, special mathematical code
> points distinguished by mathematical use and specific type
> styles is less clear: treating them as separate characters may
> be justified under some circumstances.  A more extreme example
> occurs with some Chinese characters that Unicode treats as
> compatibility equivalents for other characters.  That treatment
> is usually (and perhaps always) appropriate when the "meaning"
> of the characters is intended.  But some of those characters
> are, or historically have been, used in personal names.  To the
> extent to which those names are used as identifiers, e.g., for a
> person thus named, treating them as invalid is inappropriate and
> applying a compatibility mapping to them only slightly less bad.

The many issues with compatibility equivalents provide strong reasons to 
exclude them from the IdentifierClass, which is what the WG did in 
Section 3.2.3. They are allowed in the FreeformClass, but we provide 
warnings about that in Section 10.3. I'll add a forward reference to 
10.3 from 3.1 and 3.3. Suggestions are welcome if you feel that the 
warnings are not strong enough.

> (iii) Experience with IDNA strongly suggests that
> "DefaultIgnorable" is a bad idea.

I don't recall discussion about this in the PRECIS WG, so thanks for 
raising the issue now.

> Forbidding some (or perhaps
> all) of these characters may be reasonable; treating them as if
> they were not present impedes possibly-reasonable future
> extensions and provides an attack vector for phishing and other
> types of unpleasant behavior that do not appear to be called out
> in Security Considerations.

These characters are DISALLOWED, thus forbidden rather than treated as 
not present.

> It is also worth noting that one
> difference between IDNA2008 and this specification is that the
> former is not profiled (except by registries providing their own
> subsetting rules) while the latter is intended as a base for
> profiling.  While the order in which categorization rules is
> applied in Section 8 provides some protection (perhaps
> sufficient protection if the spec is never updated or used as
> the basis for a different profile),

Profiles are not allowed to override the order of rule-checking in the 
algorithm used to determine derived properties.

> it is worth noting that some
> code points appear in more than one category (e.g., the
> notorious ZWJ and ZWNJ in both JoinControl (Section 7.8) and
> PrecisIgnorableProperties (Section 7.13)) and that this should
> at least be called out explicitly.

There's no harm in doing so, for sure.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 May 2014 20:09:33 -0600

> for usernamey constructs.

In a thread that diverged from this one and went offlist, John brought 
up a point that I had not understood until just now. In the interest of 
bringing it to wider attention, with his permission I shall try to 
summarize John's point here and then reply to it in a more public way.

As I understand it, John suggests that the profile mechanism currently 
specified in the PRECIS framework document is a less than ideal way to 
handle exceptional characters. For example, consider the characters that 
are disallowed in the localpart of a Jabber ID in XMPP:

       U+0022 (QUOTATION MARK), i.e., "
       U+0026 (AMPERSAND), i.e., &
       U+0027 (APOSTROPHE), i.e., '
       U+002F (SOLIDUS), i.e., /
       U+003A (COLON), i.e., :
       U+003C (LESS-THAN SIGN), i.e., <
       U+003E (GREATER-THAN SIGN), i.e., >
       U+0040 (COMMERCIAL AT), i.e., @

(See http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.3 
for further discussion.)

It's merely an historical accident that XMPP disallows these characters, 
so he wonders why would define an entirely separate profile just to 
accommodate this usage. Better, he suggests, to do something like define 
a core subset of characters for usernamey things, then note in passing 
that some protocols do silly things with some of these characters (this 
might be similar to what I've started to do in 
draft-saintandre-username-interop, although there I was trying to find a 
least common denominator for all the silliness).

As I see it, that might enable us to unify the UsernameIdentifierClass 
from draft-ietf-precis-saslprepbis and the JIDlocalIdentifierClass from 
draft-ietf-xmpp-6122bis:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-4.1
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.3

Passwords, though, would still be a separate construct, using the 
PasswordFreeformClass from draft-ietf-precis-saslprepbis:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-07#section-5.1

I have some sympathy with John's argument. However, it seems to me that 
exceptional characters are not the only reason we have a multitude of 
profiles. Consider, for example, the JIDresourceFreeformClass from 
draft-ietf-xmpp-6122bis and the NicknameFreeformClass from 
draft-ietf-precis-nickname:

http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12#section-3.4
http://tools.ietf.org/html/draft-ietf-precis-nickname-09#section-2

 From the XMPP perspective (but not the MSRP perspective), a nickname is 
simply a reduced subset and different handling (e.g., NFKC instead of 
NFC) of the resourcepart profile because some further restrictions are 
appropriate for chatroom nicknames. Mostly we have defined these 
restrictions to prevent user confusion in chatroom user interfaces - 
basically, in chatrooms we want to prevent people from mimicking 
nicknames of other users, so we forbid trailing and leading whitespace 
as well as multiple spaces in a row inside a nickname, we want to be 
more aggressive about finding matches so that, for instance, U+2163 
ROMAN NUMERAL FOUR would match the combination of U+0049 LATIN CAPITAL 
LETTER I and U+0056 LATIN CAPITAL LETTER V), etc. These restrictions are 
discussed in http://tools.ietf.org/html/draft-ietf-precis-nickname so 
please see that document for details.

Perhaps I'm too close to the matter at this point, but I think there are 
legitimate reasons for defining at least some of these different 
profiles. Maybe we could handle the differences between the underlying 
strings and the contexts in which they're used (e.g., chatrooms) in 
another way, i.e., by not specifying additional profiles. However, it 
seems to me that users would still have the experience of similar 
strings being treated in different ways (e.g., "why can't my chatroom 
nickname contain multiple internal spaces like my password can?"). To my 
mind, a nickname is quite a different thing (used in quite a different 
context) from a password, even though at the PRECIS level they're both 
based on the FreeformClass.

As I see it, John would like us to reduce the complexity of all these 
different strings and identifiers (including IDNAs) into one or two 
classes. I'm simply not optimistic that such a monism or dualism will 
really serve our needs because we already have a plethora of strings out 
there in the world (usernames, passwords, domain names, file names, 
chatroom names, etc.). I would indeed like to at least unify 
username/localpart constructs (thus draft-saintandre-username-interop), 
but I am not sure if we can progress much farther than that (although 
it's worth investigating in any case).

Peter