Subject: [xmpp] Last Call: <draft-ietf-xmpp-address-05.txt> (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 07 Oct 2010 08:03:27 -0700

The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Address Format'
  <draft-ietf-xmpp-address-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-10-21. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-address/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-address/

No IPR declarations were found that appear related to this I-D.

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 15 Oct 2010 23:36:44 +0900

Hi,

my few remarks:

1)
2.4 Resourcepart

«
 When an XMPP address does not include a resourcepart (i.e., when it
   is of the form <domainpart> or <localpart@domainpart>), it is
   referred to as a BARE JID.  When an XMPP address includes a
   resourcepart (i.e., when it is of the form <domain/resource> or
   <localpart@domain/resource>), is referred to as a FULL JID.
»

To remain consistent in the naming, "<domain/resource>" should be
replaced by <domainpart/resourcepart> and <localpart@domain/resource>
by <localpart@domainpart/resourcepart>.

2) 4.3 Confusable characters

«
  A localpart can be employed as one part of an entity's address in
   XMPP.  One common usage is as the username of an instant messaging
   user; another is as the name of a multi-user chat room; and many
   other kinds of entities could use localparts as part of their
   addresses.  The security of such services could be compromised based
   on different interpretations of the internationalized localpart; for
   example, a user entering a single internationalized localpart could
   access another user's account information, or a user could gain
   access to a hidden or otherwise restricted chat room or service.
»

I don't really get the example. How can anyone access another user's
account information (or a hidden/restricted chat room) by using
internationalized characters?

«
   A resourcepart can be employed as one part of an entity's address in
   XMPP.  One common usage is as the name for an instant messaging
   user's connected resource; another is as the nickname of a user in a
   multi-user chat room; and many other kinds of entities could use
   resourceparts as part of their addresses.  The security of such
   services could be compromised based on different interpretations of
   the internationalized resourcepart; for example, a user could attempt
   to initiate multiple connections with the same name, or a user could
   send a message to someone other than the intended recipient in a
   multi-user chat room.
»

This too, what do you mean multiple connections with the same name?
That's the point (or at least one of the points) of the resourcepart:
having multiple connection possible with a single bare JID. Unless you
mean that several full JID might "LOOK" similar (while they are not,
because using different characters but with a very similar graphical
representation?), so speaking of JID mimicking. Actually the use of
"name" here is not very precise. What do we call a "name" in this RFC?
We deal with localpart/domainpart/resourcepart forming JIDs, not with
"names".

Anyway I think this would deserve better text...

3) The next section "4.4 Address Spoofing" could be merged with the
previous "4.3 Confusable characters", don't you think? In particular
with "4.4.2 Address Mimicking" because the issue of confusable
characters is about mimicking addresses. Or is there any other
security issue with confusable characters (maybe related to the
examples I did not get in my previous point, when it was written it
could be used to access user's information or hidden chatroom...)?

4) 4.4.2 Address Mimicking

I have nothing against paypal but that's still an existing company.
Couldn't we use some more neutral name than [email-masked] for our
mimicked JID example? I understand it is a good example as mimicked
address could typically be used to scam people into giving money but I
still think a RFC should avoid such real-company example if possible
(unless it really has some importance as an historical event to
report, or at least if the company had any role in the writing of the
RFC, which is not the case here).

To keep the same l/1 example, any name with 'l' inside will make it:
[email-masked]/[email-masked].

We don't have the "company dedicated to transfer money" example, but I
guess implementers know and understand all the possible uses of
address mimicking (this one and all the others), and we can still add
an explicit note to explain how important this is.

5) Still 4.4.2 Address Mimicking:

The recommendation to XMPP applications to present differently «JID
that mixes characters from more than one character set or that uses
characters outside the normal range of the user's preferred
language(s)» is good. I think we could add a second recommendation
intended to XMPP service providers though.

We could advise them than they should make limitations to their
authorized character sets (or the possibilities of mixing them) in the
localpart/resourcepart when it is relevant to their service context.
For instance a French-only service would be wise to allow only
characters in the French character set (or more globally occidental
character sets) because if the whole service is only in French, they
are not likely to get users using Asian (or whatever else) characters.
Or allowing everything (for very international XMPP services) but not
authorizing character set mixes (or only some kind of mixes which can
be relevant) in order to avoid one type of mimicking we wrote about.
Etc.

Basically a XMPP service provider should take the security
responsability on their part of the network (which is
localpart/resourcepart) that Top Level Domains also deal with (not all
unfortunately) for domain names (domainpart). Of course when relevant.

I remember we had a talk about making a XEP detailing such possible
recommendations and how to limit known security issues (in particular
using all the knowledge of previous bad experience that the Internet,
and the Web in particular, has had) but we can already make a generic
recommendation about this in xmpp-address (and we can later link to
the detailed XEP as well when this one is written).

