[Council] [Fwd: Re: [Standards] "subdomains"]

Peter Saint-Andre stpeter at stpeter.im
Tue Sep 15 14:34:13 CDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is this something we want to finish before the end of the Council term?
If so I can finish making these changes...

- -------- Original Message --------
Subject: Re: [Standards] "subdomains"
Date: Thu, 10 Sep 2009 10:03:49 -0600
From: Peter Saint-Andre <stpeter at stpeter.im>
Reply-To: XMPP Standards <standards at xmpp.org>
To: XMPP Standards <standards at xmpp.org>
References: <4AA819E1.4070408 at stpeter.im>
<2fd53c3a0909100314o5c19bae1ye1b0e99ab99900ad at mail.gmail.com>
<29879.1252577935.014563 at puncture>	<4AA9078E.3060100 at stpeter.im>
<29879.1252593021.092296 at puncture>

On 9/10/09 8:30 AM, Dave Cridland wrote:

> you've made my point - the term "subdomain" is
> meaningless in most circumstances. The email address
> "peter at foo.example.net" has no relation to "peter at example.net" aside
> from a (likely) common ancestor in their management. And even that's not
> certain, given addresses like "james007 at sausage.demon.co.uk", which was
> (back when it existed) certainly not under the direct control of Demon
> Internet.

Right.

Here is the impact of airbrushing the concept of subdomain from the
XSF's specifications...

1. JID matching rules

In XEPs 16, 45, and 191 change this:

<domain> (the domain itself matches, as does any user at domain,
domain/resource, or address containing a subdomain)

to this:

<domain> (the domain itself matches, as does any user at domain or
domain/resource)

2. Addressing

XEP-0100 (Gateway Interaction) has the following text:

"The address of a gateway itself SHOULD be a hostname only, and that
hostname SHOULD NOT be supplemented with a resource identifier when
referring to the gateway's address (e.g., when storing the gateway in a
roster). The hostname SHOULD be a subdomain of a primary Jabber host
(e.g., icq.jabber.org might be the ICQ gateway run by the jabber.org
server)."

I think that is simply out of date, so I would recommend that we strike
the second sentence.

XEP-0271 (XMPP Nodes) contains the following analogy between Internet
domains and the real world:

***

... an Internet domain (e.g., jabber.org or xmpp.org) is a virtual space
or area that is controlled by an individual or organization (e.g.,
Jeremie Miller or the XMPP Standards Foundation). Given the workings of
the Domain Name System, it is also possible to have subdomains such as
planet.jabber.org or interop.xmpp.org, which can be seen as the virtual
equivalent of administrative subdivisions in the real world...

***

I think that's mostly harmless, but I might put the word "subdomains" in
scare quotes.

3. Server identity in certificates and DNS records

The only mention of subdomains in draft-ietf-xmpp-3920bis is the
following informational note:

      Note: Many XMPP servers are implemented in such a way that they
      can host additional services (beyond those defined in this
      specification and [xmpp-im]) at hostnames that are subdomains of
      the hostname of the main XMPP service (e.g.,
      conference.example.net for a [XEP-0045] service associated with
      the example.net XMPP service) or subdomains of the first-level
      domain of the underlying host (e.g., muc.example.com for a
      [XEP-0045] service associated with the im.example.com XMPP
      service).  If an entity from a remote domain wishes to use such
      additional services, it would generate an appropriate XML stanza
      and the remote domain itself would attempt to resolve the
      service's hostname via an SRV lookup on resource records such as
      "_xmpp-server._tcp.conference.example.net." or "_xmpp-
      server._tcp.muc.example.com.".  Therefore if a service wishes to
      enable entities from remote domains to access these additional
      services, it needs to advertise the appropriate "_xmpp-server" SRV
      records in addition to the "_xmpp-server" record for its main XMPP
      service.

This is reflected in XEP-0178 (Best Practices for Use of SASL EXTERNAL
with Certificates):

***

As specified in RFC 3920 and provisionally clarified in rfc3920bis, if a
JabberID is included in an X.509 certificate, it MUST be encapsulated as
an id-on-xmppAddr Object Identifier. Although it is not necessary for an
X.509 certificate to include a JabberID, it is RECOMMENDED that server
certificates include the id-on-xmppAddr OID encapsulating the JabberID
of the bare XMPP server domain only (e.g., "example.org"). In addition,
it is RECOMMENDED in the case of server certificates for the server's
hostname to be encapsulated as a subjectAltName extension of type
dNSName. Furthermore it is quite common for XMPP servers to also offer
associated services as subdomains of the server; if a server offers such
services then it is RECOMMENDED to either include an id-on-xmppAddr OID
for each subdomain or to include a dnsName containing the wildcard
character '*' applying to the left-most domain name component or
component fragment (this is considered to match any single component or
component fragment, e.g., *.example.org matches foo.example.org but not
bar.foo.example.org, and im*.example.net matches im1.example.net and
im2.example.net but not chat.example.net). This specification includes
recommendations that address all three cases.

***

That recommendation seems appropriate.

XEP-0178 also has this:

***

Server2 advertises SASL mechanisms. If Server2 expects that Server1 will
be able to authenticate and authorize as the identity provided in the
certificate that Server1 already provided (e.g., because the two servers
share a common root certification authority, Server1's certificate has
not been revoked, and the address provided in the 'from' address of
Server1's initial stream header matches the authentication identity or a
subdomain thereof), then Server2 SHOULD advertize the SASL EXTERNAL
mechanism.

***

That seems wrong to me, so I would recommend striking the phrase "or a
subdomain thereof".

In XEP-0220 (Server Dialback) we talk about piggypacking / multiplexing
and mention subdomains:

***

A single XML stream between Originating and Receiving Server can be used
to multiplex stanzas for more than one domain pair. This usage is for
historical reasons also known as "PIGGYBACKING". One common motivation
for this is virtual hosting, for which many domains are hosted on the
same server. Another common motivation for such reuse is the existence
of additional services associated with the Sender Domain but hosted at
subdomains thereof. For example, both the "target.tld" and the
"sender.tld" XMPP servers might host a groupchat service at
"chat.target.tld" and "chat.sender.tld" respectively. Without
multiplexing, many server-to-server connections would be necessary to
exchange stanzas between those domains. With more domains, the number of
connections might exceed the maximum number of connections allowed from
a single IP address as explained in Best Practices to Discourage Denial
of Service Attacks [10]. Multiplexing reduces the number of connections
to two.

***

Given how dialback works (based on DNS using a callback to the base XMPP
domain), that text is probably fine, but I need to think about it some more.

Peter


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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqv7DUACgkQNL8k5A2w/vyH8QCgvNzCoKqA7QNiEl4nNgpsaLfy
4LUAoPzRVN2yya3rhcLDs0B2YS1zV1Py
=/vc+
-----END PGP SIGNATURE-----


More information about the Council mailing list