[Standards] alternate SRV records?
stpeter at stpeter.im
Mon Mar 24 15:48:44 UTC 2008
Pedro Melo wrote:
> On Mar 21, 2008, at 9:41 PM, Peter Saint-Andre wrote:
>> Some scenarios...
>> 3. Let's say that you want to advertise a c2s or s2s port where TLS is
>> required (e.g., because you have different firewall rules for non-TLS
>> connections). How about this (some different ports)?
>> _xmpp-server-tls._tcp.jabber.org 5270 athena.jabber.org
>> _xmpp-server-tls._tcp.jabber.org 5223 athena.jabber.org
> I don't think this one is required.
> XMPP requires TLS. If you don't want to use TLS, you are using Jabber,
> not XMPP. And then you should look for
Let me describe the scenario more fully, as I understand it (it was
first presented to me by the operator of an XMPP service at a Wall
Let's say you accept connections from two kinds of XMPP services:
1. Trusted services run by other companies in your industry or supply
chain. These services all receive certificates that can be traced back
to the same trusted root. You automatically accept connections from such
services, but use of (not just support for) TLS is required. Because you
trust these services, you can accept connections from them on a
connection manager or server that is located inside the DMZ.
2. Untrusted services run by companies outside your industry or supply
chain. These services may or may not have certificates, but such
certificates cannot be traced back to the trusted root used by the
services in #1 above. Because of local security policies, if you accept
a connection from such a service it must happen in the DMZ.
So you might want to have two kinds of connection manager, separately
_xmpp-server-tls._tcp.mybank.com 5270 trusted.mybank.com
_xmpp-server._tcp.mybank.com 5269 untrusted.mybank.com
The more I think about it, _xmpp-server-tls is not quite right, because
you could accept a TLS+Dialback connection from a service that does not
have a certificate issued by your trusted root. I'll have to think about
this some more...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards