I remember reading about this somewhere before, so if you can find the
reference please post it:
What's the _preferred_ action to take when trying to establish an IP
address for a remote server while doing s2s dns lookups?
So eg: looking up the server to send a message to
bob (AT) department (DOT) example.com should result in:
SRV IN
SRV IN (optional)
SRV IN (optional)
AAAA IN department.example.com (optional)
A IN department.example.com
then if those all fail do/should/must/may/shouldn't/mustn't we try:
SRV IN _xmpp-server._tcp.example.com
SRV IN _jabber._tcp.example.com (optional)
SRV IN _im._tcp.example.com (optional)
AAAA IN example.com (optional)
A IN example.com
and then:
SRV IN _xmpp-server._tcp.com
SRV IN _jabber._tcp.com (optional)
SRV IN _im._tcp.com (optional)
AAAA IN com (optional)
A IN com
Most jabber servers seem to give up and _not_ do the dns cascade, but
Wildfire seems to do the cascade DNS, generating lots of 'Failed to
lookup .de', or 'Failed to lookup .org' records in the log files.
ref:

7/4/06, Norman Rasmussen <norman (AT) rasmussen (DOT) co.zawrote:
Most jabber servers seem to give up and _not_ do the dns cascade, but
Wildfire seems to do the cascade DNS, generating lots of 'Failed to
lookup .de', or 'Failed to lookup .org' records in the log files.

So you say if I'm hosting your parent domain I could take-over and
spoof your non-functioning (DDoS'ed) XMPP server? Sending SPIM,
harvesting password. Possibilities are endless. Great, just great.
:-D

07/06/2006 06:21 PM, Tomasz Sterna wrote:
7/4/06, Norman Rasmussen <norman (AT) rasmussen (DOT) co.zawrote:
>Most jabber servers seem to give up and _not_ do the dns cascade, but
>Wildfire seems to do the cascade DNS, generating lots of 'Failed to
>lookup .de', or 'Failed to lookup .org' records in the log files.

So you say if I'm hosting your parent domain I could take-over and
spoof your non-functioning (DDoS'ed) XMPP server? Sending SPIM,
harvesting password. Possibilities are endless. Great, just great.

Given jabber clients' genearlly poor support of SSL/TLS certificate
verification (kudos to Psi for doing it right), resistance to DNS-based
attacks seems like a definite non-priority for the jabber community.

2006-07-06 22:34, Peter Saint-Andre wrote:
Jefferson wrote:
07/06/2006 06:21 PM, Tomasz Sterna wrote:
7/4/06, Norman Rasmussen <norman (AT) rasmussen (DOT) co.zawrote:
Most jabber servers seem to give up and _not_ do the dns cascade, but
Wildfire seems to do the cascade DNS, generating lots of 'Failed to
lookup .de', or 'Failed to lookup .org' records in the log files.
So you say if I'm hosting your parent domain I could take-over and
spoof your non-functioning (DDoS'ed) XMPP server? Sending SPIM,
harvesting password. Possibilities are endless. Great, just great.
Given jabber clients' genearlly poor support of SSL/TLS certificate
verification (kudos to Psi for doing it right), resistance to DNS-based
attacks seems like a definite non-priority for the jabber community.

RFC 3920 says how to properly handle certificates. Unfortunately, server
certificates are not widespread yet (let alone client certificates). But
I'm working to change that

Indeed I think the RFC is pretty much on target in its SSL/TLS
specification. My criticism above is that clients have failed to follow
the RFC.

There are in fact many servers using self-signed certificates but that
accomplishes very little when clients don't even bother to warn users
about bad certificate chains. In a way, the current focus on getting
server certificates signed by a CA is a red herring; it doesn't matter
so much if they're self-signed AS LNG AS the client WARNS the user that
the cert can't be verified. After all, the user can import a self-signed
certificate into his or her local trust database at first use and at
least be alerted when the certificate CHANGES, indicating an attack
either now or at the time of import. This is not an uncommon
protocol look at SSH host key handling.

I do have a concern about the RFC, in the details of cn matching
performed when SRV records are involved. While clearly you do the right
thing in ignoring the hostname returned in an SRV record for purposes of
cn matching, the defined approach imposes a problematic constraint on
servers: if I want to offer a certificate for users @example.com, I must
use a certificate for "example.com". Because the cn of this certificate
is the domain root, if stolen it could be used to spoof other services
for the domain root itself. Meanwhile, since jabber servers are a new
breed, there remains a great deal of unaudited server code. The prospect
of having a certificate for my domain root running in an unaudited piece
of server software exposed to the world is one I do not relish.

An alternative might have been to match the cn against the same name
used in the successful SRV query (the query, not the result). So if for
example the successful SRV query was for _xmpp-server._tcp.example.com,
the certificate cn could have that same name, in addition to
example.com. This would allow use of server certs that don't have as
much value to an attacker if compromised.

I'm not certain exactly what the best approach would be, but the status
quo is not ideal in my view.

07/12/2006 06:02 AM, Benjamin Podszun wrote:
Jefferson wrote:
>I do have a concern about the RFC, in the details of cn matching
>performed when SRV records are involved. While clearly you do the right
>thing in ignoring the hostname returned in an SRV record for purposes of
>cn matching, the defined approach imposes a problematic constraint on
>servers: if I want to offer a certificate for users @example.com, I must
>use a certificate for "example.com". Because the cn of this certificate
>is the domain root, if stolen it could be used to spoof other services
>for the domain root itself. Meanwhile, since jabber servers are a new
>breed, there remains a great deal of unaudited server code. The prospect
>of having a certificate for my domain root running in an unaudited piece
>of server software exposed to the world is one I do not relish.

I have two issues with this paragraph: The first/obvious one is probably
nitpicking anyway, but I'd really like to hear what you call "new
breed". claims, that jabberd was 1.0 in
2000, which is not that new to me. But as I said, this might be nitpicking.

I'm aware that XMPP has history; I still, however, consider a 2000 1.0
release new. And my strong impression is that there has been very little
investigation of security vulnerabilities in XMPP implementations, which
is the principle concern. Newness is not the whole story look at
Sendmail for an example of a program that is about as old as anything in
current use, yet another significant vulnerability was disclosed within
recent months. Contrast, for example, the audit history of any of the
popular jabber servers with that of, say, Apache. Not only are there
typically many, many more eyes on Apache, Apache has also been the
subject of a great deal of rigorous auditing. So I agree that "new" is a
subjective characterization, but I hope you see my point.

A completely different question comes to my mind when you talk about the
certificate: Even if your certificate for the CN example.com would be
stolen, what exactly is your connection to other services here? Each
service could imo use a different certificate - if you want that. And
all your clients should notice a change of a certificate anyway?

If the private key for a valid certificate for example.com is stolen, an
attacker can use it to spoof any service for example.com. It doesn't
matter if you use different certificates for other services. The only
thing encoded in the certificate cn is the domain name. (There are usage
constraints on certificates that may differentiate SSL server
certificates from personal client certificates, for example, but nothing
that specifies valid services.) In fact, if you do buy different
certificates for different services, you're just throwing money away
certificate for example.com is valid for any service found at that address.