commit fc561d2bb586141320306a86f17db9dac6ed0ce8 Author: Isis Lovecruft isis@torproject.org Date: Tue Jan 23 00:51:09 2018 +0000
WIP Migration to TLS 1.3 proposal. --- proposals/xxx-tls-1.3.txt | 336 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 336 insertions(+)
diff --git a/proposals/xxx-tls-1.3.txt b/proposals/xxx-tls-1.3.txt new file mode 100644 index 0000000..e89cf9f --- /dev/null +++ b/proposals/xxx-tls-1.3.txt @@ -0,0 +1,336 @@ +Filename: xxx-tls-1.3.txt +Title: TLS 1.3 Migration +Authors: Isis Lovecruft +Created: 11 December 2017 +Updated: 23 January 2018 +Status: Needs Research + +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/Tls13QuicAtt... + +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... +[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-algor...