[gnutls-devel] RFC for gnutls 3.4 plan

[Nikos Mavrogiannopoulos]

Hello,
 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.

New Features:
- 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.
  http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02

- 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)
  http://tools.ietf.org/html/draft-josefsson-tls-curve25519-05
  http://tools.ietf.org/html/rfc7027

- 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:
  http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-02
  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:
  http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm 
  That requires both an internet draft to be written and
  its implementation in nettle.

House keeping:  
- 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
  at:  https://github.com/bagder/c-ares/pull/16

regards,
Nikos