[Standards] RFC 3920, 10.2/10.3: subdomain routing rules

Matthias Wimmer m at tthias.eu
Thu Mar 29 13:52:58 UTC 2007


Hi Dave!

Dave Cridland schrieb:
>> We are open to this type of attack at present anyway. XMPP s2s does 
>> only authenticate the sending server of a connection - NOT the 
>> receiving server.
> Oh. TLS deployment is that bad?

Even if destination certificate would be checked we would not gain 
anything as long as we support dialback. An attacker would just not 
offer TLS but just dialback.

I considered checking destination certificates several times. But what 
would I do if the certificate could not be verified? Don't nail me down 
on the number, but I expect that about 50% of the certificates for my 
peers are invalid. I only seem to have two options:
- Not peering with them. This would not encourage people to get valid 
certificates. Most admins would probably just stop using TLS at all.
- Fall back to using dialback. Oh what cool improvement. Because I do 
not trust the certificate I go to transmit stanzas totally in clear.

Both not very appealing options ...

As I said: The only situation where I consider destination cert checks 
possible at present are in closed environments or with a configured set 
of destination hosts.

> Well, with TLS+SASL, you can authenticate both ends. It gets quite 
> amusing to do, because of the certificate authorities, but it is practical.

The problem is not, that we cannot do mutual authentication. The problem 
is, that we have to keep with legacy protocols for now (i.e. dialback).

> The problem is you have to essentially mandate a list of CAs, as I 
> understand things. Or, you can use leap-of-faith TLS in combination with 
> dialback, and at the least heavily reduce the attack's practical benefit.
> 
> Leap-of-faith TLS is basically where you assume that the certificate is 
> correct the first time, and you assume that a change - if the new 
> certificate is still not verifiable - is a spoof. It's not perfect, but 
> since people rarely want to intercept data from servers which have never 
> been used before, it's quite practical.

Yes the ssh type of key verification. I don't think that it would work 
for XMPP s2s. What do you do if the certificate changes? There are quite 
some reasons why a server could get a different certificate:
- multiple s2s instances, each operating with its own certificate
- certificate replacement because cert expired
- certificate replacement because data has to be added to the cert
- change of used CA
- change of key type
- old certificate lost

This works with ssh, as there is a user, that can be asked if he accepts 
the changed certificate. But it does not work very well for machine to 
machine connections.


Matthias



More information about the Standards mailing list