Subject: [xmpp] 6122bis: servers as "registrars"

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 15 Jul 2011 14:31:08 -0600

In IDNA, certain aspects of the technology are enforced by domain
registrars (e.g., the Hungarian registrars probably won't allow you to
register domain names containing Korean code points). In XMPP, a server
functions somewhat like a registrar, in the sense that it could define
what localparts can be registered (XEP-0077) or provisioned as account
names, and define what domains it will host in a virtual hosting setup.

Do we want to recommend that servers explicitly define such policies? Do
we want to provide suggestions about what such policies contain (e.g.,
"don't allow registration of localparts or domainparts whose script you
don't understand")? If so, do we need to define new error conditions to
handle "registrar"-related problems, or can we use existing conditions
like <not-acceptable/> or <policy-violation/>?

Naturally, one policy might be "anything goes" -- i.e., we could define
a small set of policies from which a service administrator could choose,
where some policies are more restrictive than others. (It might also
help if the policy were discoverable.)

Peter

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 16 Jul 2011 09:50:11 -0700

I would suggest that there is an important distinction between the role of a
registrar in IDNA and the role of an XMPP server.   The "Hungarian
Registrar" you speak about below is a human, not a software component.  The
registrar can decide whether to allow a domain name registration based on a
number of criteria (e.g. trademarks, etc.) which may not be easily
replicated in software, and the existence of these policies does not
necessarily imply changes to software.  For example, a DNS server can allow
RRs to be entered and served which would violate registrar policies (e.g. a
label containing Korean code points within the Hungarian CC tld).

Given this, I'd be careful to separate discussions of mechanism and policy,
and also to be clear when policy can be applied and when it should not be.
For example, who gets to decide whether a username can utilize mixed
scipts?  Is this only the local server creating the username, or can any
XMPP client or server interacting with the JID also have its own policies.
IMHO, allowing all entities to create (potentially incompatible) policies is
probably not a good idea. It is one thing for the Hungarian Registrar to
prohibit Koren codepoints within the Hungarian CCTLD; it is another thing
for an XMPP server in Hungary to decidde not to accept Korean code points in
JIDs, even when the user is hosted on an XMPP server in Korea.

On Fri, Jul 15, 2011 at 1:31 PM, Peter Saint-Andre <[email-masked]>wrote:

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

---

From: "Peter Saint Andre" <[email-masked]>
Date: Sat, 16 Jul 2011 10:51:01 -0700

Good point. I think only servers that accept account registrations would have such policies.

________________________________

From: [email-masked] <[email-masked]> 
To: Peter Saint-Andre <[email-masked]> 
Cc: XMPP <[email-masked]> 
Sent: Sat Jul 16 09:50:11 2011
Subject: Re: [xmpp] 6122bis: servers as "registrars" 

I would suggest that there is an important distinction between the role of a registrar in IDNA and the role of an XMPP server.   The "Hungarian Registrar" you speak about below is a human, not a software component.  The registrar can decide whether to allow a domain name registration based on a number of criteria (e.g. trademarks, etc.) which may not be easily replicated in software, and the existence of these policies does not necessarily imply changes to software.  For example, a DNS server can allow RRs to be entered and served which would violate registrar policies (e.g. a label containing Korean code points within the Hungarian CC tld).  

Given this, I'd be careful to separate discussions of mechanism and policy, and also to be clear when policy can be applied and when it should not be.   For example, who gets to decide whether a username can utilize mixed scipts?  Is this only the local server creating the username, or can any XMPP client or server interacting with the JID also have its own policies.  IMHO, allowing all entities to create (potentially incompatible) policies is probably not a good idea. It is one thing for the Hungarian Registrar to prohibit Koren codepoints within the Hungarian CCTLD; it is another thing for an XMPP server in Hungary to decidde not to accept Korean code points in JIDs, even when the user is hosted on an XMPP server in Korea. 

On Fri, Jul 15, 2011 at 1:31 PM, Peter Saint-Andre <[email-masked]> wrote:

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

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 17 Jul 2011 18:56:37 +0900

Oups, error in the recipient! The below email is a response to the
mailing list, not Peter only, of course! :-)

---------- Forwarded message ----------
From: Jehan Pagès <[email-masked]>
Date: 2011/7/17
Subject: Re: [xmpp] 6122bis: servers as "registrars"
To: Peter Saint-Andre <[email-masked]>

Hi,

> names, and define what domains it will host in a virtual hosting setup.

Indeed.

> like <not-acceptable/> or <policy-violation/>?

I think that we obviously must not *enforce* any policy on the XSF
level, because every server deployment could have very different rules
compared to another, depending on their use case. Defining policy is
only valid when there are some risks, in particular security risks
(impersonation of other users, or simply errors when contacting one
user whose address really looks like another user, etc.). If you have
a private server for your personal domain name with just a few user
(you, a few friends or family) for instance, you don't need any policy
and there is no reason for you to forbid Korean characters (even
though you might be French), or even mixing Korean, Japanese, French,
for fun, and so on. Even a company server is some kind of private
server as a new employee may have an exotic JID as long as the human
administrator does not find any security problem or risk of mistakes.

