[Standards] RFC 3920, 10.2/10.3: subdomain routing rules
m at tthias.eu
Thu Mar 29 13:52:58 UTC 2007
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
More information about the Standards