[gnutls-devel] RFC for gnutls 3.4 plan
nmav at gnutls.org
Sun Jul 27 15:21:11 CEST 2014
My plan for gnutls 3.4 is listed below. I'd appreciate any
comments/recommendations, as well as additions to the list especially if
you volunteer to implement it.
- Chacha cipher
DTLS lacks a fast stream cipher, and TLS only specifies the broken
RC4. My experiments with salsa20 (the predecessor of chacha) showed
that there are indeed speed improvements and it would be nice to take
advantage of them.
- Chacha cipher + poly1305 MAC
An AEAD combination of chacha with the poly1305 authenticator for
performance in software implementations. A former variant of it
is already being used by google's servers for communication between
them and chrome.
- Support for alternative to NIST elliptic curves (e.g., brainpool or
curve25519). There is a lot of hype around the curves defined by NIST
and although there are many exaggerations, having alternatives is a
good thing. (I personally prefer brainpool but features depends mainly
on what nettle will support)
- Privilege separation for private key operations:
During the development of openconnect vpn server, I've realized the
need for separating private key operations for typical SSL operations.
That resulted to a special security module that handles the private
key operations of a less privileged worker process. That could be
generalized so that more applications can use it. The advantage of
such a design is that a bug on the TLS/ASN.1 parsing code would not
leak the server's private key (thus counter heartbleed type of
attacks). That part would be restricted to UNIX/POSIX systems so it
may be released as a different library.
- Support for Encrypt-then-authenticate mode:
That is becoming less and less relevant as GCM is becoming mainstream.
- OCB mode (not decided on that as it seems quite of thankless work)
OCB is very simple authenticated-encryption mode which performs much
better than GCM in generic-purpose CPUs (e.g., without a
special instruction for carry-less multiplication), and CCM (always).
Its license to use is now quite liberal:
That requires both an internet draft to be written and
its implementation in nettle.
- nettle 3.0
Unfortunately nettle 3.0 breaks the API and we need to convert to it
in order to use the new features of it. That probably has to be
combined with the chacha-poly1305 AEAD cipher inclusion.
- Drop the unbound dependency in libdane
That dependency requires a dependency either on openssl or nss and
both are unacceptable. My current plan is to convert libdane to a
non-validating dnssec library that depends on a validating server
running on localhost - e.g., unbound or dnsmasq. Such library
currently does not exist, but I've made a patch for c-ares
More information about the Gnutls-devel