Subject: [xmpp] DNS service domains.

From: Kevin Smith <[email-masked]>
Date: Tue, 8 Jun 2010 18:14:10 +0100

I think someone else raised this, but I don't see it now:
" In the absence of a secure DNS option (e.g., as provided by
   [DNSSEC]), the initiating entity MUST check that the target domain
   name returned in a DNS SRV record matches the original service domain
   that was queried.  If the target domain name (e.g.,
   "connect.example.net") is not in the queried domain (e.g.,
   "example.com"), the connecting application MUST warn a human user (if
   any) about the mismatch and require the user to approve the
   connection before the client proceeds; however, the client MAY also
   allow the user to add the presented hostname to a configured set of
   accepted hostnames to expedite future connections."

If the host is able to present a valid cert chain for the original
target domain name, this seems redundant (and actively harmful to
hosted solutions).

/K

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 9 Jun 2010 15:13:47 -0700

> target domain name, this seems redundant (and actively harmful to

Actually, there are two issues with the above text (which comes from 
13.9.2 Use of DNS).  3.2.4 (SRV Security Checks) cites:

    In the absence of a secure DNS option (e.g., as provided by
    [DNSSEC]), the initiating entity SHOULD check that the target domain
    name returned in the SRV record matches the origin domain that was
    queried.  If the target domain name is not within the trust
    boundaries of the origin domain, the connecting application SHOULD
    verify with the human user (if any) that the SRV target domain name
    is suitable for use before executing any connections to the IP
    address of the XMPP service.

One is a disagreement on SHOULD vs MUST for the same function.

Secondly, what are the limitations on the 'trust boundary' or 'queried 
domain' when determining whether the target domain is within it?  Is it 
that the target and queried domains share just two levels from the root 
(example.com) or that they differ only in the target having an extra label 
(xmpphost.example.com for example.com) ?  If the target domain has two 
levels (eg, xmpp.services.example.com.aq for example.com.aq), is it still 
within the trusted boundary?

Kevin's suggestion of having the client connect and retrieve the cert 
chain would appear to solve this.

-- 
   Bruce.

---

From: Paul Aurich <[email-masked]>
Date: Wed, 09 Jun 2010 16:29:46 -0700

On 2010-06-09 15:13, Bruce Campbell wrote:
> (example.com) or that they differ only in the target having an extra
> label (xmpphost.example.com for example.com) ?  If the target domain has
> two levels (eg, xmpp.services.example.com.aq for example.com.aq), is it
> still within the trusted boundary?

I also don't really relish adding in an entire database of top-level
domains (that may be the wrong term) into an XMPP client, since the
client needs to know that example.co.uk and example2.co.uk cross a
'trust boundary', whereas 1.example.com and 2.example.com are in the
same 'trust boundary' (at least, based on my assumption of what 'trust
boundary' means :) ).

~Paul