diff options
author | Jack Lloyd <[email protected]> | 2016-11-28 22:32:39 -0500 |
---|---|---|
committer | Jack Lloyd <[email protected]> | 2016-11-28 22:32:39 -0500 |
commit | edee962bf5ecfa7776bf6dfc2ed835fce2374e4b (patch) | |
tree | 81cc51e856cd52c11e7ec9d356dd4df1f08ae180 | |
parent | 1e53889e902cbd1ad95cde529be5ae7903d30482 (diff) |
Update roadmap with plans for 2017 [ci skip]
-rw-r--r-- | doc/roadmap.rst | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/doc/roadmap.rst b/doc/roadmap.rst index ccac29a28..668e5553a 100644 --- a/doc/roadmap.rst +++ b/doc/roadmap.rst @@ -63,3 +63,69 @@ Ongoing Issues Documentation could always use help. Many things are completely undocumented, few things are documented well. + +Plans for 2017 +---------------------------------------- + +It's an open question how many of these will end up being backported to 2.0.x, +versus being features only in 2.1.x development snapshots. + +TLS 1.3 +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The RFC process seems to be approaching consensus so hopefully there will be a +final spec soon. + +The handshake differences are quite substantial, it's an open question how to +implement that without overly complicating the existing TLS v1.0-v1.2 handshake +code. There will also be some API changes to support 0-RTT data. + +This is a major project and probably will not start until later in the year. + +TLS Hardening/Testing +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Improve testing of TLS: leverage TLS-Attacker better, for example using custom +workflows. Add tests using BoringSSL's hacked Go TLS stack. + +X509_Certificate Refactor +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The certificate classes use a type called Data_Store which ends up shoving +everything (DN values, extension info, etc) into a single std::multimap<string,string>. +This was a bad design. Instead the certificate type should contain X509_DN +objects for the subject and issuer, an int value for the format version, and so on. +The Data_Store type should be removed entirely. + +ASN.1 Redesign +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The current ASN.1 library (DER_Encoder/BER_Decoder) does make it +roughly possible to write C++ code matching the ASN.1 structures. But +it is not flexible enough for all cases and makes many unnecessary +copies (and thus memory allocations) of the data as it works. + +It would be better to have a system that used (a simple subset of) ASN.1 to +define the types as well as encoding/decoding logic. Then new types could be +easily defined. This could also obviate the current code for handling OIDs, and +allow representing the OIDs using the natural OID tree syntax of ASN.1. + +Another important feature will be supporting copy-free streaming decoding. That +is, given a (ptr,len) range the decoding operation either returns an error +(throws exception) or else the decoded object plus the number of bytes after ptr +that contain the object, and it does so without making any allocations or +copies. + +It will probably be easier to be consistently allocation free in machine +generated code, so the two goals of the redesign seem to reinforce each other. + +Interface to PSK and SRP databases +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Adding support for databases storing encrypted PSKs and SRP credentials. + +Ed25519 signatures +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Used by many protocols these days including SSH and Tor. +Probably will be done by importing from SUPERCOP or similar. |