Re: [xmpp] Fwd: 6122bis: servers as "registrars"

[Peter Saint-Andre <[e-mail]>]

On 7/17/11 3:56 AM, Jehan Pagès wrote:
> 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<[e-mail]>
> Date: 2011/7/17
> Subject: Re: [xmpp] 6122bis: servers as "registrars"
> To: Peter Saint-Andre<[e-mail]>
>
>
> Hi,
>
> On Sat, Jul 16, 2011 at 5:31 AM, Peter Saint-Andre<[e-mail]>  wrote:
>> 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.
>
> Indeed.
>
>> 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/>?
>
> 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 jehan.pagè[e-mail], I could
> create an alias [e-mail]  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 ᎫᎬᎻᎪᏁ@example.fr, 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?

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/