Subject: Re: [xmpp] _xmpp-delegate SRV record

From: Jesse Thompson <[email-masked]>
Date: Tue, 16 Feb 2010 12:40:15 -0600

On 2/16/2010 11:48 AM, Peter Saint-Andre wrote:
> At XMPP Summit #8 in Brussels last week, we discussed the problem of
> delegated XMPP services in relation to encrypted streams. For example,
> let's say that im.example.com is hosted by Google Apps. To provide TLS
> for an XML stream to that domain, we would either need something like
> domain name assertions (draft-ietf-xmpp-dna) or some kind of alternate
> solution whereby example.com could officially delegate its XMPP service
> to Google. The approach we discussed would be to define a new SRV record
> for an XMPP delegate:
>
> _xmpp-delegate._tcp.im.example.com google.com
>
> The connecting entity would then perform a standard SRV lookup on the
> delegate, for example:
>
> _xmpp-server._tcp.google.com
>
> The connecting entity would then resolve one of the provided hostnames
> and connect to that IP address. When the digital certificate presented
> says "google.com" instead of "im.example.com", the connecting entity
> would know that it's OK to proceed.
>
> The primary problem with this approach is that, absent DNSSEC, it is
> insecure (someone could point your XMPP service at some other hosting
> provider). However, the assembled throng in Brussels had rough
> (non-IETF) consensus that this would be a fine approach for delegating
> service once we have DNSSEC, so the security issues are temporary.
> However, we promised to raise this on the XMPP WG list for broader
> discussion.
>
> Thoughts?

 From the perspective of an XMPP hosting provider who suffers from 
certificate mismatch issues with virtual domains, I like this solution a 
lot.  It's simple to understand and will be easy to implement (minus the 
DNSSEC part.)  I'm not involved with our DNS service, so I don't know 
how close it is to implementation in our namespace 
(http://arstechnica.com/security/news/2009/09/securing-the-edu-top-level-domain-with-dnssec.ars). 

Domain owners might not care enough about the certificate mismatch 
errors to bother with the extra hassles and costs involved with 
implementing xmpp-dna.  I think it will end up being a "herding cats" 
scenario.

My feeling is that it will be easier for a few coordinated ISP 
administrators to solve one large problem (implementing DNSSEC) than it 
is for many disintegrated domain owners to independently complete one 
medium sized task (obtaining attribute certs.)  Maybe that's just 
wishful thinking.

Jesse

-- 
   Jesse Thompson
   Division of Information Technology, University of Wisconsin-Madison
   Email/IM: [email-masked]