Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-address-00

From: Philipp Hancke <[email-masked]>
Date: Mon, 05 Jul 2010 06:55:04 +0200

Ben Campbell wrote:
> This is a Working Group Last Call of draft-ietf-xmpp-address-00. The draft is available at the following URL:
> 
> http://tools.ietf.org/html/draft-ietf-xmpp-address-00
> 
> The WGLC will conclude on 13 July, 2010. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group.

2.2: s/can identity an entity/can identify an entity/

If wonder if the last paragraph in 2.4 should mention user@host
resourceparts - some people use them in MUC rooms.

cheers

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 15:59:44 -0600

On 7/4/10 10:55 PM, Philipp Hancke wrote:
>> The WGLC will conclude on 13 July, 2010. Please send your comments,
>> including nits and "this is ready to go" type comments, to the authors
>> and the working group.
> 

Fixed.

> resourceparts - some people use them in MUC rooms.

Good point. Changed to:

###

   XMPP entities SHOULD consider resourceparts to be opaque strings and
   SHOULD NOT impute meaning to any given resourcepart.  In particular:

   o  Use of the '/' character as a separator between the domainpart and
      the resourcepart does not imply that XMPP addresses are
      hierarchical in the way that, say, HTTP addresses are
      hierarchical; thus for example an XMPP address of the form
      <localpart@domain/foo/bar> does not identify a resource "bar" that
      exists below a resource "foo" in a hierarchy of resources
      associated with the entity "localpart@domain".

   o  The '@' character is allowed in the resourcepart, and is often
      used in the "nick" shown in XMPP chatrooms.  For example, the JID
      <[email-masked]/user@host> describes an entity who is an
      occupant of the room <[email-masked]> with an (asserted)
      nick of <user@host>.  However, chatroom services do not
      necessarily check such an asserted nick against the occupant's
      real JID.

###

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Jul 2010 10:49:52 -0500

[as chair]

Just a reminder--we're a little over a week into this WGLC and I have only seen one comment on the mailing list. If you think there are no issues, please send email to that effect. We can't really assume lack of feedback to mean consensus in an WGLC.

Thanks!

Ben.

On Jun 29, 2010, at 1:30 PM, Ben Campbell wrote:

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 11:21:02 -0600

Thanks for the reminder. Based on feedback received so far along with my
own WGLC review, I've made some mostly minor edits to this spec. Given
that the I-D cutoff is fast approaching and that I need to finish up my
editor's review of 3921bis before then too, I would like to push out a
revised I-D so that those responding to your reminder have the latest
and greatest text.

Objections?

On 7/7/10 9:49 AM, Ben Campbell wrote:
> [as chair]
> 
> Just a reminder--we're a little over a week into this WGLC and I have
> only seen one comment on the mailing list. If you think there are no
> issues, please send email to that effect. We can't really assume lack
> of feedback to mean consensus in an WGLC.
> 
> Thanks!
> 
> Ben.
> 
>> This is a Working Group Last Call of draft-ietf-xmpp-address-00.
>> The draft is available at the following URL:
>> 
>> including nits and "this is ready to go" type comments, to the
>> authors and the working group.
>> 
>> Thanks!
>> 
>> Ben.

---

From: Florian Zeitz <[email-masked]>
Date: Fri, 09 Jul 2010 02:03:57 +0200

> including nits and "this is ready to go" type comments, to the authors

Looks fine to me. Just 2 nitpicks:
1. Introduction and overview seem to have a large overlap. Not sure if that's nesseccarily bad though.
2. Section 4.4.2 s/occus/occurs/

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Jul 2010 11:54:39 -0600

> 1. Introduction and overview seem to have a large overlap. Not sure if that's nesseccarily bad though.

Yes, I see a few sentences and clauses that could be removed from the
introduction.

Fixed.

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 13 Jul 2010 13:42:08 -0500

