issue #85, prepare for Quantum Computing, part 2/2, phase 1

In phase 1, we have defaults set to disabling requirements for
Post Quantum cipher suites.

Part 2/2 adds flags `Q` and `q` to the validation expression language.
These flags currently fail on all accounts, but can still be used
in an OR compisition, with alternatives that you would like to
remove later.  In other words, the TLS Pool allows you to get
started with Quantum Proofing today.  If the cipher suites that
fall under your other options get in disgrace in the future, you
may find that your validation expressions silently fall back to
these extra OR options.

Note that TLS-KDH is a Post Quantum cipher suite.  When we finally
have our own unique code for this cipher suite, we can implement
tis positive results for both the `Q` and `q` flags.

diff --git a/doc/validation.md b/doc/validation.md
index fd78722..8e2b01e 100644 (file)
--- a/doc/validation.md
+++ b/doc/validation.md
@@ -37,6 +37,24 @@ rope-pulling contest between PKIX and real-life security):
     the validity period of pinned identities, resulting from limited validity of
     the certificate received.
 
+-   **Post Quantum:** this constrains the cipher suites to only those that hold
+    up under an attack by a quantum computer.  This is a much more
+    [realistic threat](http://internetwide.org/blog/2018/02/10/quantum-crypto-1.html)
+    than people think, so the ARPA2 project has a plan for
+    [getting over Quantum Computers](http://internetwide.org/blog/2019/02/11/quantum-crypto-2.html)
+    of which the ability to enforce it in the TLS Pool is an important part.
+    It makes no sense at present to enforce Post Quantum crypto, as too few
+    options exist today, certainly in connections to remote servers.  The best
+    course of action would be to leave the default settings, and let us change
+    these settings once we are satisfied that it works sufficiently often and
+    can indeed be enforced.  We will of course take care of versioning constraints
+    for underlying crypto software to ensure that the new cipher suites are then
+    available.  Leave the defaults for an easy ride, or at best play with them
+    for a while; you will see that the results are devastating for now, but the
+    conclusion should *not* be to disable these settings actively, but rather to
+    remove them from the configuration file let the TLS Pool distribution care
+    for it, and time the change.
+
 -   **Forward Secrecy:** the use of a suitable cipher suite ensures that future
     reverse engineering of a private key does not make stored sessions from the
     past decipherable.
@@ -170,6 +188,19 @@ operations:
     error if a non-critical extension turns up in a credential as a critical
     extension.
 
+-   `Q` and `q` evaluate protection of cipher suites against quantum computing.
+    Where `q` refers to authentication in a manner protected from quantum
+    computers, and `Q` refers to such encryption strength.  The thing we need
+    as fast as possible is `Q`, because current encrypted sessions can be stored
+    and rewound for decryption in the (near) future.  This is more serious than
+    the protection on authentication with `q`, as future quantum computers will
+    not be able to authenticate with today's credentials.  For now, both options
+    lead to flat-out failure, simply because the guarantees cannot be given.
+    You should not learn that they cannot be used however; just be aware that
+    you should always leave other options in your expressions.  Once most or
+    all people have evolved to post quantum crypto you can remove the other
+    options, if you decide then that they are wanting or lacking.
+
 -   `O` and `o` validate online/live information; for X.509 this means that a
     predefined OCSP central responder under local management is being contacted;
     for OpenPGP `O` means the same as `G` and `o` means the same as `g`. Where

diff --git a/src/starttls.c b/src/starttls.c
index 2099084..f8ec526 100644 (file)
--- a/src/starttls.c
+++ b/src/starttls.c
@@ -3314,6 +3314,19 @@ static void valexp_Cc_start (void *vcmd, struct valexp *ve, char pred) {
 }
 
 
+/* valexp_Qq_start -- validation function for the GnuTLS backend.
+ * This function ensures a post-quantum cipher suite.
+ * While _Q_ focusses on encryption, _q_ focusses on authentication.
+ * There is currently no variable to protect the handshake, as that
+ * may well prove impossible.
+ */
+static void valexp_Qq_start (void *vcmd, struct valexp *ve, char pred) {
+       /* Work to be done for TLS designers! */
+       /* Once we get TLS-KDH going we should update the code below */
+       valexp_setpredicate (ve, pred, 0);
+}
+
+
 static void valexp_error_start (void *handler_data, struct valexp *ve, char pred) {
        assert (0);
 }
@@ -3384,6 +3397,9 @@ static void valexp_switch_start (void *handler_data, struct valexp *ve, char pre
        case 'c':
                valexp_Cc_start (handler_data, ve, pred);
                break;
+       case 'Q':
+       case 'q':
+               valexp_Qq_start (handler_data, ve, pred);
        default:
                // Called on an unregistered symbol, that spells failure
                valexp_setpredicate (ve, pred, 0);

diff --git a/src/validate.c b/src/validate.c
index 2b47667..47db0cf 100644 (file)
--- a/src/validate.c
+++ b/src/validate.c
@@ -32,7 +32,7 @@
  * thanks to the limited number of variables, the size of this variable
  * can be limited to 32 bits only.
  */
-static char valexp_varchars [] = "LlIiFfAaTtDdRrEeOoGgPpUuSsCc";
+static char valexp_varchars [] = "LlIiFfAaTtDdRrEeOoGgPpUuSsCcQq";
 static int valexp_char_bitnum [128];
 typedef uint32_t valexpreqs_t;