Re: [Operators] [Fwd: Re: Secure Communications Week]

[Peter Saint-Andre]

Johansson Olle E wrote:

1. Is TLS+Dialback better than Dialback without TLS?

Yes. Confidentiality is always an improvement.

Agreed. As long as people know what they're doing. :)

Well, yes. That applies to all security measures. I think it's important to separate issues - confidentiality, identiy, authorization and integrity. Requiring TLS, but don't bothering with the rest is a first step. Trying to solve the whole identity and authorization issue on a global

federation is something that hasn't been done yet.

Agreed. That's why still have more work to do. :) We're having a good discussion about these issues right now on the [EMAIL PROTECTED] list.

2. How *should* we handle certificates that are self-signed, issued by unknown CAs, etc.?

There is a lot we could add in a best-practise document. Self-cigned certificates doesn't belong to a CA, but can still be identified with a fingerprint. Postfix (e-mail server) supports

both fingerprints and CA-style certificate handling.

Yes it would be good to see how this is handled in mail servers.

"Certificate fingerprint verification




http://www.postfix.org/TLS_README.html

Certificate fingerprint verification is available with Postfix 2.5 and later. At this security level ("smtp_tls_security_level = fingerprint"), no trusted certificate authorities are used or required. The certificate trust chain, expiration date, ... are not checked. Instead, the smtp_tls_fingerprint_cert_match parameter or the "match" attribute in the policy table lists the valid "fingerprints" of the remote SMTP server certificate. If certificate fingerprints are exchanged securely, this is the strongest, and least scalable security level. The administrator needs to securely collect the fingerprints of the X.509 certificates of each peer server, store them into a local file, and update this local file whenever the peer server's public certificate changes. This may be feasible for an SMTP "VPN" connecting a small number of branch offices over the Internet, or for secure connections to a central mail hub. It works poorly if the remote SMTP server is managed by a third party, and its public certificate changes periodically without prior coordination with the verifying site." This is something that I think works in small, closed networks - sneakernets - or in business relationships where you exchange the fingerprint out of band.

Agreed. But I think we're past the point of having a small, closed network for XMPP. Yes, there may be trust islands on the network (e.g., supply chains and industry groups), but here we are talking about the full network.

A web-of-trust-model like PGP could also work and scale a bit more.

Or we could base a WoT on something other than PGP. As far as I can see, PGP has not been applied to server identification (the way I think of it is "PGP is for people and certs are for servers"). But we could do something like have a web of trust among servers (managed by server admins), based on the certificates presented by those servers. In a way this would mean that a server would have a "buddy list" or at least a list of entities that it trusts to some extent (which it might advertise in a public manner).

From reading server manuals and configurations, we could both improve configurations and improve documentation of this in order to make more people install certificates and

enable encryption.

that as a "lightweight" option. That won't require a global CA.

Authentication of domains can be assisted by a CA, or by DNS-sec. There are options now to store server-side SSH key fingerprints in DNS, certified by DNS-sec. We could certainly recommend doing the same with XMPP server certificate fingerprints and have

I suppose one question is: how do you check fingerprints? Do you find contact information for the hostmaster and call him on the phone? Does XMPP traffic get queued up while you do that? Do you refuse the connection and flag the s2s request for action by the xmpp admin? And is all that really easier in the end than requesting a cert at xmpp.net?

Fingerprints without a secure directory is sneakernet sponsored by Adidas. Within business relationships, fingerprints could securely be exhanged with a high level of trust. They have to be pre-insalled or fetched from LDAPS or something similar. DNS-sec is one way to trust another authority - DNS - and build upon that trust.

I don't think it's easier to use fingerprints in general, but it's a good enough alternative in many situations. And yes, in many situations it's easier to setup than requesting a cert at xmpp.net - there's no reason to contact legal services to go through the agreement and no need to install the CA certificate chain or evaluating the CA's certificate policy. A shortcut for the engineer :-)=

1. no cert
2. self-signed cert
3. CA-issued cert

Somehow I don't like the combination of "security" and "shortcut". :) IMHO it's not *that* difficult for a server admin to obtain a domain certificate (either from the XMPP ICA or some other CA), and we could work to make it a bit easier at xmpp.net (I welcome feedback about that). Yes it's always easiest to generate a self-signed cert, but I wonder what the percentages are for the following options: I bet that most servers fall under option (1) because even most server admins don't care about security. I also bet that admins who care enough to generate a self-signed cert might not realize that there are free and relatively easy options for obtaining a CA-issued cert (from xmpp.net). It's not that much harder, and it prevents all those annoying security warnings. :)

So yes, a best practices document seems like a good idea...

Can we use the wiki?

/psa

Sure. We've started using wiki.jabber.org for more pages, so feel free to start typing. :)

smime.p7s
Description: S/MIME Cryptographic Signature