That's all I see for now.
Bye.

Jehan

On Fri, Oct 8, 2010 at 12:03 AM, The IESG <[email-masked]> wrote:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Oct 2010 10:48:14 -0600

> by <localpart@domainpart/resourcepart>.

Good catch. I also found some instances (in 3920bis and 3921bis) of
domain/resource, domainpart/resource, node@domain, etc. Fixed in all cases.

> internationalized characters?

If a malicious application could fool you into thinking that "a" (U+0061
= LATIN SMALL LETTER A) and "а" (U+0430 = CYRILLIC SMALL LETTER A) are
the same thing, then it is possible that you could be misdirected to an
account other than [email-masked] or whatever.

> representation?), so speaking of JID mimicking. 

Exactly.

The resourcepart of [email-masked]/jehan uses all ASCII
characters.

The resourcepart of [email-masked]/jehаn uses Cyrillic
characters for the vowels.

Now I try to send a private message to you in the jdev room, but I
choose the occupant with a resourcepart containing Cyrillic vowels.

It could be a problem, no?

> Actually the use of

People often use addresses to name things, such as the "jehan" occupant
of the jdev chatroom.

> Anyway I think this would deserve better text...

Proposed text is always welcome. Personally I don't see a problem with
the current text, so I'm not going to propose any changes.

> could be used to access user's information or hidden chatroom...)?

There might be some overlap between the two sections. I'll look at them
in more depth over the weekend.

> mimicked JID example? 

It is a very common example when people talk about typejacking.

> I understand it is a good example as mimicked

I see no problem with the example, but I can change it to ju1iet instead
(Alice is so boring).

> an explicit note to explain how important this is.

I see no need for such a note.

> the detailed XEP as well when this one is written).

Well, as I said during the previous discussion, an XMPP server
deployment that allows registration of new accounts serves a function
similar to a DNS domain name registry or DNS zone administrator, so it
might be appropriate to adapt some text from Section 4.3 of RFC 5891 and
Section 3.2 of RFC 5894. Another weekend task. :)

> That's all I see for now.

Thanks for the continued feedback.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Oct 2010 15:59:16 -0600

> On 10/15/10 8:36 AM, Jehan Pagès wrote:

<snip/>

> in more depth over the weekend.

I took another look at this and there is indeed quite a bit of overlap.
I think the text about confusable characters can be folded into the
section on address mimicking. I've done that in my working copy (see
proposed text at the bottom of this message).

> Section 3.2 of RFC 5894. Another weekend task. :)

I've looked at this topic, as well. The paste below contains proposed
text, mostly adapted from those RFCs.

(Note: the section number changed...)

###

