|
|
# Planning for GnuTLS 3.4 #
|
|
|
|
|
|
## New Features
|
|
|
### API:
|
|
|
* [x] **A simple API for AEAD ciphers**: The current API for AEAD ciphers does not take advantage of the inherent simplicity in AEAD ciphers (e.g., decryption + tag verification at the same step). Provide an API that simplifies usage of such ciphers. [The current API design.](https://gitorious.org/gnutls/gnutls/source/ce6389cb1fd3b641f14c0ccd57f17a51827cb2d3:lib/includes/gnutls/crypto.h#L67)
|
|
|
|
|
|
* [x] **System-keys API:** Provide an API to access keys from the system storage, if available. That should, as first step, allow accessing keys from windows key store (and also windows supported smart cards). [The current API design.](https://gitorious.org/gnutls/gnutls/source/91472921689d799cb991db84af7e04fba6b049f1:lib/includes/gnutls/system-keys.h)
|
|
|
|
|
|
* [#] **Privilege separation for private key operations:** During the development of openconnect vpn server, we realized the need for separating private key operations for typical SSL operations. That resulted in ocserv 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. **This most likely will be [part of p11-kit](http://lists.freedesktop.org/archives/p11-glue/2014-December/000523.html) and will allow isolating PKCS #11 modules**.
|
|
|
|
|
|
* [x] **Transparent support for internationalized DNS names:** Add support for [RFC6125 recommendations](https://tools.ietf.org/html/rfc6125#section-6.4.2).
|
|
|
|
|
|
### Protocol/Ciphers:
|
|
|
* [ ] **[Chacha cipher + poly1305 MAC](http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02):** 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. That in addition would allow the use of fast stream cipher in DTLS. Depends on having a new nettle release which updates to the latest draft of Chacha-poly1305.
|
|
|
|
|
|
* [x] **[AES-CCM](https://tools.ietf.org/html/rfc6655) and [AES-ECC-CCM](https://tools.ietf.org/html/rfc7251):** An alternative AES AEAD construction using CTR and CBC-MAC. Depends on porting to nettle 3.0.
|
|
|
|
|
|
* [ ] **Support for alternative to NIST elliptic curves:** There is a lot of hype around the curves defined by NIST and although there are many exaggerations, having alternatives is a good thing. Related drafts/RFCs: [http://tools.ietf.org/html/draft-josefsson-tls-curve25519-06](http://tools.ietf.org/html/draft-josefsson-tls-curve25519-06), [http://tools.ietf.org/html/rfc7027](http://tools.ietf.org/html/rfc7027)
|
|
|
|
|
|
* [x] **[Disable SSL 3.0 by default](http://nmav.gnutls.org/2014/10/what-about-poodle.html)**
|
|
|
|
|
|
* [x] **[Support for Encrypt-then-authenticate mode](http://tools.ietf.org/html/rfc7366):** That is becoming less and less relevant as GCM is becoming mainstream, but needed as the CBC ciphersuites are the only alternative and there is no plan to retire or replace them. **Note: [Implemented an errata version of the RFC](http://www.ietf.org/mail-archive/web/tls/current/msg14357.html).**
|
|
|
|
|
|
* [x] **[Fix for triple handshake](http://tools.ietf.org/html/draft-ietf-tls-session-hash-02):** Implement the proposed fix.
|
|
|
|
|
|
## House keeping:
|
|
|
* [x] **Add support for [getrandom() and getentropy()](http://lwn.net/Articles/606141/):** It proved that opening the /dev/urandom file descriptor on constructor has caused issues in servers that for some reason run close() on every available file descriptor. Using the system call interfaces would solve these issues, and simplify the code in the rng handling.
|
|
|
|
|
|
* [x] **Port to 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 switch should be combined with the chacha-poly1305 AEAD cipher inclusion. Status: port is done, but not merged yet.
|
|
|
|
|
|
* [ ] **Drop the unbound dependency in libdane:** That dependency requires either openssl or nss; and both are unacceptable. The 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 there is [patch for c-ares](https://github.com/bagder/c-ares/pull/16). |