The WGLC of draft-ietf-xmpp-address-00 ends today. Thanks to all those who gave feedback. If you have comments you haven't made, please send them ASAP!

Thanks!

Ben.

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 15 Jul 2010 03:52:15 +0900

Hi,

> The WGLC of draft-ietf-xmpp-address-00 ends today. Thanks to all those who gave feedback. If you have comments you haven't made, please send them ASAP!

sorry again for sending late comments. So if it is not too late here
is my only comment.

In the security considerations, in particular "4.2.2 address
mimicking", 2 typical cases of increased probability of mimicking are
« addresses that involve characters from more than one character set,
or from a character set not typically employed by a particular user ».
But later on the case when one mix character set seems to be forgotten
in the implementation advice:
« Therefore, an XMPP application SHOULD warn the user
   when presenting a JID that uses characters outside the normal range
   of the user's preferred language(s). »

I think it would be worth repeating both cases by replacing by:
« Therefore, an XMPP application 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 character-set mix stuff is a typically "doubtful address"
recognition (though as it is precised in the draft, it does not
necessarily mean this is a real mimicking scam) and that's something
typically detected nowaydays to fight domain name mimicking. Basically
for the very new Internationalized TLDs, or for some older ascii TLD
which accepts internationalized characters, the policies more and more
defines security limitation by forbidding domain names mixing
characters from different languages (and for the tlds which refuse to
define such limitation, modern browsers will not display the
internationalized characters but only their ASCII representation to
warn the user from possible character set mix scam).

I don't say we should do the same and forbidding character set mix in
the whole JID but it is worth insisting on this and the logics of such
recommendation (which is that when you write in some language, you
"usually" don't switch between several character sets in the same word
or name, so there may be some understandable "doubt" on the validity
of such character-set-mixing jid) so that implementers fully
understand the background of such security discussions and take them
seriously. Hence maybe some additional background text would worth
being added about this, no?

Except from this detail, this draft looks good to me.
Bye.

Jehan

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 15 Jul 2010 09:18:02 +0500

> The WGLC of draft-ietf-xmpp-address-00 ends today. Thanks to all those who gave feedback. If you have comments you haven't made, please send them ASAP!

1.
A little inconsistency or duplication: The 1023 byte limit is
mentioned in sections 2.1, 2.3 and 2.4, but not in 2.2.

2.
The specification doesn't say anything about ACE labels.

"An ACE label is an internationalized label that can be rendered in
ASCII and is equivalent to an internationalized label that cannot be
rendered in ASCII."

i.e., they are ASCII equivalents of non-ASCII domain names.

Users can reasonably be expected to use these when inputting the
non-ASCII version of a domain isn't feasible (lack of non-ascii input
method, copy pasting host from web browser address bar, etc). I
suspect most XMPP entities currently wouldn't consider the ASCII and
non-ASCII versions of a non-ASCII domainpart to be the same, when they
should in fact be equivalent.

One solution: Normalize domainparts which start with the ACE prefix by
applying ToUnicode.

3.
The 1023 byte limit applies to all parts of a JID. But when does this
apply? Does this apply to both prepped and unprepped JIDs? IMHO it
should apply to both.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 15:29:49 -0600

On 7/14/10 12:52 PM, Jehan Pagès wrote:
>> The WGLC of draft-ietf-xmpp-address-00 ends today. Thanks to all
>> those who gave feedback. If you have comments you haven't made,
>> please send them ASAP!
>> 
>> Thanks!
>> 
>> Ben.
> 

Nope, not too late at all.

> mimicking", 2 typical cases of increased probability of mimicking
> are « addresses that involve characters from more than one character
> set, or from a character set not typically employed by a particular
> user ». But later on the case when one mix character set seems to be
> forgotten in the implementation advice: « Therefore, an XMPP
> application SHOULD warn the user when presenting a JID that uses
> characters outside the normal range of the user's preferred
> language(s). »
> 
> I think it would be worth repeating both cases by replacing by: «
> Therefore, an XMPP application 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). »

