[gnutls-devel] [Telepathy] mcabber GnuTLS related problem

[Nikos Mavrogiannopoulos]

On Fri, Aug 30, 2013 at 4:34 PM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:

> On 29/08/13 20:33, Niels Ole Salscheider wrote:
>
>  >>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
> ...
> >> In general there is no reason to use compression with TLS. It
> >> can only cause harm (including reveal of plaintext).
>
> XMPP is a fairly verbose protocol (XML, with namespaces used for
> extensibility). I'm led to believe that XMPP + deflate is much more
> bandwidth-efficient.
>

Hello,
 I understand that. However the length of compressed data may reveal the
plaintext data in certain scenarios, and there is no clear solution to
these issues so far. For that I'd suggest to use the uncompressed protocol
by default and allowing an option for the user to enable TLS compression
(in the case benefits outweigh the risks).

Having said that gnutls offers an new (experimental) API to control padding
and avoid the length of data reveal the plaintext. This is around
gnutls_record_send_range() and the %NEW_PADDING priority string option.


> What priority string would the GNUTLS team recommend for XMPP traffic?
> (If the answer is "don't call gnutls_priority_set_direct() by default at
> all", that'll be a little more code, but we can do that.)
>

gnutls_priority_set_direct() is required so you cannot avoid that. I'd
suggest to use the default "NORMAL" or "NORMAL:%COMPAT" option, and allow
alternatives by user options. The normal priority string will always
contain conservative security options suitable for generic usage (and will
be updated as security threats change).  By using a custom priority string
you take the responsibility of such updates.


> That's not the normal configuration. It's intended to be enabled in
> bandwidth-constrained environments by ./configure
> --enable-prefer-stream-ciphers, documented as "prefer stream ciphers
> over block ciphers to save bandwidth (at the possible expense of
> security". I believe it may have been implemented for OLPC, in which
> they initially deployed clear-text XMPP, then switched on TLS solely for
> the bandwidth-reduction of getting compression as a side-effect (their
> experimental mesh networking didn't cope well with uncompressed XMPP).
>

You may also use the "performance" string if you'd like to increase the
priority of arcfour. However recent gnutls versions also support the
AES-GCM ciphersuites that use the same bandwidth as arcfour-sha1 so normal
may as well do better there.

regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130830/d04a56e8/attachment-0001.html>