Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for Quantum Computing #85

Closed
vanrein opened this Issue Feb 13, 2019 · 2 comments

Comments

Projects
None yet
1 participant
@vanrein
Copy link
Contributor

vanrein commented Feb 13, 2019

With the upcoming threat of Quantum Computing and how we think to get over it there are a few new requirements for the TLS Pool. They are not too compex, because the TLS work is delegated to an existing stack.

Requirements in the Config File

We should add an entry to the config file, like like:

# Quantum Computing Protection.  When set, these flags assure that
# TLS connections are only accepted when they are protected from
# attacks with Quantum Computers.  This is quite restrictive; the
# algorithms known to fail include RSA, DSA, ECDSA and even plain
# DH and ECDH.
#
# The level of protection in `quantum_proof_authentication` sets
# the selection of any mechanisms usable for signatures proving
# the identity of the client and/or server.  This is the minimum
# level, but it may already be steep in a transitioning phase.
# 
# The level of protection in `quantum_proof_encryption` sets the
# privacy of the connection, but applies to the application level
# and not the handshake.
#
# The level of protection in `quantum_proof_names` adds privacy
# for the identities exchanged during the handshake (and is quite
# restrictive).
# 
# Initially, these flags will be disabled by default while it is too early
# to make the switch.  However, as soon as it becomes practical,
# any new releases of the TLS Pool will enable them by default.
# The trigger for this will be when sufficient software supports
# Quantum Proof cipher suites.  Note that this is not the same
# as every site administrator having rolled out this software; if
# we wait for that to complete we create a new chicken/egg
# problem, much like IPv6 which is hampered by continued use
# or the "temporary" stop-gap measure NAT.  The TLS Pool is
# part of the ARPA2 mindset that wants to get over such
# critical-mass problems.
# 
# If you feel you need to actively disable any flags, overriding
# the defaults, the suggestion is to plan a future date at which
# this temporary setting will be undone, and announce it brightly
# and clearly to all parties that you are in contact with.  Plan to
# change vendors if they don't seem to meet your deadlines.
# Quantum Computing is a serious threat and must not wait
# until every remote fool has gotten the point.
#  
# quantum_proof_authentication = yes
# quantum_proof_encryption = yes
# quantum_proof_handshake = yes

These flags will impact the cipher suites that are acceptable on the TLS Pool that sees them. This may seriously impact the number of successful connections that can be successfully constructed, but the flags allow some degree of pushiness among administrators.

Even without these flags, it is a good idea to place cipher suites that protect against Quantum Computers before those that do not. When they are available, they should be opportunistically selected.

Dynamic Control in Validation Expressions

On top of this, we should probably include flags in the validation expressions, like perhaps:

  • Q and q require the connection to be proofed against Quantum Computing; q refers to authentication and Q refers to encryption of the application level; there is currently no flag to protect the names exchanged during the handshake, but we may expand the definition of Q to that end when it becomes practical in the future.

This option allows administrators to dynamically control quantum proofing for individual trust relations.

@vanrein vanrein added this to the release 1.0 milestone Mar 23, 2019

@vanrein vanrein added the enhancement label Mar 24, 2019

@vanrein vanrein self-assigned this Mar 25, 2019

@vanrein

This comment has been minimized.

Copy link
Contributor Author

vanrein commented Mar 25, 2019

The process describes a four-stage adoptance plan for Quantum Proof TLS. We hope to do this so gradually that users will not want to override it. The danger lies in the remote peers that might not be good netizens. These present a choice to the admin: avoid complaints by individual users visiting such old sites, or avoid the traffic being tapped?

The phases are:

  1. No PQ cipher suites; no default enforcement. This is the status quo, but we already introduce the options to override. You should not enforce PQ choices yet, as they are guaranteed to fail.
  2. PQ cipher suites; no default enforcement. This is a phase during which we are willing to engage in PQ ciphers, and certainly try to, but opportunistically. There should be feedback about when it succeeds, perhaps with percentages and by naming bad sites.
  3. PQ cipher suites; default enforcement. This is when the choices face the administrator. We intend to guide their choices as well as possible using the proper TLS Pool defaults at the right times. The administrator can start this phase earlier than our default.
  4. PQ cipher suites only. The settings can go (and probably will continue to be there, and be ignored).

The whole idea is to gently guide the operator into the PQ realm without taking away their choice.

vanrein added a commit that referenced this issue Mar 25, 2019

issue #85, prepare for Quantum Computing, part 1/1, phase 1
Currently, we have defaults set to disabling requirements for
Post Quantum cipher suites.  One day, the default can migrate.
Administrators already get an opportunity to override, but are
STRONGLY SUGGESTED to never switch it off; however, it is now
possible to experiment with actively switching on support.  In
lieu of cipher suites, this will fail.  So, leave the lines
for Post Quantum cipher suites commented as they are in the
example configuration file.

vanrein added a commit that referenced this issue Mar 25, 2019

issue #85, prepare for Quantum Computing, part 1/2, phase 1
In phase 1, we have defaults set to disabling requirements for
Post Quantum cipher suites.  One day, the default can migrate.
Administrators already get an opportunity to override, but are
STRONGLY SUGGESTED to never switch it off; however, it is now
possible to experiment with actively switching on support.  In
lieu of cipher suites, this will fail.  So, leave the lines
for Post Quantum cipher suites commented as they are in the
example configuration file.

Part 1/2 involves configuration file settings; part 2/2 involves
flags for the validation expression language.

vanrein added a commit that referenced this issue Mar 25, 2019

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.
@vanrein

This comment has been minimized.

Copy link
Contributor Author

vanrein commented Mar 25, 2019

Resolved in 14c9a66 (configuration file options) and 864d65d (validation expression flags).

@vanrein vanrein closed this Mar 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.