Good catch. Fixed in my working copy.

> typically detected nowaydays to fight domain name mimicking.
> Basically for the very new Internationalized TLDs, or for some older
> ascii TLD which accepts internationalized characters, the policies
> more and more defines security limitation by forbidding domain names
> mixing characters from different languages (and for the tlds which
> refuse to define such limitation, modern browsers will not display
> the internationalized characters but only their ASCII representation
> to warn the user from possible character set mix scam).

Yes, that kind of policy is now fairly common for domain name registrars.

> I don't say we should do the same and forbidding character set mix
> in the whole JID 

In a way, an XMPP service is like a registrar for localparts (it plays a
role similar to that of a domain name registrar for domainparts). So I
agree that it can make sense for the XMPP service provider to enforce
some rules about localparts during the process of registering an XMPP
account.

> but it is worth insisting on this and the logics of
> such recommendation (which is that when you write in some language,
> you "usually" don't switch between several character sets in the same
> word or name, so there may be some understandable "doubt" on the
> validity of such character-set-mixing jid) so that implementers
> fully understand the background of such security discussions and take
> them seriously. Hence maybe some additional background text would
> worth being added about this, no?

I don't know if it is best to talk about this topic here or in XEP-0077
(In-Band Registration), which is explicitly about account registration.
I lean toward XEP-0077, but accounts can be registered in other ways
(via website, by calling someone on the phone, etc.).

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 16:09:12 -0600

On 7/14/10 10:18 PM, Waqas Hussain wrote:
> 1. A little inconsistency or duplication: The 1023 byte limit is 

Fixed. Naturally, the rules for FQDNs are more complicated than for
localparts and resourceparts...

> 2. The specification doesn't say anything about ACE labels.

I'm happy that someone mentioned this.

> non-ASCII version of a domain isn't feasible (lack of non-ascii
> input method, copy pasting host from web browser address bar, etc).

I think it's not exactly "reasonable" to expect humans to input ACE labels.

Consider the following Czech example from RFC 3492:

pročprostěnemluvíčesky.cz

The ACE conversion yields:

xn--proprostnemluvesky-uyb24dma41a.cz

Or a traditional Chinese example, also from RFC 3492:

他們爲麽么說中文.cn

The ACE conversion yields:

xn--ihqwctvzc91f659drss3x8bo0yb.cn

How is it reasonable to expect anyone to enter such strings?

> I suspect most XMPP entities currently wouldn't consider the ASCII
> and non-ASCII versions of a non-ASCII domainpart to be the same, when
> they should in fact be equivalent.

I strongly suspect that no XMPP clients support ACE labels, and that few
XMPP servers do.

> One solution: Normalize domainparts which start with the ACE prefix
> by applying ToUnicode.

Given that XMPP is all UTF-8, I think that converting to Unicode for
communication over the wire is quite reasonable. I'd even go further and
say that we probably thought we were saying that when we re-used
IDNA2003. Unfortunately, I don't think we really understood IDNA at that
time (not that we understand it completely now, but IMHO we did not grok
i18n issues at all back then).

Naturally, an XMPP implementation might use ACE labels for backend data
storage or for interfacing with non-XMPP / non-UTF-8 systems, but in the
specification of XMPP itself we don't need to mention that.

> 3. The 1023 byte limit applies to all parts of a JID. But when does
> this apply? Does this apply to both prepped and unprepped JIDs? IMHO
> it should apply to both.

It could be argued that an unprepped string is not really a JID, even
though it looks like one, and IMHO the 1023 limit applies only to JIDs.
However, I suppose it would save processing cycles to perform the
1023-byte check before prepping, right? If you'd like to do that in your
implementation, feel free. :)

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 16:24:45 -0600

Proposed text at the end of this message.

> specification of XMPP itself we don't need to mention that.