5.3.2.  Address Mimicking

   Address mimicking occurs when an entity provides legitimate
   authentication credentials for and sends XML stanzas from an account
   whose JID appears to a human user to be the same as another JID.  For
   example, in some XMPP clients the address "[email-masked]"
   (spelled with the number one as the third character of the localpart)
   might appear to be the same as "[email-masked] (spelled with the
   lower-case version of the letter "L"), especially on casual visual
   inspection; this phenomenon is sometimes called "typejacking".  A
   more sophisticated example of address mimicking might involve the use
   of characters from outside the US-ASCII range, such as the Cherokee
   characters U+13DA U+13A2 U+13B5 U+13AC U+13A2 U+13AC U+13D2 instead
   of the US-ASCII characters "STPETER".

   In some examples of address mimicking, it is unlikely that the
   average user could tell the difference between the real JID and the
   fake JID.  (Indeed, there is no way to distinguish with full
   certainty which is the fake JID and which is the real JID; in some
   communication contexts, the JID with Cherokee characters might be the
   real JID and the JID with US-ASCII characters might thus appear to be
   the fake JID.)  Because JIDs can contain almost any Unicode
   character, it can be relatively easy to mimic some JIDs in XMPP
   systems.  The possibility of address mimicking introduces security
   vulnerabilities of the kind that have also plagued the World Wide
   Web, specifically the phenomenon known as phishing.

   These problems arise because Unicode and ISO/IEC 10646 repertoires
   have many characters that look similar (so-called "confusable
   characters" or "confusables").  In many cases, users of security
   protocols might perform visual matching, such as when comparing the
   names of trusted third parties.  Because it is impossible to map
   similar-looking characters without a great deal of context (such as
   knowing the fonts used), stringprep and stringprep-based technologies
   such as Nameprep, Nodeprep, and Resourceprep do nothing to map
   similar-looking characters together, nor do they prohibit some
   characters because they look like others.  As a result, XMPP
   localparts and resourceparts could contain confusable characters,
   resulting in JIDs that appear to mimick other JIDs.  In particular:

   o  A localpart can be employed as one part of an entity's address in
      XMPP.  One common usage is as the username of an instant messaging
      user; another is as the name of a multi-user chat room; and many
      other kinds of entities could use localparts as part of their
      addresses.  The security of such services could be compromised
      based on different interpretations of the internationalized
      localpart; for example, a user entering a single internationalized
      localpart could access another user's account information, or a
      user could gain access to a hidden or otherwise restricted chat
      room or service.

   o  A resourcepart can be employed as one part of an entity's address
      in XMPP.  One common usage is as the name for an instant messaging
      user's connected resource; another is as the nickname of a user in
      a multi-user chat room; and many other kinds of entities could use
      resourceparts as part of their addresses.  The security of such
      services could be compromised based on different interpretations
      of the internationalized resourcepart; for example, a user could
      attempt to initiate multiple connections with the same name, or a
      user could send a message to someone other than the intended
      recipient in a multi-user chat room.

   Despite the fact that some specific suggestions about identification
   and handling of confusable characters appear in the Unicode Security
   Considerations [UNICODE-SEC], it is also true (as noted in
   [IDNA-DEFS]) that "there are no comprehensive technical solutions to
   the problems of confusable characters".  Mimicked JIDs that involve
   characters from only one character set or from the character set
   typically employed by a particular user are not easy to combat (e.g.,
   the simple typejacking attack previously described, which relies on a
   surface similarity between the characters "1" and "l" in some
   presentations).  However, mimicked addresses that involve characters
   from more than one character set, or from a character set not
   typically employed by a particular user, can be mitigated somewhat
   through the application of appropriate registration policies at XMPP
   services and presentation policies in XMPP client software
   implementations.  Therefore the following policies are encouraged:

   1.  Because an XMPP service that allows registration of XMPP user
       accounts (localparts) plays a role similar to that of a registry
       for DNS domain names, such a service SHOULD establish a policy
       about the ranges of characters it will allow in localparts at the
       service.  Such a policy is likely to be informed by the languages
       and the scripts that are used to write registered account names;
       in particular, to reduce confusion, the service MAY forbid
       registration of XMPP localparts that contain characters from more
       than one script and to restrict registrations to characters drawn
       from a very small number of scripts (e.g., scripts that are well-
       understood by the administrators of the service).  For related
       considerations in the context of domain name registration, refer
       to Section 4.3 of [IDNA-PROTO] and Section 3.2 of
       [IDNA-RATIONALE].  Note well that wethods for enforcing such
       restrictions are out of scope for this document.

   2.  Because every human user of an XMPP client presumably has a
       preferred language (or, in some cases, a small set of preferred
       languages), an XMPP client SHOULD gather that information either
       explicitly from the user or implicitly via the operating system
       of the user's device.  Furthermore, because every language has a
       range (or a small set of ranges) of characters normally used to
       represent that language in textual form, an XMPP client SHOULD
       warn the user when presenting a JID that mixes characters from
       more than one character set or that uses characters outside the
       normal range of the user's preferred language(s).  This
       recommendation is not intended to discourage communication across
       language communities; instead, it recognizes the existence of
       such language communities and encourages due caution when
       presenting unfamiliar character sets to human users.

###

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Oct 2010 20:31:26 -0600

On 10/15/10 3:59 PM, Peter Saint-Andre wrote:

<snip/>

> The paste below contains proposed text.
> 

Sorry, folks, I wrote some of that in a hurry. On re-reading it I found
a few things that were not quite right. Also, I checked the terminology
against the Unicode spec, resulting in a few additional changes (e.g.,
"character set" to "script" and "range of characters" to "block").
Revised text follows.

###

6.3.2.  Address Mimicking

   Address mimicking occurs when an entity provides legitimate
   authentication credentials for and sends XML stanzas from an account
   whose JID appears to a human user to be the same as another JID.  For
   example, in some XMPP clients the address "[email-masked]"
   (spelled with the number one as the third character of the localpart)
   might appear to be the same as "[email-masked] (spelled with the
   lower-case version of the letter "L"), especially on casual visual
   inspection; this phenomenon is sometimes called "typejacking".  A
   more sophisticated example of address mimicking might involve the use
   of characters from outside the familiar Latin extended-A block of
   Unicode code points, such as the characters U+13DA U+13A2 U+13B5
   U+13AC U+13A2 U+13AC U+13D2 from the Cherokee block instead of the
   similar-looking US-ASCII characters "STPETER".

   In some examples of address mimicking, it is unlikely that the
   average user could tell the difference between the real JID and the
   fake JID.  (Indeed, there is no programmatic way to distinguish with
   full certainty which is the fake JID and which is the real JID; in
   some communication contexts, the JID formed of Cherokee characters
   might be the real JID and the JID formed of US-ASCII characters might
   thus appear to be the fake JID.)  Because JIDs can contain almost any
   properly-encoded Unicode code point, it can be relatively easy to
   mimic some JIDs in XMPP systems.  The possibility of address
   mimicking introduces security vulnerabilities of the kind that have
   also plagued the World Wide Web, specifically the phenomenon known as
   phishing.

   These problems arise because Unicode and ISO/IEC 10646 repertoires
   have many characters that look similar (so-called "confusable
   characters" or "confusables").  In many cases, XMPP users might
   perform visual matching, such as when comparing the JIDs of
   communication partners.  Because it is impossible to map similar-
   looking characters without a great deal of context (such as knowing
   the fonts used), stringprep and stringprep-based technologies such as
   Nameprep, Nodeprep, and Resourceprep do nothing to map similar-
   looking characters together, nor do they prohibit some characters
   because they look like others.  As a result, XMPP localparts and
   resourceparts could contain confusable characters, producing JIDs
   that appear to mimic other JIDs and thus leading to security
   vulnerabilities such as the following:

   o  A resourcepart can be employed as one part of an entity's address
      in XMPP.  One common usage is as the name for an instant messaging
      user's connected resource; another is as the nickname of a user in
      a multi-user chat room; and many other kinds of entities could use
      resourceparts as part of their addresses.  The security of such
      services could be compromised based on different interpretations
      of the internationalized resourcepart; for example, a user could
      attempt to bind multiple resources with the same name, or a user
      could send a message to someone other than the intended recipient
      in a multi-user chat room.

   Despite the fact that some specific suggestions about identification
   and handling of confusable characters appear in the Unicode Security
   Considerations [UNICODE-SEC], it is also true (as noted in
   [IDNA-DEFS]) that "there are no comprehensive technical solutions to
   the problems of confusable characters".  Mimicked JIDs that involve
   characters from only one script, or from the script typically
   employed by a particular user or community of language users, are not
   easy to combat (e.g., the simple typejacking attack previously
   described, which relies on a surface similarity between the
   characters "1" and "l" in some presentations).  However, mimicked
   addresses that involve characters from more than one script, or from
   a script not typically employed by a particular user or community of
   language users, can be mitigated somewhat through the application of
   appropriate registration policies at XMPP services and presentation
   policies in XMPP client software.  Therefore the following policies
   are encouraged:

   1.  Because an XMPP service that allows registration of XMPP user
       accounts (localparts) plays a role similar to that of a registry
       for DNS domain names, such a service SHOULD establish a policy
       about the scripts or blocks of characters it will allow in
       localparts at the service.  Such a policy is likely to be
       informed by the languages and scripts that are used to write
       registered account names; in particular, to reduce confusion, the
       service MAY forbid registration of XMPP localparts that contain
       characters from more than one script and to restrict
       registrations to characters drawn from a very small number of
       scripts (e.g., scripts that are well-understood by the
       administrators of the service).  For related considerations in
       the context of domain name registration, refer to Section 4.3 of
       [IDNA-PROTO] and Section 3.2 of [IDNA-RATIONALE].  Note well that
       methods for enforcing such restrictions are out of scope for this
       document.

   2.  Because every human user of an XMPP client presumably has a
       preferred language (or, in some cases, a small set of preferred
       languages), an XMPP client SHOULD gather that information either
       explicitly from the user or implicitly via the operating system
       of the user's device.  Furthermore, because most languages are
       typically represented by a single script (or a small set of
       scripts) and most scripts are typically contained in one or more
       blocks of characters, an XMPP client SHOULD warn the user when
       presenting a JID that mixes characters from more than one script
       or block, or that uses characters outside the normal range of the
       user's preferred language(s).  This recommendation is not
       intended to discourage communication across different communities
       of language users; instead, it recognizes the existence of such
       communities and encourages due caution when presenting unfamiliar
       scripts or characters to human users.

###

/psa

---

From: Jehan Pagès <[email-masked]>
Date: Sat, 16 Oct 2010 22:58:34 +0900

Hi,

> domain/resource, domainpart/resource, node@domain, etc. Fixed in all cases.

Cool.

> account other than [email-masked] or whatever.

Ok so basically a derived usage of address mimicking.

> the current text, so I'm not going to propose any changes.

Ok. I saw there was other answer-email changing this section, so I
will look at them first and see if I still want to propose other text
for this specific part. :-)

> in more depth over the weekend.

Yes I saw the other emails answer this more deeply. I will have a look at that.

> It is a very common example when people talk about typejacking.

Ok. Just to say.

> I see no problem with the example, but I can change it to ju1iet instead

Juliet works fine with me (though she speaks endlessly about this
"Romeo". That's annoying too ;-).

> I see no need for such a note.

Me neither really. No prob then.

> Section 3.2 of RFC 5894. Another weekend task. :)

I saw you made answer-emails related to that. I will have a look at them soon.

> Thanks for the continued feedback.

You are welcome. That's also for myself. ;-)
Thanks also for the feedback processing. ;-)

Jehan