[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 security at xmpp.org 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
> 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."
> 
> http://www.postfix.org/TLS_README.html
> 
> 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.
>>> 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
>>> that as a "lightweight" option. That won't require a global CA.
>>
>> 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 :-)=

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:

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

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?

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

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080819/369342bd/attachment.bin