Add work-in-progress TLS 1.3 proposal as a draft with number 294.

1 files changed, 340 insertions, 0 deletions

diff --git a/proposals/294-tls-1.3.txt b/proposals/294-tls-1.3.txt
new file mode 100644
index 0000000..c9bae79
--- /dev/null
+++ b/proposals/294-tls-1.3.txt
@@ -0,0 +1,340 @@
+Filename: 294-tls-1.3.txt
+Title: TLS 1.3 Migration
+Authors: Isis Lovecruft
+Created: 11 December 2017
+Updated: 23 January 2018
+Status: Draft
+
+This proposal is currently in draft state and should be periodically
+revised as we research how much of our idiosyncratic older TLS uses
+can be removed.
+
+1. Motivation
+
+   TLS 1.3 is a substantial redesign over previous versions of TLS, with several
+   significant protocol changes which should likely provide Tor implementations
+   with not only greater security but an improved ability to blend into "normal"
+   TLS traffic on the internet, due to its improvements in encrypting more
+   portions of the handshake.
+
+   Tor implementations may utilise the new TLS 1.3 EncryptedExtensions feature
+   to define arbitrary encrypted TLS extensions to encompass our less standard
+   (ab)uses of TLS.  Additionally, several new Elliptic Curve (EC) based
+   signature algorithms, including Ed25519 and Ed448, are included within the
+   base specification including a single specification for EC point compression
+   for each supported curve, further decreasing our reliance on
+   Tor-protocol-specific uses and extensions (and implementation details).
+
+   Other new features which Tor implementations might take advantage of include
+   improved (server-side) stateless session resumption, which might be usable
+   for OPs to resume sessions with their guards, for example after network
+   disconnection or router IP address reassignment.
+
+2. Summary
+
+   Everything that's currently TLS 1.2: make it use TLS 1.3.  KABLAM.  DONE.
+
+   For an excellent summary of differences between TLS 1.2 and TLS 1.3, see
+   [TLS-1.3-DIFFERENCES].
+
+3. Specification
+
+3.1. Link Subprotocol 4
+
+   (We call it "Link v4" here, but reserve whichever is the subsequently
+   available subprotocol version at the time.)
+
+3.2. TLS Session Resumption & Compression
+
+   As before, implementations MUST NOT allow TLS session resumption.  In the
+   event that it might be decided in the future that OR implementations would
+   benefit from 0-RTT, we can re-evaluate this decision and its security
+   considerations in a separate proposal.
+
+   Compression has been removed from TLS in version 1.3, so we no longer need to
+   make recommendations against its usage.
+
+3.3. Handshake Protocol
+
+3.3.1. Negotiation
+
+   The initiator sends the following four sets of options, as defined in §4.1.1
+   of [TLS-1.3-NEGOTIATION]:
+   >
+   >  - A list of cipher suites which indicates the AEAD algorithm/HKDF hash
+   >    pairs which the client supports.
+   >  - A “supported_groups” (Section 4.2.7) extension which indicates the
+   >    (EC)DHE groups which the client supports and a “key_share” (Section 4.2.8)
+   >    extension which contains (EC)DHE shares for some or all of these groups.
+   >  - A “signature_algorithms” (Section 4.2.3) extension which indicates the
+   >    signature algorithms which the client can accept.
+   >  - A “pre_shared_key” (Section 4.2.11) extension which contains a list of
+   >    symmetric key identities known to the client and a “psk_key_exchange_modes”
+   >    (Section 4.2.9) extension which indicates the key exchange modes that may be
+   >    used with PSKs.
+
+   In our case, the initiator MUST leaave the PSK section blank and MUST include
+   the "key_share" extension, and the responder proceeds to select a ECDHE
+   group, including its "key_share" in the response ServerHello.
+
+3.3.2. ClientHello
+
+   To initiate a v4 handshake, the client sends a TLS1.3 ClientHello with the
+   following options:
+
+     - The "legacy_version" field MUST be set to "TLS 1.2 (0x0303)".  TLS 1.3
+       REQUIRES this.  (Actual version negotiation is done via the
+       "supported_versions" extension.  See §5.1 of this proposal for details of
+       the case where a TLS-1.3 capable initiator finds themself talking to a
+       node which does not support TLS 1.3 and/or doesn't support v4.)
+
+     - The "random" field MUST be filled with 32 bytes of securely generated
+       randomness.
+
+     - The "legacy_session_id" MUST be set to a new pseudorandom value each
+       time, regardless of whether the initiator has previously opened either a
+       TLS1.2 or TLS1.3 connection to the other side.
+
+     - The "legacy_compression_methods" MUST be set to a single null byte,
+       indicating no compression is supported.  (This is the only valid setting
+       for this field in TLS1.3, since there is no longer any compression
+       support.)
+
+     - The "cipher_suites" should be set to 
+       "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:"
+       This is the DEFAULT cipher suite list for OpenSSL 1.1.1.  While an
+       argument could be made for customisation to remove the AES-128 option, we
+       choose to attempt to blend in which the majority of other TLS-1.3
+       clients, since this portion of the handshake is unencrypted.
+       (If the initiator actually means to begin a v3 protocol connection, they
+       send these ciphersuites anyway, cf. §5.2 of this proposal.)
+
+     - The "supported_groups" MUST include "X25519" and SHOULD NOT include any
+       of the NIST P-* groups.
+
+     - The "signature_algorithms" MUST include "ed25519 (0x0807)".
+       Implementations MAY advertise support for other signature schemes,
+       including "ed448 (0x0808)", however they MUST NOT advertise support for
+       ECDSA schemes due to the perils of secure implementation.
+
+   The initiator MUST NOT send any "pre_shared_key" or "psk_key_exchange_modes"
+   extensions.
+
+   The details of the "signature_algorithms" choice depends upon the final
+   standardisation of PKIX. [IETF-PKIX]
+
+3.3.2.1. ClientHello Extensions
+
+   From [TLS-1.3_SIGNATURE_ALGOS]:
+   >
+   > The “signature_algorithms_cert” extension was added to allow implementatations
+   > which supported different sets of algorithms for certificates and in TLS itself
+   > to clearly signal their capabilities. TLS 1.2 implementations SHOULD also
+   > process this extension.
+
+   In order to support cross-certification, the initiator's ClientHello MUST
+   include the "signature_algorithms_cert" extension, in order to signal that
+   some certificate chains (one in particular) will include a certificate signed
+   using RSA-PKCSv1-SHA1:
+
+     - The "signature_algorithms_cert" MUST include the legacy algorithm
+       "rsa_pkcs1_sha1(0x0201)".
+
+3.3.3. ServerHello
+
+   To respond to a TLS 1.3 ClientHello which supports the v4 link handshake
+   protocol, the responder sends a ServerHello with the following options:
+
+     - The "legacy_version" field MUST be set to "TLS 1.2 (0x0303)".  TLS 1.3
+       REQUIRES this.  (Actual version negotiation is done via the
+       "supported_versions" extension.  See §5.1 of this proposal for details of
+       the case where a TLS-1.3 capable initiator finds themself talking to a
+       node which does not support TLS 1.3 and/or doesn't support v4.)
+
+     - The "random" field MUST be filled with 32 bytes of securely generated
+       randomness.
+
+     - The "legacy_session_id_echo" field MUST be filled with the contents of
+       the "legacy_session_id" from the initiator's ClientHello.
+
+     - The "cipher_suite" field MUST be set to "TLS13-CHACHA20-POLY1305-SHA256".
+
+     - The "legacy_compression_method" MUST be set to a single null byte,
+       indicating no compression is supported.  (This is the only valid setting
+       for this field in TLS1.3, since there is no longer any compression
+       support.)
+
+   XXX structure and "key_share" response (XXX can we pre-generate a cache of
+   XXX key_shares?)
+
+3.3.3.1 ServerHello Extensions
+
+   XXX what extensions do we need?
+
+4. Implementation Details
+
+4.1. Certificate Chains and Cross-Certifications
+
+   TLS 1.3 specifies that a certificate in a chain SHOULD be directly certified by
+   the preceding certificate in the chain.  This seems to imply that OR
+   implementations SHOULD NOT do the DAG-like construction normally implied by
+   cross-certification between the master Ed25519 identity key and the master
+   RSA-1024 identity key.
+
+   Instead, since certificate chains are expected to be linear, we'll need three
+   certificate chains included in the same handshake:
+
+     1. EdMaster->EdSigning, EdSigning->Link
+     2. EdMaster->RSALegacy
+     3. RSALegacy->EdMaster
+
+   where A->B denotes that the certificate containing B has been signed with key A.
+
+4.2. Removal of AUTHENTICATE, CLIENT_AUTHENTICATE, and CERTS cells
+
+   XXX see prop#224 and RFC5705 and compare
+
+   XXX when can we remove our "renegotiation" handshake completely?
+
+5. Compatibility
+
+5.1. TLS 1.2 version negotiation
+
+   From [TLS-1.3-DIFFERENCES]:
+   >
+   > The “supported_versions” ClientHello extension can be used to
+   > negotiate the version of TLS to use, in preference to the
+   > legacy_version field of the ClientHello.
+
+   If an OR does not receive a ClientHello with a "supported_versions"
+   extenstion, it MUST fallback to using the Tor Link subprotocols v3.  That is,
+   the OR MUST immediately fallback to TLS 1.2 (or v3 with TLS 1.3, cf. the next
+   section) and, following both Tor's "renegotiation" and "in-protocol" version
+   negotiation mechanisms, immediately send a VERSIONS cell.
+
+   Otherwise, upon seeing a "supported_versions" in the ClientHello set to
+   0x0304, the OR should procede with Tor's Link subprotocol 4.
+
+5.2. Preparing Tor's v3 Link Subprotocol for TLS 1.3
+
+   Some changes to the current v3 Link protocol are required, and these MUST
+   be backported, since implementations which are currently compiled against
+   TLS1.3-supporting OpenSSLs fail to establish any connections due to:
+
+     - failing to include any ciphersuite candidates which are TLS1.3 compatible
+
+   This is likely to be accomplished by:
+
+     1. Prefacing our v3 ciphersuite lists with
+        TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:
+        (We could also retroactively change our custom cipher suite list to be
+        the HIGH cipher suites, since this includes all TLS 1.3 suites.)
+     2. Calling SSL_CTX_set1_groups() to set the supported groups (should be set
+        to "X25519:P-256"). [TLS-1.3_SET1_GROUPS]
+     3. Taking care that older OpenSSLs, which instead have the concept of
+        "curves" not groups, should have their equivalent TLS context settings
+        in place.  [TLS-1.3_SET1_GROUPS] mentions that "The curve functions were
+        first added to OpenSSL 1.0.2. The equivalent group functions were first
+        added to OpenSSL 1.1.1".
+
+   However more steps may need to be taken.
+
+   [XXX are there any more steps necessary? —isis]
+
+6. Security Implications
+
+   XXX evaluate the static RSA attack and its effects on TLS1.2/TLS1.3
+   XXX dual-operable protocols and determine if they apply
+   XXX
+   XXX Jager, T., Schwenk, J. and J. Somorovsky, "On the Security
+   XXX of TLS 1.3 and QUIC Against Weaknesses in PKCS#1 v1.5 Encryption",
+   XXX Proceedings of ACM CCS 2015 , 2015.
+   XXX https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf
+
+7. Performance and Scalability
+
+8. Availability and External Deployment
+
+8.1. OpenSSL Availability and Interoperability
+
+   Implementation should be delayed until the stable release of OpenSSL 1.1.1.
+
+   OpenSSL 1.1.1 will be binary and API compatible with OpenSSL 1.1.0, so in
+   preparation we might wish to revise our current usage to OpenSSL 1.1.0 to be
+   prepared.
+
+   From Matt Caswell in [OPENSSL-BLOG-TLS-1.3]:
+   >
+   > OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is
+   > finalised. In the meantime the OpenSSL git master branch contains
+   > our development TLSv1.3 code which can be used for testing purposes
+   > (i.e. it is not for production use). You can check which draft
+   > TLSv1.3 version is implemented in any particular OpenSSL checkout
+   > by examining the value of the TLS1_3_VERSION_DRAFT_TXT macro in the
+   > tls1.h header file. This macro will be removed when the final
+   > version of the standard is released.
+   >
+   > In order to compile OpenSSL with TLSv1.3 support you must use the
+   > “enable-tls1_3” option to “config” or “Configure”.
+   >
+   > Currently OpenSSL has implemented the “draft-20” version of
+   > TLSv1.3. Many other libraries are still using older draft versions in
+   > their implementations. Notably many popular browsers are using
+   > “draft-18”. This is a common source of interoperability
+   > problems. Interoperability of the draft-18 version has been tested
+   > with BoringSSL, NSS and picotls.
+   >
+   > Within the OpenSSL git source code repository there are two branches:
+   > “tls1.3-draft-18” and “tls1.3-draft-19”, which implement the older
+   > TLSv1.3 draft versions. In order to test interoperability with other
+   > TLSv1.3 implementations you may need to use one of those
+   > branches. Note that those branches are considered temporary and are
+   > likely to be removed in the future when they are no longer needed.
+
+   At the time of its release, we may wish to test interoperability with other
+   implementation(s).
+
+9. Future Directions
+
+   The implementation of this proposal would greatly ease the
+   implementation difficulty and maintenance requirements for some
+   other possible future beneficial areas of work.
+
+9.1. TLS Handshake Composability
+
+   Handshake composition (i.e. hybrid handshakes) in TLS 1.3 is incredibly
+   straightforward.
+
+   For example, provided we had a Supersingular Isogeny Diffie-Hellman (SIDH)
+   based implementation with a sane API, composition of Elliptic Curve
+   Diffie-Hellman (ECDH) and SIDH handshakes would be a trivial codebase
+   addition (~10-20 lines of code, for others who have implemented this).
+
+   Our current circuit-layer protocol safeguards the majority of our security
+   and anonymity guarantees, while our TLS layer has historically been either a
+   stop-gap and/or an attempted (albeit usually not-so-successful) obfuscation
+   mechanism.  However, our TLS usage has, in many cases, successfully, through
+   combination with the circuit layer cryptography, prevented more then a few
+   otherwise horrendous bugs.  After our circuit-layer protocol is upgraded to a
+   hybrid post-quantum secure protocol (prop#269 and prop#XXX), and in order to
+   ensure that our TLS layer continues to act in this manner as a stop gap —
+   including within threat models which include adversaries capable of recording
+   traffic now and decrypting with a potential quantum computer in the future —
+   our TLS layer should also provide safety against such a quantum-capable
+   adversary.
+
+
+A. References
+
+[TLS-1.3-DIFFERENCES]:
+   https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.1.3
+[OPENSSL-BLOG-TLS-1.3]:
+   https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
+[TLS-1.3-NEGOTIATION]:
+   https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.4.1.1
+[IETF-PKIX]:
+   https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
+[TLS-1.3_SET1_GROUPS]:
+   https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set1_groups.html
+[TLS-1.3_SIGNATURE_ALGOS]:
+   https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#signature-algorithms