[Operators] IM Observatory @ xmpp.net

Thijs Alkemade thijs at xnyhps.nl
Sun Nov 3 10:49:34 UTC 2013

On 3 nov. 2013, at 07:27, Phil Pennock <xmpp-operators+phil at spodhuis.org> wrote:

> So as long as SSLv2 is not allowed and the server private key is long
> enough to have a reasonable expected lifetime (avoiding compromise and
> more problems than just the attacker's ability to sign a downgrade
> attack), surely a server operator can offer suites as weak as they like
> and it's only an issue if they configure the server to force its choice,
> rather than honouring the client's?  It's then the client's
> responsibility to not support suites too weak to meet the user's
> requirements.
> Thus if a server operator has to continue to support a chat client in an
> embedded device which is very dated and underpowered (TV Set top box or
> somesuch), they might well choose to support some otherwise dubious
> choices, knowing that it can't impact on the more up-to-date clients.
> So why does a server offering such ciphersuites cause it to be
> downgraded, if they're not forced on normal clients and the server
> _does_ (also & preferentially) offer suites which meet current best
> practices?

In my opionion, if you are using DES (or even worse, EXPORT-DES or eNULL) and
calling it "encrypted", then you are deceiving people.

Of course encryption is a spectrum, from "can be cracked in real-time" to
"impossible to crack", but users won't understand that. When calling something
"encrypted" to end-users, I think a good starting point would be that it would
take at least a million dollars and/or a decade to decrypt it at the current
state of technology and math.

I don't know what the current best attack on DES is - but probably because
people stopped once it could be brute-forced in a day.

Processing power is also not an argument to support DES but not RC4 (though
the latter is looking more and more flawed these days).

Also, if you assume clients always pick the strongest encryption cipher they
support, then I have a surprise for you:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131103/a55fab6e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131103/a55fab6e/attachment-0001.pgp>

More information about the Operators mailing list