[Operators] [Fwd: Re: Secure Communications Week]
stpeter at stpeter.im
Tue Aug 19 09:47:13 CDT 2008
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."
> 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
> 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
>>> 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
>> 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. :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080819/369342bd/attachment.bin
More information about the Operators