How is this for revised text?

   A domainpart consisting of a fully qualified domain name MUST be an
   "internationalized domain name" as defined in [IDNA2003], that is, it
   MUST be "a domain name in which every label is an internationalized
   label" and MUST follow the rules for construction of
   internationalized domain names specified in [IDNA2003].  When
   preparing a text label (consisting of a sequence of UTF-8 encoded
   Unicode code points) for representation as an internationalized label
   in the process of constructing an XMPP domainpart or comparing two
   XMPP domainparts, an application MUST ensure that for each text label
   it is possible to apply without failing the ToASCII operation
   specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus
   forbidding ASCII code points other than letters, digits, and
   hyphens).  If the ToASCII operation can be applied without failing,
   then the label is an internationalized label.  (Note: The ToASCII
   operation includes application of the [NAMEPREP] profile of
   [STRINGPREP] and encoding using the algorithm specified in
   [PUNYCODE]; for details, see [IDNA2003].)  Although XMPP applications
   do not communicate the output of the ToASCII operation (called an
   "ACE label") over the wire, it MUST be possible to apply that
   operation without failing to each internationalized label.  If an
   XMPP application receives as input an ACE label, it MUST convert that
   ACE label to an internationalized label using the ToUnicode operation
   (see [IDNA2003]) before including the label in an XMPP domainpart
   that will be communicated over the wire on an XMPP network.

/psa

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 22 Jul 2010 03:46:13 +0500

>   that will be communicated over the wire on an XMPP network.

On further reading IDNA (rfc3490), I see in section 6.1:

   Applications MAY allow input and display of ACE labels, but are not
   encouraged to do so except as an interface for special purposes,
   possibly for debugging, or to cope with display limitations as
   described in section 6.4..  ACE encoding is opaque and ugly, and
   should thus only be exposed to users who absolutely need it.

which discourages ACE labels, except where they are appropriate in UIs.

Though in section 6.2, 6.3 and 7 there's text about resolver
libraries, DNS servers and name servers only supporting (or being
required to only support) ASCII. That seems out of scope for
draft-ietf-xmpp-address I think, and there's section 6.4: 'Avoiding
exposing users to the raw ACE encoding'.

I just switched from pointing out ACE label, to discouraging their
use. Sorry about that :)

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 16:54:33 -0600

> I just switched from pointing out ACE label, to discouraging their

Right, I think we need to strongly discourage their use over XMPP
itself, because we have no need of them. And, as I pointed out, my
impression is that we *thought* we were just using UTF-8 encoded
"internationalized domain names" when we re-used stringprep back in
2003-2004, and we did not carefully read RFC 3490 and related specs to
learn about the strange entities like ACE labels.

However, whether or not we discourage use of ACE labels or showing them
to real humans, I think the text I posted above still makes sense.

Peter

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

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 22 Jul 2010 03:57:59 +0500

> How is it reasonable to expect anyone to enter such strings?

The only cases where such strings would be useful are constrained UIs,
but that's a UI issue, not a protocol one. As I just noted in my other
email, IDNA apparently discourages their use, unless there's a strong
reason to use them.

> I strongly suspect that no XMPP clients support ACE labels, and that few

I suspect none do at all :)

> specification of XMPP itself we don't need to mention that.

Agreed. IDNA notes that things like DNS resolver libraries, and
DNS/name servers are often limited to ASCII, therefore ToAscii must be
applied to strings passed to them (and perhaps from them), but that's
out of scope for a XMPP spec.

> implementation, feel free. :)

That was the idea. While an upper limit on input isn't required for an
efficient implementation, it's a nice-to-have.

--
Waqas Hussain

---

From: Waqas Hussain <[email-masked]>
Date: Thu, 22 Jul 2010 04:02:44 +0500

> to real humans, I think the text I posted above still makes sense.

Does the last sentence in the proposed text render existing servers
non-compliant?

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 17:06:07 -0600

> Does the last sentence in the proposed text render existing servers

Hmm. That would be:

###

