On 5/21/14, 4:08 PM, Peter Saint-Andre wrote:
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.
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
_______________________________________________
precis mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/precis