On this point, I guess it rejoins what was saying Bernard Aboba.

But we should definitely, in my opinion, propose *suggestions* for
*public* services, based on the Internet experience (experience that
the domain name registrars indeed collected for years) of various
scams or possible errors.

Also I agree (it seems even obvious to me) that no implementation must
refuse to contact any other JID because it uses strange characters or
mixes. BUT there are still 2 other kinds of recommendations we could
do:

1/ remind deployment servers, when writing their policy, that there is
another risk to take into account (= other than impersonation scam and
confusion between various users): do the user needs to be joinable
easily all over the world? If you are a very locale Hungarian server,
you don't mind Hungarian characters, but if users wish to be easily
contactable from all over the world, do not forget that you may not be
if your correspondent cannot easily write your name. Of course if he
can copy-paste, this is nice, but if you gave him a business card and
your JID has hungarian characters, a French contact may not know how
to write it.
Do we have a "alias" XEP? That could solve a lot of similar problem,
for instance if I had my main JID [email-masked], I could
create an alias [email-masked]  which would redirect to
jehan.pagès@ (actually a "clever" implementation could even
automatically create it for me, or at least "reserve" it. This is one
of many security recommendation we should do).

2/ Neither clients nor servers implementations must block other
server's JID with other policy (as Bernard Aboba reminds), which means
that my French server, even though it may refuse me to create a JID
with Japanese characters, must obviously definitely not refuse me to
contact my friend 雅子＠例え.テスト. But a secure client could provide some
kind of warning system, the same way that browsers sometimes warn on
dangerous looking domain name.
For instance if you are contacted by an unknown JID (not in your
roster) using mixed (usually incompatible) characters, or strange
characters (for instance [email-masked], so cherookee characters,
especially while using a .fr tld!), the user should definitely be
warned by a big red banner that this can be a risk of impersonation.
The client could also provide a way for the user to check a "this
specific JID is secure, don't warn me again" box, or even a  general
checkbox in the configuration if the user does not ever want to be
warned. But in any case, the default should be to warn of every
"strange" JID or combination.
For this client side also, I think recommendations of implementation
should definitely be written.

As a conclusion, yes I definitely think we have a lot of
recommendations to do in the matter, because we could gather the wide
knowledge in this centralized place (and update it regularly as new
forms of risks are discovered). I summarize the recommendations:
(1) Advice for servers, especially for those using a public
registration system without any kind of human verification, in order
to help them define safe policies (depending on their expected users
in particular);
(2) Advice for servers to enforce additional "dynamic" restrictions
based on existing users (for instance your policy might authorize both
'e' and 'è' characters on a French server, but if a user registered
'pagès@', future registrations of 'pages@' should be restricted.
(3) Recommendations for clients to warn users of risks, where we would
define as exhaustively as possible, the many known kind of risks:
characters mixes; locale name's characters not corresponding to the
domain name's characters and the TLD location; common known
"looking-alike" character maps between various syllabaries, like
cheerokee or cyrillic to assume occidental alphabets, and so on.

Also remind that apart from this, a client or server must accept any
contact but may provide appropriate warning and maybe an alias XEP (if
not already existing) could be in order.

Note that I remember that the XSF roadmap has an item about preparing
us to work on these kind of security considerations: spam, scam,
phishing, etc. This kind of discussion could definitely enter as an
item in such a working group. Are we creating it?

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Jul 2011 15:59:16 -0600

On 7/17/11 3:56 AM, Jehan Pagès wrote:
> From: Jehan Pagès<[email-masked]>
> Date: 2011/7/17
> To: Peter Saint-Andre<[email-masked]>
>
>
> Hi,
>
> On Sat, Jul 16, 2011 at 5:31 AM, Peter Saint-Andre<[email-masked]>  wrote:
>> like<not-acceptable/>  or<policy-violation/>?
>

We already have some on these matters here:

http://tools.ietf.org/html/draft-blanchet-precis-framework-02#section-10.3

http://tools.ietf.org/html/draft-saintandre-xmpp-6122bis-01#section-4.3.2

However, I think we probably want to add more detailed guidance for both 
service providers and client developers.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 19 Jul 2011 13:22:50 +0900

Hi,

> On 7/17/11 3:56 AM, Jehan Pagès wrote:
[...]
> service providers and client developers.

Yes I remember these texts. But as you say, I think we should have
more detailed guidance, and probably also in separate documents. Like
one document could be a guide for public server deployment. And one
other could be a guide for client implementers.

XMPP is great for identifying JIDs but it does not cover all issues,
and especially those i18n matters, though necessary, create many
hard-to-counter attacks (as you showed well with your example in the
Unicode version thread).
One day, if XMPP gets the attention it deserves (and that's the goal),
we'll get there too (people trying to scam others, directly or setting
bots for this, and so on). So let's prepare better than were other
protocols (even though it is a never-ending preparation).

Jehan