If an XMPP application receives as input an ACE label, it MUST convert
that ACE label to an internationalized label using the ToUnicode
operation (see [IDNA2003]) before including the label in an XMPP
domainpart that will be communicated over the wire on an XMPP network.

###

We'd need to see what existing applications do, but I suspect that the
text as written would make applications non-compliant, so we might want
to rethink it.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Jul 2010 21:10:45 -0600

> text as written would make applications non-compliant, so we might want

Among other things, I think that sentence is too constraining. For
instance, instead of converting the ACE label to an internationalized
label, the application simply reject the ACE label (or the request that
includes an ACE label). So "SHOULD" seems to be the strongest word we
can use here.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 22 Jul 2010 17:09:58 +0900

Hi,

> (via website, by calling someone on the phone, etc.).

As you wrote, this issue is not specific to in-band registration, but
is related to the global logics of jid naming. Hence I think it has
its place in draft-ietf-xmpp-address.
Still another XEP can be suitable to detail such information, but not
XEP-0077. Probably XEP-0165 or similar ("Best Practices to Discourage
JID Mimicking", so a fairly good name correspondence, which is cited
from draft-ietf-xmpp-address but has unfortunately a status of
"deferred" and not updated since 2007. It might be an occasion to
update this and set it back on the standardization track?) can make
the deal.

In my opinion, it is good for server to have character restriction
politics (probably depending on their country implantation, their
customers/users, their tld, or international services could accept all
kind of characters set but not to mix different, etc.). And this
should be an advice to XMPP services in a "best practice" paper,
because as you say, they are some kind of localname registrar. And as
such, they have some responsibility.

But the most important "best practice" is for clients to warn when
they detect "strange" localnames OR domain names (as browsers do)
because oppositely to actual domain name registrar, the list of XMPP
servers is infinite and unknown. We cannot know the politics of each
and every XMPP server so that we can make specific rules depending on
our contact (as browsers like Firefox do for domain name: specific
display rules depending on the tld, because they know the restriction
politics of each). Then we are not protected from servers with weak
security restrictions in their naming politics or roguer servers. We
don't choose our contact's servers, but we can choose our client with
a good security layer.

Anyway as a conclusion, I agree that we should maybe not clutter the
draft-ietf-xmpp with details (just a vague security text as it is now
is good), but we should give more details on a separate XEP dedicated
to this (update XEP-0165 probably, or a new one, whatever), with
recent discussions conclusion, background explanation on the issues
and the solutions currently adopted (by browsers and registrars among
other things), etc.
Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Jul 2010 15:17:13 -0600

On 7/22/10 2:09 AM, Jehan Pagès wrote:
> is good), 

OK.

> but we should give more details on a separate XEP dedicated

I agree that it would be good to write a best practices document on
these topics, once we figure out what the best practices are. :) Not
only are these issues are complex and messy, but as a community we
haven't thought about them very much.

Peter

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

---

From: Jehan Pagès <[email-masked]>
Date: Fri, 23 Jul 2010 16:24:20 +0900

Hi,

> haven't thought about them very much.

Yes that's probably another good reason why it is better in a XEP than
in an ietf rfc, in fact. It is easier to update this way, in the same
time as security considerations improve on such matters.

And yes again, best practices for such topics are definitely good to
prepare the common malevolent misuses (this JID/domain name mimicking
issue, and all other sort of misuses, scam, spam, etc.) that any other
kind of network which got widely used has unfortunately known.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Jul 2010 14:20:17 -0600

[Typed while in flight, delivery will be delayed.]

> includes an ACE label). So "SHOULD" seems to be the strongest word we

With a bit of further tweaking, I currently have:

###

   XMPP application receives as input an ACE label, it SHOULD convert
   domainpart that will be communicated over the wire on an XMPP network
   (however, instead of converting the label, there are legitimate
   reasons why an application might instead refuse the input altogether
   and return an error to the entity that provided the offending data).

###

/psa