Subject: [xmpp] #80: enforcement of address format

From: "xmpp issue tracker" <[email-masked]>
Date: Tue, 29 Jun 2010 16:14:24 -0000

#80: enforcement of address format
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  major               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 The specification does not define when and by whom the address format is
 enforced.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/80>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 11:52:20 -0600

> #80: enforcement of address format

Although we've moved the address format definition to a separate spec
(expecting it to be obsoleted once the PRECIS WG completes its work), we
need to specify more clearly (a) which entities are responsible for
enforcing the address format and (b) when in various processes that
enforcement occurs.

Here are some initial thoughts to spur discussion, mostly related to
user JIDs, not server or component JIDs.

IMHO the primary enforcement points are:

1. Account provisioning (don't let bad JIDs into a user database)

2. Authentication (don't let bad JIDs onto the network)

I think that the JID format MUST be enforced by the server at those points.

JIDs are used in many other ways and places, including:

3. The 'from' address of a stanza. Enforcement here is a consequence of
the server's stamping the 'from' address.

4. The 'to' address of a stanza (RFC 3920).

I think that a server MAY enforce the JID format in 'to' addresses of
outbound stanzas generated by clients -- that's a helpful service, but
not mandatory or even recommended, by any means.

I think that a server SHOULD return a <jid-malformed/> error when
discovering that the JID in the 'to' address of an inbound stanza is
malformed or simply doesn't exist (but could instead just return our old
friend <service-unavailable/>).

5. The 'jid' attribute of a roster set (RFC 3921)

Here again I think the server MAY enforce the JID format as a service to
the client.

6. The <JABBERID/> element in a user vCard (XEP-0054) along with lots of
other XMPP extensions -- data forms (XEP-0004), service discovery
(XEP-0030), chatroom invitations (XEP-0045), Jingle (XEP-0166), delayed
delivery (XEP-0203), and many more

I see no good reason to even mention these in rfc3920bis or rfc3921bis.

If we can reach consensus on the concepts here, I'll formulate some text.

Peter

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jun 2010 16:34:51 -0500

> not mandatory or even recommended, by any means.

I don't know how well this applies to XMPP, but my experience with SIP is that SIP proxies need to be very careful in policing things that don't cause them problems otherwise. In the case of an outbound stanza, I would tend to make it the destination's problem to police format errors, assuming said error does not prevent the server from forwarding the stanza in the first place, or cause some other harm to the server itself.  (I don't mean to say we should forbid doing this--just that we don't need to suggest it.)

Or, in short, this might be a good application of Postel's Law.

> I see no good reason to even mention these in rfc3920bis or rfc3921bis.

Does that sentence refer to paragraph 6, or the whole list?
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 16:44:21 -0600

>>> Type:  defect              |      Status:  new Priority:  major
>>> |   Milestone: Component:  3920bis             |     Version:
>>> enforced.
>> 
>> Although we've moved the address format definition to a separate
>> spec (expecting it to be obsoleted once the PRECIS WG completes its
>> work), we need to specify more clearly (a) which entities are
>> responsible for enforcing the address format and (b) when in
>> various processes that enforcement occurs.
>> 
>> Here are some initial thoughts to spur discussion, mostly related
>> to user JIDs, not server or component JIDs.
>> 
>> 3. The 'from' address of a stanza. Enforcement here is a
>> consequence of the server's stamping the 'from' address.
>> 
>> I think that a server MAY enforce the JID format in 'to' addresses
>> of outbound stanzas generated by clients -- that's a helpful
>> service, but not mandatory or even recommended, by any means.
> 
> I don't know how well this applies to XMPP, but my experience with
> SIP is that SIP proxies need to be very careful in policing things
> that don't cause them problems otherwise. In the case of an outbound
> stanza, I would tend to make it the destination's problem to police
> format errors, assuming said error does not prevent the server from
> forwarding the stanza in the first place, or cause some other harm to
> the server itself.  (I don't mean to say we should forbid doing
> this--just that we don't need to suggest it.)
> 

Right, it's not the sending server's responsibility to enforce the
format of JIDs at the destination server. Now, if the domain component
is malformed and the stanza can't be routed to another server in the
first place then the sending server might be justified in returning a
jid-malformed error to the originating client.

>> discovering that the JID in the 'to' address of an inbound stanza
>> is malformed or simply doesn't exist (but could instead just return
>> our old friend <service-unavailable/>).
>> 
>> Here again I think the server MAY enforce the JID format as a
>> service to the client.
>> 
>> 6. The <JABBERID/> element in a user vCard (XEP-0054) along with
>> lots of other XMPP extensions -- data forms (XEP-0004), service
>> discovery (XEP-0030), chatroom invitations (XEP-0045), Jingle
>> (XEP-0166), delayed delivery (XEP-0203), and many more
>> 

Paragraph 6.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 17:07:22 -0600

> 1. Account provisioning (don't let bad JIDs into a user database)

I've added the following sentence to Appendix C:

   An XMPP
   server implementation or administrative function MUST ensure that any
   JID assigned during account provisioning (including localpart,
   domainpart, resourcepart, and separator characters) conforms to the
   canonical format for XMPP addresses defined in [XMPP-ADDR].

> 2. Authentication (don't let bad JIDs onto the network)

This is already handled by the following paragraph in Section 4.2.6:

   The receiving entity MUST ensure that the resulting JID (including
   localpart, domainpart, resourcepart, and separator characters)
   conforms to the canonical format for XMPP addresses defined in
   [XMPP-ADDR]; to meet this restriction, the receiving entity MAY
   replace the JID sent by the initiating entity with the canonicalized
   JID as determined by the receiving entity.

> I think that the JID format MUST be enforced by the server at those points.

We seem to have agreement on that requirement.

> the server's stamping the 'from' address.

I don't think we need to add any text here, since this simply falls out
from the text in Section 4.2.6 (see above).

> not mandatory or even recommended, by any means.

Given the good points that Ben raised, I think it's best to remain
silent about any such behavior.

> friend <service-unavailable/>).

I have provisionally added the following text to Section 8.3.3.8:

      Implementation Note: Enforcement of the format for XMPP localparts
      is the responsibility of the service at which the associated
      account or entity is located (e.g., the example.com service is
      responsible for returning <jid-malformed/> errors related to all
      JIDs of the form <[email-masked]>), whereas enforcement of
      the format for XMPP domainparts is the responsibility of the
      service that seeks to route a stanza to the service identified by
      that domainpart (e.g., the example.org service is responsible for
      returning <jid-malformed/> errors related to stanzas that users of
      that service have to tried send to JIDs of the form
      <[email-masked]>).

> Here again I think the server MAY enforce the JID format as a service to

Perhaps we'll add some text about that to 3921bis. One step at a time. :)

> I see no good reason to even mention these in rfc3920bis or rfc3921bis.

I stand by that.

Peter

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

---

From: Matthew Wild <[email-masked]>
Date: Wed, 30 Jun 2010 00:36:18 +0100

>   canonical format for XMPP addresses defined in [XMPP-ADDR].

+1.

>> I think that the JID format MUST be enforced by the server at those points.

+1.

> from the text in Section 4.2.6 (see above).

+1.

> silent about any such behavior.

Ok with remaining silent, however...

>      <[email-masked]>).

...is there any harm in keeping the door open for servers to always
validate the JID? For example in Prosody we run the 'to' JID through
stringprep, and we use this prepped JID for all kinds of things,
including matching against privacy lists for a simple example.

So in our case at least we're in a good position to return
jid-malformed, it would also be a bit difficult for us to proceed with
routing the stanza knowing that the JID is invalid and we possibly
were not able to perform required processing/filtering because of
that.

>> Here again I think the server MAY enforce the JID format as a service to

Big +1, it's the main entry-point for bad JIDs because they come
directly from users, and not from authenticated entities' identities.

>> I see no good reason to even mention these in rfc3920bis or rfc3921bis.

+1. These XEPs can now simply reference xmpp-address when ready, which
will be good.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 29 Jun 2010 20:08:38 -0600

> were not able to perform required processing/filtering because of

I've tweaked the text:

      Implementation Note: Enforcement of the format for XMPP localparts
      is primarily the responsibility of the service at which the
      associated account or entity is located (e.g., the example.com
      service is responsible for returning <jid-malformed/> errors
      related to all JIDs of the form <[email-masked]>), whereas
      enforcement of the format for XMPP domainparts is primarily the
      responsibility of the service that seeks to route a stanza to the
      service identified by that domainpart (e.g., the example.org
      service is responsible for returning <jid-malformed/> errors
      related to stanzas that users of that service have to tried send
      to JIDs of the form <[email-masked]>).  However, any entity
      that detects a malformed JID MAY return this error.

> directly from users, and not from authenticated entities' identities.

Right. I'm looking forward to finishing up on XMPP-CORE so that we can
work on XMPP-IM. :)

> +1. These XEPs can now simply reference xmpp-address when ready, which

Exactly.

Peter

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

---

From: "xmpp issue tracker" <[email-masked]>
Date: Wed, 30 Jun 2010 03:06:33 -0000

#80: enforcement of address format
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  major               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 See list discussion for resolution.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/80#comment:1>
xmpp <http://tools.ietf.org/xmpp/>