On Wed, Nov 3, 2010 at 7:02 AM, Simon McVittie < [email protected]> wrote: > On Tue, 02 Nov 2010 at 18:11:18 -0400, zhong ming wu wrote: >> Moreover assuming DNS is safe (big assumption in the past & some will >> say now) should client not do DNS look up and then use server cert to >> verify authenticity of it > > DNS can't be assumed to be safe; anything we're told via a SRV lookup is > suspect. The thing we're trying to verify is: > > * the user told us to connect as [email protected], therefore they wanted to > talk to the example.com server > * we got a connection to a server claiming to serve example.com > * is it really authorized to act on behalf of example.com? > > If there's a SRV record telling us we should actually connect to > jabber.services.example.net (or whatever), accepting a certificate for > jabber.services.example.net would be unsafe, because that's not what the > user asked for.
You made good points. But there are cases where user can get the server that host xmpp service not necessarily from DNS; they choose not to publish it for whatever reason. Imagine an organization wanting to use xmpp service using example.org domain and have it hosted at xmpp.provider.com and they made the user enters the hostname in the client; pidgin and alike have the option for a reason. In that case you may still consider your point of giving priority to user entered input as still valid but I don't. Someone (possibly an unauthorized adim from example.org who can get example.org certificate) could take over DNS of provider.com and set up xmpp.provider.com and intercept the xmpp communications of example.org >> TLS implementation of HTTP/SMTP/IMAP/POP do not work like XMPP in this regard > > HTTPS doesn't do SRV lookups, but when you use a CNAME it behaves just like > XMPP. If I connect to https://www.google.com/ I get this: > > s...@reptile% dig www.google.com > ... > ;; QUESTION SECTION: > ;www.google.com. IN A > ... > ;; ANSWER SECTION: > www.google.com. 348 IN CNAME www.l.google.com. > www.l.google.com. 156 IN A 209.85.227.103 > ... (and more geolocated addresses for www.l.google.com) > > and when I connect to 209.85.227.103 (or whatever), it presents a certificate > for www.google.com (not for www.l.google.com or 209.85.227.103). > > S > Or in the old way www.cnn.com points to multiple ips and the browser randomly choose one; https thus merely checks that www.cnn.com and the server it connects matches. I think SMTP might be a slightly better example although with that TLS is not supposed to be mandatory. MTA looks up MX record and connects to the mx server and can/is supposed to verify that the mx server presents the certificate with matching mx hostname which is not necessarily the same email domain that MTA is delivering. MX record is not supplied by the sending user but MTA looks it up.
