Subject: [xmpp] dealing with "bad" certificates on s2s connections

From: Philipp Hancke <[email-masked]>
Date: Tue, 08 Jun 2010 16:37:02 +0200

5.3.2.2. claims that
"STARTTLS failure is not triggered by TLS errors such as bad certificate 
or unknown certificate authority; those errors are generated and handled 
during the TLS negotiation itself".
This is not true for the majority of deployed servers which let the TLS 
handshake succeed in any case and then do dialback after starttls.
	
Making the TLS layer send an alert is appropriate when the certificate 
is revoked, possibly also when the certificate is expired and in some 
other cases.

Doing this for unknown CAs (or self-signed certificates) is not 
realistic while claiming to do "open federation", see 
http://mail.jabber.org/pipermail/standards/2007-July/016086.html

This also conflicts with the recommendation in 13.14:
"To help prevent this attack, the parties SHOULD protect the channel 
using TLS before proceeding, even if the presented certificates are 
self-signed or otherwise untrusted."
which in turn also contradicts 13.7.2.1.1 sub-case #2:
"the application SHOULD terminate the connection (with a bad certificate 
error) and log the error to an appropriate audit log".
I was actually looking for a <bad-certificate/> stream error before 
realizing that this should be a bad_certificate error at TLS level.

The recommended default at the end of that subcase is not realistic imo.
Additionally, draft-ietf-xmpp-dna says (in 7.2) that a peer server
"MUST NOT disconnect when the certificate received does not contain a 
name matching its expectations", which is going to be hard if the 
default is to disconnect.

Fortunately, that is the only remaining major technical snafu^Wissue 
that I have ;-)

philipp