Investigating the Multi-Ciphersuite and Backwards-Compatibility Security of the Upcoming TLS 1.3

This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2017.2685382, IEEE Transactions on Dependable and Secure Computing

IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING 1 Investigating the Multi-Ciphersuite and Backwards-Compatibility Security of the Upcoming TLS 1.3

Xiao Lan, Jing Xu, Zhen-Feng Zhang, and Wen-Tao Zhu, Senior Member, IEEE

Abstract—Transport Layer Security (TLS) is one of the most widely used Internet protocols for secure communications. TLS 1.3, the next-generation protocol, is currently under development, with the latest candidate being draft-18. For flexibility and compatibility, TLS supports various ciphersuites and offers configurable selection of multiple protocol versions, which unfortunately opens the door to practical attacks. For example, although TLS 1.3 is now proven secure separately, coexisting with previous versions may be subject to backwards compatibility attacks. In this paper, we present a formal treatment of the multi-ciphersuite and backwards-compatibility security of TLS 1.3 (specifically, draft-18). We introduce a multi-stage security model, covering all known kinds of compositional interactions (w.r.t. ciphersuites and protocol versions) and reasonably strong security notions. Then we dissect the cross-ciphersuite attack regarding TLS 1.2 in our model, and show that the TLS 1.3 handshake protocol satisfies the multi-ciphersuite security, highlighting the strict necessity of including more information in the signature. Furthermore, we demonstrate how the backwards compatibility attack by Jager et al. can be identified owing to our model, and prove that the handshake protocol can achieve our desired strong security if certain countermeasures are adopted. Our treatment is also applicable to analyzing other protocols.

Index Terms—Transport Layer Security, key reuse, security model, multi-ciphersuite security, backwards-compatibility security. !

1 INTRODUCTION

RANSPORT Layer Security (TLS) [1], as the descendant T of Secure Sockets Layer (SSL), is a cornerstone of In- ternet security and the basis of other protocols like HTTPS. TLS has been generally recognized as one of the Internet’s most widely deployed cryptographic protocols to protect the data transmitted between two communicating peers. For example, Fig. 1 shows the secured connection between a client and a server, where TLS uses a handshake to establish cipher settings as well as a shared key and then the communication is encrypted using that key. Since TLS has been pervasively used to provide end-to- end confidentiality, integrity, and authentication for communications over insecure networks, the security of TLS [2] Fig. 1. TLS containing the handshake and the record protocols is primarily used with TCP to secure communications between a client and a server. has been analyzed extensively by the research community, with TLS and its implementations being the target of a plethora of cryptographic attacks [3]–[13]. An interesting an analysis-before-deployment design paradigm has been and intuitive (yet possibly slightly informal and outdated) effected. Since Apr. 2014, the TLS Working Group of the introduction to the security of TLS can be found in [14]. Internet Engineering Task Force (IETF) has been working So far, the various flaws identified in TLS 1.2 [3]–[5], [8], on TLS 1.3, and at the time of writing (as of Feb. 2017) the [10], [13] have necessitated an open standardization process current candidate is draft-ietf-tls-tls13-18 [15], or draft-18 for of the next-generation protocol, i.e., TLS 1.3, for which short. TLS consists of two primary components, the handshake • X. Lan is with State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences, Beijing 100093, protocol (for authentication and key agreement) and the China, and also with the University of Chinese Academy of Sciences, record protocol (for traffic protection only); in this paper, we Beijing 100049, China. E-mail:[email protected]. focus on the former (specifically, the handshake protocol • J. Xu and Z.-F. Zhang are with Trusted Computing and Information specified in draft-18), as it is relatively more complicated Assurance Laboratory, Institute of Software, Chinese Academy of Sciences, Beijing 100190, China. E-mails:{xujing, zfzhang}@tca.iscas.ac.cn. and thus more subtle when security is concerned: • W.-T. Zhu is with Data Assurance and Communication Security Research Center (and also State Key Laboratory of Information Security, Institute of • For the sake of flexibility, TLS supports various Information Engineering), Chinese Academy of Sciences, Beijing 100093, combinations of cryptographic algorithms officially China. E-mail:[email protected]. known as ciphersuites. Currently, TLS 1.2 has more Manuscript received Dec. 7, 2016. than 300 ciphersuites registered at the Internet As-

1545-5971 (c) 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for more information. This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI 10.1109/TDSC.2017.2685382, IEEE Transactions on Dependable and Secure Computing

2 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

signed Numbers Authority (IANA) [16], e.g., TL- security, and accordingly analyze the “actual” security of the S ECDH RSA WITH AES 128 CBC SHA256 indi- TLS protocol in a systematic and pragmatic manner. Our cates the combination of the ECDH handshake, the approach is in sharp contrast to prior research efforts on RSA digital signature, the AES-128 encryption in the provable security of TLS, which either only considers a CBC mode, the SHA256-based PRF, and the SHA256- “fixed” protocol mode at a time or considers multiple modes based MAC algorithms. with “independent” cryptographic parameter settings. We • Likewise, TLS provides a built-in mechanism for envision that our security treatment concerning the key version negotiation between communicating peers reuse across ciphersuites and versions of the TLS protocol, potentially supporting different versions of TLS. For as well as the insights gained from this study, can offer example, according to an up-to-date survey [17], as constructive inputs to making the next-generation TLS (and of Feb. 2017, TLS 1.2, 1.1, and 1.0 are supported protocols alike) more dependable. by 84.2%, 81.5%, and 95.2% of the most popular web sites (according to alexa.com’s statistics), respec- 1.2 Related Work tively. TLS takes compatibility into consideration by offering a configurable selection of multiple protocol Studies on the security of cryptographic protocols (and versions. particularly on TLS) are extensive. Next, we review those closely related to our work from three aspects. Key reuse. Theoretically, the security proof of a cryp- 1.1 Motivation: The Key Reuse Problem tographic scheme is based on the ideal assumption that To simplify digital certificate management, in practice a the scheme employs randomly chosen keys that are not server (also a client, but not the focus of this paper) often employed elsewhere. In practice, especially in the context of uses the same long-term public/private key pair across public key protocols, however, simultaneously using a key multiple protocol ciphersuites and versions, which is known across different primitives is “operationally” attractive due as key reuse. This seems beneficial as it reduces the server’s to reduced costs (e.g., in certificate application, storage, and certificate storage (and also its clients’ certificate verifica- verification). Key reuse generally exists in the real world. tions). However, key reuse may open the door to security Haber and Pinkas [22] initiated the formal security study breaches, which we regard as the price for the flexibility on key reuse. They defined the joint security of combined and compatibility mentioned above. For example, the well- public key schemes, and analyzed the combinations of known key reuse attack across ciphersuites on TLS 1.2 was a public key encryption scheme and a signature scheme identified in [4], exploiting the interaction between two w.r.t. key reuse. Later, Coron et al. [23] showed that PSS different key exchange protocols (DH and ECDH). Specifi- (Probabilistic Signature Scheme) enables one to safely use cally, signed elliptic curve ephemeral DH parameters may the same RSA key pair for both encryption and signature. be interpreted as valid signed finite field ephemeral DH Komano and Ohta [24] proposed new ES (Encryption & parameters, which allows an adversary to impersonate a Signature) schemes based on OAEP (Optimal Asymmetric server after collecting 240 signed elliptic curve keys. Encryption Padding) and REACT (Rapid Enhanced-security For another example, although users may have the best Asymmetric Cryptosystem Transform). Paterson et al. [25] intentions to use only the most up-to-date, vulnerability- revisited the topic of joint security and proposed a general free version of TLS, the mere support for previous versions construction of a combined public key scheme using IBE as may have serious ramifications such as the key reuse attack a component in the standard model. Degabriele et al. [26] across versions, a.k.a. the backwards compatibility attack [18]. showed the joint security of elliptic curve based signature In 2015, Jager et al. [19] presented an RSA padding oracle and encryption algorithm in the EMV (Europay-Mastercard- attack [20] against TLS 1.3 draft-07 (though TLS 1.3 does not Visa) standard. Recently, Bergsma et al. [27] showed that really support RSA key exchange); specifically, in a setting the SSH (Secure Shell) protocol is secure even if the same where the server uses the same RSA certificate for TLS 1.3 signing key is used across multiple ciphersuites. and a previous version, an adversary can impersonate a In parallel with the above positive results are (inevitably) server by using a vulnerable TLS-RSA server implemen- the negative research findings. As mentioned in Section tation as a “signing oracle” to compute valid signatures 1.1, key reuse has incurred vexing and recurring problems, for messages chosen by him. Moreover, such an attack can particularly for real-world protocols like TLS [4], [19], [21]. be applied to the Quick UDP Internet Connections (QUIC) In [26], Degabriele et al. also presented a theoretical attack protocol, too. Very recently, by exploiting the protocol flaws on RSA-based combined algorithms in EMV, showing how in SSLv2, a practical cross-version key reuse attack was adversarial access to a partial decryption oracle can be used demonstrated in [21], which decrypts modern TLS connec- to forge signatures on freely chosen messages. tions and also affects the QUIC protocol. As many as 11.5 Provable security of TLS 1.2. Although TLS 1.2 [1] was million (33%) HTTPS servers were vulnerable to this attack. standardized in 2008, the progress on formally modeling We make the observation that the above attacks follow a the security of the TLS handshake protocol has been slow. common scenario that messages signed or decrypted using The main reason is that in TLS 1.2 the encryption of the long-term keys in one ciphersuite could be misused in other final Finished messages in the TLS Handshake Layer leads ciphersuites or older protocols, and that such attacks have to a subtle interleaving of the data encryption in the TLS been insufficiently captured in existent security models. Record Layer, which violates the basic principle of key This motivates us to formally revisit the security notions indistinguishability in classical security models such as the called multi-ciphersuite security and backwards-compatibility Bellare-Rogaway one [28].

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 3

In 2012, Jager et al. [29] put forth a new notion called sufficiently rich model for the TLS 1.3 handshake protocol, ACCE (Authenticated and Confidential Channel Establish- covering all kinds of compositional interactions of different ment) to precisely capture the security properties expected ciphersuites and protocol versions, and providing reason- from TLS in practice, and presented the first complete ably strong security guarantees. Our model is built on the cryptographic security proof for TLS-DHE in the standard definition of multi-stage key exchange protocols [35], [36], model. Subsequently, other TLS handshake modes were as it is liberal enough to capture the TLS 1.3 handshake mostly shown secure based on the ACCE model. For ex- protocol. In order to cover various ciphersuites and protocol ample, Krawczyk et al. [30] proved the security of TLS-RSA versions, we introduce two Boolean variables δU,{c,d} and with server-only authentication ciphersuite without having δU,{c,d}, which are used to represent whether party U reuses to assume the IND-CCA security for RSA PKCS #1 v1.5. the same long-term keys across ciphersuites and protocol Giesen et al. [31] analyzed the renegotiation security of TLS versions, respectively. in an extended ACCE model, while Li et al. [32] evaluated Our model additionally provides the adversary with a the variants of TLS with pre-shared keys and proved their featured BCAux oracle, by which the adversary can inter- security in another extended ACCE model. act with old versions and obtain the operation results of In 2014, Bhargavan et al. [33] proposed new security the reused long-term private key. Our model also features definitions to analyze TLS 1.2, and reduced the security certain adaptations w.r.t. the oracle queries summarized as of the TLS handshake protocol to agile assumptions on follows. First, to accommodate multi-ciphersuite cases in the constructions used for signatures, key encapsulation the Send query, the adversary’s capability of modifying the mechanisms (KEMs), and PRFs. Recently, Dowling and Ste- ciphersuite list is considered. Second, to capture the key bila [34] presented a formal treatment of the negotiation of reuse attacks in the Corrupt query, when a long-term private ciphersuites and versions in TLS 1.2. However, this work key is corrupted, other sessions (in different ciphersuites or relied on an idealistic assumption that long-term keys are versions) that use the same private key are also considered independent for each sub-protocol, i.e., there is no key reuse corrupted. Third, in the Test query, to exclude trivial attacks across different ciphersuites or versions. and capture admissible adversarial interaction, a flag lost is Provable security of TLS 1.3. The next-generation TLS, introduced. version 1.3, is currently under development [15]. In 2015, Multi-ciphersuite security of the TLS 1.3 handshake Dowling et al. [35] showed that the handshake protocols in protocol. We provide the first proof that TLS 1.3 is multi- two earlier candidates, draft-05 and draft-dh, achieve the ciphersuite secure. In TLS 1.3, since the RSA key transport main goal of providing secure authenticated key exchange algorithm has been deprecated and there does not exist under a modified multi-stage model introduced in [36]. any public key encryption scheme, our multi-ciphersuite Later, they continued in [37] to analyze the TLS 1.3 draft- analysis only addresses the signature schemes. In particular, 10 full and pre-shared key handshake protocols. Recently, via a modular approach, we show that if a single ciphersuite Krawczyk and Wee [38] presented the OPTLS key exchange TLSc with additional access to a signing algorithm is secure protocol, serving as a basis for analyzing the TLS 1.3 hand- in the multi-stage security model, and another ciphersuite shake protocol. Concurrently, Cremers et al. [39] and Li et TLSd sharing long-term keys with TLSc can be simulated al. [40] focused on the compositional security of the TLS using this signing algorithm, then the combination of the handshake protocol from independent points of view. More two ciphersuites TLSc and TLSd is secure even if keys specifically, Cremers et al. gave a comprehensive security are reused, and thus prove the multi-ciphersuite security analysis for the interaction of different handshake modes of TLS 1.3. We also identify the cross-protocol attack by in draft-10 based on symbolic analysis tools, while Li et Mavrogiannopoulos et al. [4] on TLS 1.2 in our security al. presented the formal treatment of multiple handshakes model, which highlights the strict necessity of including security of draft-10 based on computational complexity. In more information in the signature. parallel with their work, Bhargavan et al. [41] studied the Backwards-compatibility security of the TLS 1.3 hand- downgrade resilience as a formal security notion for key shake protocol. We recall the backwards compatibility at- exchange protocols and analyzed the downgrade security tack of Jager et al. [19] against TLS 1.3 draft-07, and explain of draft-10. with our model why draft-07 is vulnerable. Then we check whether the countermeasures against Bleichenbacher’s attack [20] that are recommended in the standards [1], [42], 1.3 Summary of Technical Results [43] are actually acceptable. In fact, Jager’s attack is an TLS is one of the most widely-used cryptographic protocols utilization of Bleichenbacher’s adaptive chosen ciphertext on the Internet. However, it seems that for TLS, flexibility attack against RSA PKCS #1 v1.5 [20]. With the counter- and compatibility are supported at the cost of potentially measures [1], the adversary cannot differentiate the padding introducing key reuse attacks across ciphersuites and pro- error from the decryption error (as the decryption result tocol versions. Most provable security analyses of TLS only is hidden by the uniform error message), and thus can- consider a single ciphersuite/version at a time. In this work, not forge signatures without the secret key, which negates we aim at addressing this situation by systematically inves- the backwards compatibility attacks. Finally, we prove that tigating the multi-ciphersuite and backwards-compatibility the TLS 1.3 draft-18 handshake protocol achieves multi- security of the TLS 1.3 (specifically, draft-18) handshake ciphersuite and backwards-compatibility security if an older protocol. Our technical contributions are threefold. version (such as TLS 1.2) has been upgraded with the Security model for multi-ciphersuite and backwards- countermeasures recommended in the standard [1]. The core compatibility handshake protocols. Our goal is to define a of our proof lies in the security of the signature scheme with

4 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

an auxiliary decryption algorithm BCFunc instantiated by 4 presents our security model for multi-ciphersuite and TLS-RSA in the older TLS version. backwards-compatibility handshake protocols. In Section Our model-based treatment is also applicable to analyz- 5, a multi-ciphersuite security proof of TLS 1.3 draft-18 ing other real-world security protocols. For example, QUIC is given. Section 6 identiﬁes the backwards compatibility is a multi-stage protocol only supporting the RSA signature attack on TLS 1.3 draft-07 [19] with our security model, and and suffers from a cross-protocol attack in the presence of presents a backwards-compatibility security proof of TLS 1.3 a “Bleichenbacher-oracle” provided by a TLS 1.2 server. By with TLS 1.2 (as long as TLS 1.2 adopts the proposed ﬁxes learning from the countermeasures for TLS, one can also in the standard [1]). Finally, Section 7 concludes this paper. eliminate potentially devastating security impacts on QUIC.

2 PRELIMINARIES 1.4 Comparison with Related Work In 2014, Bergsma et al. [27] introduced a generic multi- In this section, we briefly recall some common primitives $ ciphersuite composition framework and showed that the and definitions that our analysis employs, where a ← A Secure Shell (SSH) protocol is multi-ciphersuite secure. denotes the action of independently sampling a uniformly However, their framework was based on the ACCE model, random element from a set A, λ denotes the security param- which treats the key exchange and authenticated encryption eter, and negl(λ) denotes a function negligible in λ. as a single monolithic object and is not suitable for the analysis of TLS 1.3. Moreover, they did not consider key 2.1 Collision-Resistant Hash Function reuse scenarios across versions. Later, based on the multi-ciphersuite setting in [27], A hash function Hash [44] is a deterministic function Dowling and Stebila [34] gave a formal treatment of ci- z = Hash(k, m), taking as inputs a key k ∈ KHash and an phersuite and version negotiation for the TLS protocol w.r.t. arbitrary bit string m, and returning a hash value z in the versions up to 1.2, but their work relied on the assumption hash space {0, 1}l(λ) (with l(λ) polynomial in λ). that each ciphersuite has independent long-term keys. They Definition 1. We say that a keyed hash function Hash(k, m) did not take into consideration key reuse scenarios across is collision resistant, if for all polynomial-time algorithms A, either ciphersuites or versions, though in the real world such it holds that scenarios widely exist. Recently, Bhargavan et al. [41] put forward a methodolo- COLL $ 0 AdvHash = Pr[k ← KHash;(m, m ) ← A(k): gy to analyze the downgrade resilience of real-world key m 6= m0 ∧ Hash(k, m) = Hash(k, m0)] ≤ negl(λ). exchange protocols (TLS, SSH, IPSec, etc). Their work is motivated by the downgrade attacks, where an adversary interferes with the negotiation of ciphersuites or versions 2.2 Pseudo-Random Function between two innocent parties so that they end up with a ciphersuite or version, which is weaker than the one A pseudo-random function (PRF) [45] is a deterministic z = PRF(k, m) k ∈ K they would have chosen and is possibly vulnerable. In this function , taking as inputs a key PRF m z ∈ paper, instead of such downgrade problem, we focus on the and an arbitrary bit string , and returning a string {0, 1}λ key reuse problem, where different ciphersuites or versions . share the same long-term key. Moreover, the downgrade To define security, we consider the following game be- A resilience studied in [41] can be technically understood (and tween an adversary and a challenger. compared with our security notions) on two levels: 1) The challenger samples k uniformly at random. The adversary A may adaptively make oracle queries • On the ciphersuite level, downgrade resilience re- PRF(k, ·) for arbitrary values m and obtain the corre- sembles multi-ciphersuite security. However, the sponding PRF(k, m). mode set based approach in [41] cannot reflect the 2) The adversary A outputs m0 that was never queried subtle interactions between ciphersuites due to the $ to PRF(k, ·). The challenger samples b ← {0, 1} and key reuse, nor the negative impact caused by such returns PRF(k, m0) to A if b = 0, or a random value interactions. Particularly, RSA key reuse is excluded uniformly sampled from the range of the function oth- in [41] (as noted in [41] right before Theorem 7). erwise. • On the protocol version level, downgrade resilience 3) The adversary continues querying to PRF(k, ·), subject- is quite different from our backwards compatibility ed only to the restriction that the submitted bit string is security. In fact, Bhargavan et al. [41] focus on negoti- not identical to m0. ating the highest version supported by both commu- 4) Finally, A outputs a guess b0. If b = b0 the adversary nication peers, while our goal is to ensure that the wins. existence of old versions does not compromise the security of the current version. Definition 2. We say that a PRF is a secure pseudo-random function, if any adversary has an advantage of at most 1.5 Paper Organization negl(λ) to distinguish the PRF from a truly random function, i.e., The rest of this paper is organized as follows. Preliminaries 1 are introduced in Section 2, followed by the TLS 1.3 draft- AdvPRF-sec = |Pr[b = b0] − | ≤ negl(λ). 18 full handshake protocol outlined in Section 3. Section PRF 2

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 5 2.3 The Pseudo-Random Function Oracle Diffie- Client C Server S Hellman Assumption $ l ClientHello: rc ← {0, 1} The pseudo-random function oracle Diffie-Hellman (PRF- +client_key_shares: X ← gx, ... +cipher_suites ODH) assumption was introduced by Jager et al. [29]. Let G −−−−−−−−−−−−−−−−−−−−−−−−−→ $ l be a group of prime order q and g a generator of G. Let PRF ServerHello: rs ← {0, 1} +server_key_share: Y ← gy be a deterministic function z = PRF(X, m), taking as input +cipher_suite ∗ ←−−−−−−−−−−−−−−−−−−−−−−−−− a key X ∈ G and some bit string m ∈ {0, 1} , and returning H1 ← H(CHkSH) a string z ∈ {0, 1}λ. SS← Y x SS← Xy HS← HKDF.Extract(0, SS) We consider the following game between an adversary ctshs ← HKDF.Expand(HS, label1||H1) A and a challenger. stshs ← HKDF.Expand(HS, label2||H1) stage 1 ∗ 1) The adversary A outputs a value m ∈ {0, 1} . {EncryptedExtensions} $ $ λ {CertificateRequest∗} 2) The challenger samples u, v ← q, z1 ← {0, 1} ∗ Z {ServerCertificate }: pkS uv ∗ uniformly at random and sets z0 = PRF(g , m). Then H2 ← H(CHk... kSCRT ) u v {ServerCertificateVerify∗}: it tosses a coin b ∈ {0, 1} and returns zb, g and g to SCV← Sign(skS ,H2) the adversary. SFK← HKDF.Expand(stshs, label3) 0 ∗ ∗ 3) The adversary may query a pair (X, m ) ∈ (G, {0, 1} ) H3 ← H(CHk... kSCV ) u {ServerFinished}: with X 6= g to the challenger. The challenger replies SF ← HMAC(SFK,H3) v 0 ←−−−−−−−−−−−−−−−−−−−−−−−−− with PRF(X , m ). check Verify(pkS ,H2, SCV)=1 0 check SF = HMAC(SFK,H3) 4) Finally, A outputs a guess b . ∗ {ClientCertificate }: pkC ∗ H4 ← H(CHk... kCCRT ) Definition 3. We say that the PRF-ODH problem is hard for ∗ {ClientCertificateVerify }: PRF with keys from G, if for all polynomial-time algorithms CCV← Sign(skC ,H4) CFK← HKDF.Expand(ctshs, label3) A, it holds that ∗ Hsess ← H(CHk... kCCV ) {ClientFinished} PRF-ODH 0 1 : Adv = |Pr[b = b ] − | ≤ negl(λ), CF ← HMAC(CFK,Hsess) PRF,G 2 −−−−−−−−−−−−−−−−−−−−−−−−−→ check Verify(pkC ,H4, CCV)=1 where the probability is over the random coins of A and the check CF = HMAC(CFK,Hsess) u, v MS← HKDF.Extract(HS, 0) random choices of . ctkapp ← HKDF.Expand(MS, label4||Hsess) stkapp ← HKDF.Expand(MS, label5||Hsess) stage 2

2.4 Signature Scheme [NewSessionTicketM]: psk id ←−−−−−−−−−−−−−−−−−−−−−−−− A digital signature scheme SIG = (Sig.Gen, Sig.Sign, RMS ← HKDF.Expand(MS, label6||Hsess) stage 3

Sig.Verify) with message space M(λ) consists of the EMS ← HKDF.Expand(MS, label7||Hsess) stage 4 standard algorithms: key generation Sig.Gen(1λ) → Fig. 2. The full (EC)DHE handshake protocol in TLS 1.3 draft-18. {m} indicates (pk, sk), signing Sig.Sign(sk; m) → σ, and verification a message m encrypted using AEAD with the sender’s handshake traffic secret ctshs or ctshs, and [m] indicates a message m encrypted using AEAD with Sig.Verify(pk; m, σ) → {0, 1}. It is said to be correct if ∗ sender’s application traffic key ctkapp or stkapp. m indicates a message that Sig.Verify(pk; m, Sig.Sign(sk; m)) = 1 for all (pk, sk) ← can be transmitted optionally. mM indicates a message that is only sent when Sig.Gen(1λ) and m ∈ M(λ). later resumption shall be allowed. To define security [46], we consider the following game between an adversary A and a challenger. 1) Setup Phase. The challenger chooses (pk, sk) ← • ClientHello/ServerHello: contains the sup- λ Sig.Gen(1 ). ported versions and ciphersuites for negotiation pur- 2) Signing Phase. The adversary A sends signature query poses, nonce rc (resp. rs) with bit length l = 256, as mi ∈ M and receives σi = Sig.Sign(sk; mi). well as extensions (e.g., supported groups, signature 3) Forgery Phase. A outputs a message m and its signature algorithms, and key share). In TLS 1.3, the supported σ. If m is not queried during the Signing Phase and group is either an elliptic curve group (e.g., secp256r Sig.Verify(pk; m, σ) = 1, the adversary wins. and secp384r1), or a finite field group (e.g., ffdhe2048 Definition 4. We say that a signature scheme SIG is existen- and ffdhe3072); the supported signature algorithm is tially unforgeable under adaptive chosen-message attacks (EUF- either RSASSA-PKCS1-v1 5, RSASSA-PSS, ECDSA, CMA), if for all adversaries A, there exists a negligible or EdDSA. • cipher_suites cipher_suite function negl(λ) such that / : contains a list of cryptographic options supported by the clien- EUF-CMA AdvSig = Pr[A wins] ≤ negl(λ). t (resp. a single ciphersuite selected by the server from the list). These messages are included in the ClientHello/ServerHello messages. Be- 3 THE TLS 1.3 DRAFT-18 FULL HANDSHAKE sides, the ciphersuite contains the hash algorithm PROTOCOL used with HKDF, either SHA256 or SHA384. In this section we describe the TLS 1.3 draft-18 full hand- • client_key_shares/server_key_share: con- shake protocol. Fig. 2 shows the message flow and relevant tains a list of ephemeral Diffie-Hellman public cryptographic computations for the full handshake in draft- values X = gx (resp. a single Y = gy) for 18, where the messages are explained below: the groups (resp. a single group) selected by

6 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

ClientHello/ServerHello, used to compute the for the Test query, since trivial attacks need to be exclud- shared secret SS. These messages are included in the ed, a flag lost should be added to the security model to Hello Extensions field. capture admissible adversarial interaction. Besides, in or- • EncryptedExtensions: contains more extensions, der to obtain comprehensive security guarantees for multi- this is the first message that is encrypted with stshs. ciphersuite and backwards-compatibility handshake proto- • CertificateRequest: indicates the server re- cols, we additionally give the adversary access to a BCAux quests for client authentication using a certificate. query. Finally, two Boolean variables δU,{c,d} and δU,{c,d} • ServerCertificate/ClientCertificate: con- are introduced to describe the case of long-term keys reuse tains the public key certificate of the respective party. across ciphersuites and versions, respectively. • ServerCertificateVerify/ClientCertific- For the analysis of TLS 1.3, some adaptations of the ateVerify: contains a digital signature over the security model are necessary and beneficial. In TLS 1.3 entire handshake hash. draft-18, the NewSessionTicket message used for session • ServerFinished/ClientFinished: contains the resumption is encrypted with the handshake’s application HMAC evaluated on the entire handshake messages traffic key, which provides a “check value” allowing the till this calculation with the server finished key SFK adversary to test whether a given key is “real” or “random”, or the client finished key CFK, respectively. and makes it impossible to prove the security of TLS in • NewSessionTicket: creates a pre-shared key (PSK) any key indistinguishability based security model. In order binding between the resumption master secret RMS to exclude such issues, in our model, the adversary is and the ticket label. prompted to decide whether this session should be tested or not when a session key is established. If tested, the In brief, the TLS 1.3 full handshake protocol provides session key is set to be either real or random, and then the a method for participants with multiple configurations to a- protocol continues with this specific value in the rest of the gree on a uniform ciphersuite and establish a common secret execution, which ensures the consistency of the session key session key. In order to provide better protection for secure and bypasses the problem of being a “check value”. communications, the session messages are encrypted using the symmetric encryption scheme AEAD (authenticated encryption with associate data) with different keys. All the 4.2 Notation messages in ‘{}’ are encrypted with the sender’s handshake We denote a set of parties as U, and each party U ∈ U is traffic secret ctshs or stshs derived from the handshake secret HS, and all the messages in ‘[]’ are encrypted with a (potential) protocol participant in the system. Following [27], we also use the variable δU,{ , } to indicate whether the sender’s application traffic key ctkapp or stkapp derived c d SP from the master secret MS. the party U reuses the same long-term keys for c and SPd, where SPc, SPd ∈ SP~ . Besides, in order to capture the key reuse attacks across multiple versions, the variable 4 MULTI-CIPHERSUITEAND BACKWARDS- δU,{c,d} is introduced to represent whether party U reuses COMPATIBILITY SECURITYOFTHE HANDSHAKE the same long-term keys for SPc in the current version (TLS PROTOCOL 1.3 draft-18) and SPd in an old version (such as TLS 1.2), SP ∈ SP~ U In this section, we revisit the notions of multi-ciphersuite where only c . Each party is associated with a sk pk and backwards-compatibility security along the lines of the long-term private/public key pair ( U,c, U,c) for each SP sk pk seminal paper of Bellare and Rogaway [28]. Our formal ciphersuite c in the current version, and ( U,c, U,c) SP δ security model is inspired by the notation used by Dowling for each ciphersuite c in an old version. Hence, U,{c,d} et al. [35] and Bergsma et al. [27]. = 1 iff (skU,d, pkU,d) = (skU,c, pkU,c), and δU,{c,d} = 1 iff (skU,d, pkU,d) = (skU,c, pkU,c). Note that δU,{c,d} (δU,{c,d}) is symmetric in c and d. 4.1 Overview In our formulation, a session is an execution of the In the multi-ciphersuite setting, we need to consider many protocol, and each party can concurrently or subsequently different ciphersuites with different algorithms, so we ac- execute multiple sessions of the protocol. A party’s long- NP SP~ quire a multi-ciphersuite handshake protocol || by term keys are shared by each session of this party, which NP first running a negotiation protocol , which outputs a is uniquely identified using a label label ∈ LABELS = ciphersuite choice c (where c ∈ {1, . . . , nSP} and nSP = U × U × N. The k-th local session owned by identity U with SP~ SP SP~ | |), and then running a sub-protocol c ∈ , where the intended communication partner V can be presented SP~ represents different ciphersuites. In addition, our setting with session label (U, V , k). Besides, parties can establish supports multiple protocol versions and allows key reuse multiple keys in different stages of a session, and the key across versions. of some stage can be used to derive the next stage key. We Different from the basic setting, owing to the fact that also maintain a session list ListS to record each session. One an execution includes multiple ciphersuites and protocol record contains the following entries, and the values in ‘[ ]’ versions, our model allows more complex and more com- indicate the default/initial values: prehensive replies to the oracle queries. In particular, for the Send query, the adversary’s capability of modifying • label ∈ LABELS: the session label. the ciphersuite list should be considered; for the Corrupt • U ∈ U: the session owner. query, in order to capture the key reuse attacks, the queried • V ∈ (U ∪ {∗}): the intended communication partner, party’s specific ciphersuite identifier should be considered; where the symbol ‘*’ stands for “unknown identity”.

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 7

• role ∈ {initiator, responder}: the session owner’s role m = init (without any input message and with an ordered in this session. ciphersuite list cs~ as the response). • c ∈ {1, . . . , nSP, ⊥}: the identifier of the negotiated If the execution state changes to acceptedi for some ciphersuite. stage i during the protocol execution, the protocol execution • stexec ∈ (RUNNING ∪ ACCEPTED ∪ REJECTED): is immediately suspended and acceptedi is returned to the state of execution [running0], where RUN- the adversary. Later, the adversary can trigger the protocol NING={runningi |i ∈ N}, ACCEPTED={acceptedi resumption by a special Send(label, continue) query. This |i ∈ N}, REJECTED={rejectedi |i ∈ N}. gives the adversary the ability to test a session key before • stage∈ {0,..., M}: the current stage [0], where M is it may be used in later stages and thus cannot be tested the maximum stage and stage is incremented to i anymore for excluding trivial attacks. when stexec reaches acceptedi (resp. rejectedi). Besides, in order to exclude trivial attacks, we need to • auth ∈ AUTH ⊆ {unauth, unilateral, mutual}M: the consider the following subcases when the execution state authentication type of each stage from the supported label.stexec changes to acceptedi for some stage i. 0 0 0 0 authentication type set AUTH, where M is the maxi- Case 1: There is a record (label , V , U, role , c , stexec, 0 0 0 0 0 0 0 mum stage and authi denotes the authentication type stage , auth , sid , cid , K , stkey, tested ) in ListS with 0 0 0 0 in stage i >0. label.sidi = label .sidi and label .stkey = revealed. Then for ∗ M M • sid ∈ ({0, 1} ∪ {⊥} ): the session identifier [(⊥) ], the key independence, label.stkey,i is set to revealed, which which is determined by the incoming and outgoing means the session keys of partnered sessions should be messages for the session, where sidi denotes the considered revealed, whereas for the key dependence, all 0 session identifier in stage i >0. label.stkey,i0 (i ≥ i) are set to revealed, which means all ∗ • cid ∈ ({0, 1} ∪ {⊥}M): the contributive identifier subsequent keys are potentially available for the adversary. M 0 0 0 0 [(⊥) ], where cidi denotes the contributive identifier Case 2: There is a record (label , V , U, role , c , stexec, 0 0 0 0 0 0 0 in stage i >0. stage , auth , sid , cid , K , stkey, tested ) in ListS with ∗ M 0 0 0 0 • K ∈ ({0, 1} ∪ {⊥} ): the established session key label.sidi = label .sidi and label .testedi = true. Then we set M 0 0 [(⊥) ], where Ki denotes the established session key label.Ki = label .Ki and label.testedi = true. in stage i >0. Case 3: The intended communication partner V of the M • stkey ∈ {fresh, revealed} : the state of the session session with label is corrupted. Then we set label.stkey,i = M key [(fresh) ], where stkey,i denotes the state of the revealed. session key in stage i >0. -Reveal (label, i): Provides label.Ki, the i-stage session • tested ∈ {true, false}M: the test indicator [(false)M], key of the session label to the adversary. where testedi = true denotes that Ki has been tested. If there is no record label in ListS, or i > label.stage, or label.tested = true, then return ⊥. Otherwise, set label.st As usual, if we add a partially specified record (label, U, V , i key,i to revealed and provide the adversary with label.Ki. role, c, auth) to ListS, then the other record entries are set to If there is a record label0 in List with label.sid = their default values. Besides, in order to identify sessions of S i label0.sid0 and label0.stage0 ≥ i, then label0.st0 is set to honest parties, which are currently not partnered according i key revealed as well. to the (full) session identifiers but indicate the key being For the key dependence, since all subsequent keys in the entirely based on an honest peer’s contribution, we also same session label depend on the revealed key, label.st adopt the notion of contributive identifiers as in [35]. key,j is set to revealed for all j > i if label.stkey,i = revealed. For 0 0 0 the same reason, if a partnered session label with label .sidi 4.3 Adversarial Interaction 0 0 0 0 = label.sidi has label .stage = i, then label .st key,j is set to We consider a probabilistic polynomial-time adversary A revealed for all j > i. However, note that if label0.stage0 0 0 who controls the communications between all parties, with > i, then label .st key,j (j > i) is not considered revealed by the ability of interception, injection, and dropping messages. this query since it has been accepted previously, i.e., prior to Moreover, following [36] we also distinguish different levels label.Ki being revealed in this query. of the following three independent security aspects of a -Corrupt (U, c): Provides skU,c, the party U’s long-term handshake protocol: forward secrecy, authentication, and private key for the ciphersuite SPc to the adversary. If for- key dependence. The adversary A interacts with the pro- ward secrecy is not provided, label.stkey,i is set to revealed tocol via the following oracle queries: for each session label owned by U with the negotiated SPc, -NewSession (U, V , role, auth): Creates a new session for where i ∈ {1,..., M}. Besides, if there exists d satisfying 0 participant U with the role role having V as the intended δU,{c,d} = 1 (δU,{c,d} = 1 ), label .stkey,i is set to revealed partner (V = ∗ if not specified explicitly), aiming at the for each session label0 owned by U with the negotiated authentication type auth. Generate and return a unique new ciphersuite SPd (SPd). In the case of stage-j forward se- 1 label and add (label, U, V , role, auth) to ListS. crecy , label.stkey,i is set to revealed only if i < j or if i -Send (label, m): Sends a message m to the session with > label.stage, which means that the session keys before label. Check whether there is a record (label, U, V , role, c, the j-th stage as well as the keys that have not yet been stexec, stage, auth, sid, cid, K, stkey, tested) in ListS, if not, established are potentially disclosed. return ⊥. Otherwise, take the message m as input to run the protocol on behalf of U, return the response and the updated 1. As defined in [36], in stage-j-forward-secure protocols, stage-j forward secrecy means that session key Ki established at some stage i execution state label.stexec. As a special case, the adversary ≥ j remains secure when the involved long-term private key exposed, is allowed to initiate a session if label.role = initiator and whereas keys at stages i < j become insecure.

8 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

-BCAux(U, c, m): Provides a private key operation result 5) Sessions are partnered with the intended (authenticat- on the message m to the adversary. If there exists d satisfying ed) participants; δU,{c,d}=1, return the operation result using U’s long-term 6) Session identifiers do not match across different stages; private key of ciphersuite SPd in an old version. Otherwise, 7) At most two sessions have the same session identifier return ⊥. This query will trigger the execution of specific at any stage. function BCFunc and model adversary’s handling of key reuse across versions. In detailed analysis, BCFunc repre- Definition 5. (Match Security) Let NP||SP~ be a multi- sents specific signing algorithm or decryption algorithm. ciphersuite handshake protocol, and A be a probabilistic -Test (label, i): Provides the real session key of stage i in polynomial-time adversary interacting with NP||SP~ via the the session with label or a random value according to the queries defined in Section 4.3 in the following MCS game GMatch test bit btest. MCS,A:

If there is no record label in ListS or if label.stexec 6= Setup. The key reuse variables δU,{c,d} and δU,{c,d} are 0 acceptedi, return ⊥. If there is a record label in ListS with set for any U ∈ U. Then the challenger generates a long- label0 sid0 label sid label0 st0 6= accepted ~ ~ . i = . i and . exec i, the flag term private/public key pair (skU , pkU ) for each participant lost is set to true. This indicates that we only allow the U according to δU,{c,d} and δU,{c,d}. adversary to test the sessions which have been accepted but Query. The adversary A receives the generated public not used yet. In addition, if there exist partnered sessions of keys and interacts with the challenger through the queries the test sessions, they should be in the same status (accepted NewSession, Send, Reveal, and Corrupt. but not used yet). If either label.role = responder (with label.authi = Stop. At some point, the adversary stops with no output. unauth or unilateral) or label.role = initiator (with la- We say that A wins the MCS game, denoted by bel auth = unauth label0 List Match . i ), but there is no record in S GMCS,A = 1, if at least one of the following conditions holds: 0 0 with label .cid = label.cidi, the flag lost is set to true. This i 0 means that a prerequisite for testing a responder session 1) There exist distinct label and label such that label.sidi 0 (unauthenticated or unilaterally authenticated) or for testing = label .sidi 6= ⊥ for some stage i ∈ {1,..., M}, 0 an initiator session (unauthenticated) is that the responder label.stexec 6= rejectedi and label .stexec 6= rejectedi, but 0 / initiator session has an honest contributive partner. label.c 6= label .c. (The partnered sessions have different If label.testedi = true, return label.Ki, which ensures the ciphersuite indexes in some stage.) 0 consistency for repeated queries. Otherwise, set label.testedi 2) There exist distinct label and label such that label.sidi 0 to true and return the session key label.Ki (if btest = 1) = label .sidi 6= ⊥ for some stage i ∈ {1,..., M}, 0 $ label.stexec 6= rejectedi and label .stexec 6= rejectedi, or label.Ki ← D from the session key distribution D (if 0 0 but label.Ki 6= label .Ki. (The partnered sessions have btest = 0). Moreover, if there is a record label in ListS with 0 0 different session keys in some stage.) label .sidi = label.sidi and label’.stexec = acceptedi, also set 0 0 0 0 0 3) There exist distinct label and label such that label.sidi label .Ki = label.Ki and label .testedi = true, which ensures 0 = label .sidi 6= ⊥ for some stage i ∈ {1,..., M}, but the consistency for partnered sessions. 0 label.authi 6= label .authi. (The partnered sessions have different authentication types in some stage.) 4.4 Security Definitions 0 4) There exist distinct label and label such that label.sidi 0 The basic security of a handshake protocol is defined by = label .sidi 6= ⊥ for some stage i ∈ {1,..., M}, but 0 0 requiring that (i) the protocol be match secure, ensuring label.cidi 6= label .cidi or label.cidi = label .cidi = ⊥. (The the session identifiers sid effectively match the partnered partnered sessions have different or unset contributive sessions, and (ii) the protocol provides key secrecy, ensur- identifiers in some stage.) 0 ing that the adversary cannot distinguish a fresh session 5) There exist distinct label and label such that label.sidi 0 key from a random element in the same distribution. The = label .sidi 6= ⊥ for some stage i ∈ {1,..., M}, la- 0 “advanced” security of a handshake protocol needs some bel.authi = label .authi ∈ {unilateral, mutual}, label.role additional requirements: the multi-ciphersuite security, pro- = initiator, and label0.role = responder, but label.V 6= 0 0 viding the basic security even in the case of key reuse label .U or label.U 6= label .V (only when label.authi = across different ciphersuites, and the backwards-compatibility mutual). (The partnered sessions have different intend- security, providing the basic security even in the case of key ed authenticated partners.) reuse across multiple versions. 6) There exist (not necessarily distinct) label and label0 0 such that label.sidi = label .sidj 6= ⊥ for distinct 4.4.1 Match Security i, j ∈ {1,..., M}. (The same session identifier is shared The following conditions should be all satisfied: by different stages.) 0 00 1) Sessions with the same session identifier for some stage 7) There exist distinct label, label , and label such that 0 00 agree on the same ciphersuite; label.sidi = label .sidi = label .sidi 6= ⊥ for some stage 2) Sessions with the same session identifier for some stage i ∈ {1,..., M}. (The same session identifier is shared share the same session key at that stage; by three or more sessions.) 3) Sessions with the same session identifier for some stage We say a multi-ciphersuite handshake protocol is match agree on the authentication level at that stage; secure, if for all probabilistic polynomial-time adversaries 4) Sessions with the same session identifier for some stage A the advantage Advmcs-match = Pr [GMatch = 1] is negl(λ). share the same contributive identifier at that stage; NP||SP~ ,A MCS,A

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 9

4.4.2 Key Secrecy proposed by Mavrogiannopoulos et al. [4] can be captured Definition 6. (Key Secrecy) Let NP||SP~ be a multi- in the security model of Section 4. In particular, with prob- −40 ciphersuite handshake protocol with key distribution D ability around 2 , a ServerKeyExchange message from a and authenticity properties AUTH, and A be a probabilistic signed-ECDH ciphersuite can be utilized by an adversary to polynomial-time adversary interacting with NP||SP~ via the impersonate the server using a finite field DH ciphersuite queries defined in Section 4.3 in the following MCS game and cause a client to accept, and thus the match security Secrecy,D of the protocol is broken. Fortunately, in TLS 1.3 drafts, all G ,A : MCS handshake messages up to when the signature is calculated, Setup. The key reuse variables δU,{ , } and δU,{ , } are c d c d including the negotiated ciphersuite, are used for an honest set for any U ∈ U. Then the challenger generates a long-term ~ ~ participant to generate the signature. Intuitively, by such private/public key pair (skU , pkU ) for each participant U $ binding, only the negotiated ciphersuite can be accepted, according to δU,{c,d} and δU,{c,d}, chooses the test bit btest ← and thus the cross-protocol attack is avoided, which high- {0, 1}, and sets the flag lost = false. lights the strict necessity of including more information (i.e., Query. The adversary A receives the generated public the ciphersuite list provided by the client) in the protocol’s keys and interacts with the challenger through the queries signature contents. In this section, we prove that TLS 1.3 NewSession, Send, Reveal, Corrupt, and Test. Note that draft-18 is secure even if the same signing key is used across such queries may set the flag lost to true. multiple ciphersuites. Guess. At some point, A stops and outputs a guess b. First, we define the session identifiers and the contribu- Finalize. The challenger sets the flag lost to true if tive identifiers for the stages as specified in TLS 1.3 draft-18 there exist (not necessarily distinct) label and label0 such 0 to be the unencrypted messages sent and received excluding that label.sidi = label .sidi, label.stkey,i = revealed, and 0 the Finished messages: label .testedi = true for some stage i ∈ {1,..., M}. We say that A wins the MCS game, denoted by sid1 = (ClientHello, client_key_shares, Secrecy,D cipher_suites, ServerHello, server_key_share, GMCS,A = 1, if b = btest and lost = false. A multi- ciphersuite handshake protocol provides key secrecy, if for cipher_suite), all probabilistic polynomial-time adversaries A the advan- sid2 = (sid1, EncryptedExtensions, mcs-secrecy,D Secrecy,D 1 CertificateRequest∗ ServerCertificate∗ tage AdvNP||SP~ ,A = |Pr [GMCS,A = 1] − 2 | is negl(λ). , , ServerCertificateVerify∗, ClientCertificate∗, 4.4.3 Multi-Ciphersuite and Backwards-Compatibility Se- ClientCertificateVerify∗),

curity sid3 = (sid2, NewSessionTicket‘+’“RMS”), and Multi-Ciphersuite Security Definition 7. ( ) We say a multi- sid4 = (sid3, “EMS”). ciphersuite handshake protocol NP||SP~ is multi-ciphersuite The contributive identifiers are continuously appended secure with concurrent authentication types AUTH if NP||SP~ on sending (resp. receiving) the messages by the client satisfies both match security and key secrecy. and the server. When the client sends the ClientHello, Definition 8. (Backwards-Compatibility Security) Let NP||SP~ client_key_shares, and cipher_suites messages, it be a multi-ciphersuite handshake protocol, and the MCS sets GMatch GSecrecy,D games MCS,A and MCS,A be respectively extended to cid1 = (ClientHello, client_key_shares, Match Secrecy,D the BC games GBC,A and GBC,A by giving the adver- cipher_suites), BCAux sary additional access to the query . For a fixed and subsequently, on receiving the ServerHello, BCAux NP||SP~ backwards- BCFunc triggered by , we say is server_key_share, and cipher_suite messages, it ex- compatibility secure with concurrent authentication types tends the contributive identifier to AUTH if NP||SP~ still satisfies both match security and key ClientHello client_key_shares secrecy. cid1 = ( , , cipher_suites, ServerHello, server_key_share, bc-match Similarly, we define the advantages of A as AdvNP||SP~ ,A cipher_suite). Match bc-secrecy,D Secrecy,D = Pr [GBC,A = 1] and AdvNP||SP~ ,A = |Pr [GBC,A = 1] − The other contributive identifiers are set to cid2 = sid2, 1 2 |. cid3 = sid3, and cid4 = sid4 by each party on sending its respective Finished message. Remark 1. When the model is limited to a single ciphersuite (i.e., nSP = 1), our security definition is equivalent to the Theorem 1. multi-ciphersuite −−→ (TLS 1.3 draft-18 is secure.) original Match Security and Key Secrecy by Dowling et al. Let TLS be the multi-ciphersuite TLS 1.3 protocol with each [35]. In this case we denote the MCS-1 games as GMatch MCS-1,A of the nSP ciphersuites TLSc being a signed-Diffie-Hellman Secrecy,D mcs-1-match −−→ and GMCS-1,A , and the advantages of A as AdvNP||SP,A ciphersuite as in Section 3. Then TLS is multi-ciphersuite mcs-1-secrecy,D 1 and AdvNP||SP,A , respectively. secure in a key-independent and stage- -forward-secure manner with concurrent authentication properties AUTH = {(unauth, unauth, unauth, unauth), (unauth, unilateral, unilat- 5 MULTI-CIPHERSUITESECURITYOF TLS 1.3 eral, unilateral), (unauth, mutual, mutual, mutual)}. Formally, DRAFT-18 for any efficient adversary A, we have As described in the introduction, TLS 1.2 is not multi- mcs-match 2 1 −l EUF-CMA ciphersuite secure. The cross-protocol attack on TLS 1.2 Adv−→ ≤ nSP · (n · · 2 + nu · Adv ) TLS,A s q Sigc

10 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

and Lemma 5.2. Let TLSc be a single ciphersuite TLS 1.3 handshake protocol. Then TLSc provides key secrecy in a key- mcs-secrecy,D COLL EUF-CMA Adv−→ ≤ 4nSP · ns · 2Adv + 2nu · Adv TLS,A Hashc Sigc independent and stage-1-forward-secure manner with con- COLL PRF-ODH PRF-sec current authentication properties AUTH = {(unauth, unauth, +ns · Adv + Adv + 3Adv , Hashc PRFc,Gc PRFc unauth, unauth), (unauth, unilateral, unilateral, unilateral), (unauth, mutual, mutual, mutual)}. Formally, for any efficient n n where s is the maximum number of the sessions, u is the adversary A with additional access to a specific signing maximum number of the users, q is the group order, and l algorithm BCFuncc(·), we have is the bit length of the nonces.2 mcs-1-secrecy,D(A) ≤ 4n · 2 COLL + 2n · EUF-CMA AdvTLS ,BCFunc s AdvHashc u AdvSig Proof. We sketch the proof in the following steps: c c c COLL PRF-ODH PRF-sec Step 1. +n · Adv + Adv + 3Adv , First, we prove the security of a single ciphersuite s Hashc PRFc,Gc PRFc TLSc with additional access to a function BCFunc(·) repre- senting specific signing algorithm, using which the adver- where ns is the maximum number of the sessions in cipher- sary can get signatures from another ciphersuite (as long suite c and nu is the maximum number of the users. as queries to the function do not violate certain conditions Proof. Following [35] we consider the case that the adver- against trivial attacks). (Lemma 5.1 and Lemma 5.2) sary makes a single Test query only. Since there are ns Step 2. TLS Next, we prove that any ciphersuite d which sessions and each session has four stages, an arbitrary stage TLS shares long-term keys with c can be simulated using can be tested with a factor of 1 . From now on, we consider (·) 4ns BCFuncc . (Lemma 5.3) the tested query on session label at stage i. Step 3. Finally, we prove that the collection of the cipher- We consider the three (disjoint) cases separately in our suites is secure, even if the long-term keys are reused across subsequent security analysis: multiple ciphersuites. (Lemma 5.4) A. The tested query on a client session without an honest Before introducing the lemma, we extend the MCS- ,D contributive partner at the first stage; 1 games GMatch and GSecrecy to allow the adversary MCS-1,A MCS-1,A B. The tested query on a server session without an honest access to a signature oracle. Let TLS be a single ciphersuite c contributive partner at the first stage; protocol. In particular, the adversary A is given additional C. The tested query on a session with an honest contribu- access to the query BCFunc (m). If there exists d satisfying c tive partner at the first stage. δU,{c,d} = 1, the query returns Sigc.Sign(sk, Hc(m)). Note that in order to exclude trivial attacks, the query is returned Case A. Test Client without Partner ⊥ when the ciphersuite identifier contained in the queried The proof is similar to that in [35]; due to space concerns message m is equal to c (if the ServerHello message is we only sketch it in Table 1 (Case A part) and give detailed included in the queried message m and can be parsed to get description of the difference brought in by the auxiliary the ciphersuite identifier). Similarly, we define the advan- signing algorithm BCFuncc(·). A mcs-1-match (A) mcs-1-secrecy,D(A) tages of as AdvTLSc,BCFuncc and AdvTLSc,BCFuncc . TABLE 1 Sequence of Games in the Proof of Case A/B/C Lemma 5.1. Let TLSc be a single ciphersuite TLS 1.3 hand- Cases Games Probability loss Description Justification shake protocol. Then TLSc is match secure: for any efficient Game A.0 - initial game - A no collision in collision resistance adversary with additional access to a specific signing Game A.1 AdvCOLL Hashc hash function Hash of Hash Case A c c (·) no signature EUF-CMA algorithm BCFuncc , we have n · EUF-CMA Game A.2 u AdvSig c forgery of Sigc security of Sigc Game B.0 - initial game - mcs-1-match 2 1 −l EUF-CMA no collision in collision resistance AdvTLS (A) ≤ n · · 2 + nu · Adv , Game B.1 AdvCOLL c,BCFuncc s q Sigc Hashc hash function Hash of Hash Case B c c no signature EUF-CMA n · EUF-CMA Game B.2 u AdvSig c forgery of Sigc security of Sigc where ns is the maximum number of the sessions in cipher- Game C.0 - initial game - 1 guess the tested Game C.1 a factor of - suite c, nu is the maximum number of the users, q is the 4ns session’s partner COLL no collision in collision resistance group order, and l is the bit length of the nonces. Game C.2 AdvHash c hash function Hashc of Hashc PRF-ODH replace HS with a hardness of Game C.3 AdvPRF c ,Gc random string HS PRF-ODH assumption Case C f We need to show the single ciphersuite TLS 1.3 hand- replace ctshs,stshs, PRF-sec SFK, and CFK with random security of Game C.4 AdvPRF shake protocol satisfies the seven properties of Match Secu- c strings cts^hs, sts^hs, HKDF.Expand rity SFK,g and CFKg defined in Section 4.4.1. As the proof of this lemma is PRF-sec replace MS with a security of Game C.5 AdvPRF similar to that of Theorem 5.1 in [35], we omit it here3. c random string MSf HKDF.Extract replace ctkapp, stkapp,

PRF-sec RMS, and EMS with random security of Game C.6 AdvPRF c strings ctkâpp, stkâpp, HKDF.Expand 2. Our theorem is in line with Theorem 5.2 in [35], with the only ]RMS, and]EMS difference that following [37] (version 20170131) we switch to the PRF- ODH assumption. Game A.2. If the tested client session receives, within the 3. In [35], the authors proved that the draft-05 full handshake is ServerCertificateVerify multi-stage-secure without BCFuncc(·), which implies the match secu- message, a valid signature rity according to the security definition. We can conclude this property under the public key pkU of some user U ∈ U such that for the full handshake in draft-18 since they have similar structures, the hash value has not been signed by any of the honest with some minor changes (e.g., the key derivation function from PRF to HKDF). In addition, AdvEUF-CMA is also considered in our lemma, sessions, the challenger aborts the game. This means that Sigc since a successful forgery of the signature can result in a session to either the adversary A has computed a valid signature accept without having a partner with the same session identifier. himself, or A has utilized the signing algorithm BCFuncc(·)

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 11

to compute a signature on messages in this session. Just as a signed-Diffie-Hellman ciphersuite as in Section 3. Then for our definition of BCFuncc(·) demands, for all m queried any efficient adversary A, we can construct an algorithm B to BCFuncc(·), it returns ⊥ when the ciphersuite identifier such that contained in the queried message m is equal to c, and thus mcs-match mcs-1-match A Adv−→ ≤ nSP · Adv (B ) no query to the signature oracle helps A to get a valid TLS,A TLSc,BCFuncc signature in ciphersuite TLSc. and We now construct an EUF-CMA signature forger, who mcs-secrecy,D mcs-1-secrecy,D A Adv−→ ≤ nSP · Adv (B ). receives a public key pk as the challenge, guesses a user TLS,A TLSc,BCFuncc −−→ U for signature verification (which is responsible for our Proof. Our main idea is to construct a simulator B for TLS reduction loss of nu), replaces pk with pkU,c, generates such that whenever A breaks the match security or the key private/public key pair for any other user U 0 ∈ U \ {U} secrecy of ciphersuite TLSc* in the MCS game for multi- A −−→ in ciphersuite c, and runs the game Game A.1 for . ciphersuite secure protocol TLS, the algorithm B will, with Since each honest session has a different session iden- probability 1 , break the match security or the key secrecy tifier, the transcript value expected by the tested client nSP of a single ciphersuite TLSc with additional access to a session cannot be signed by any honest party. Besides, by signing algorithm BCFuncc(·), respectively. the modification in Game A.1, there is no collision between Let A be an adversary in the MCS game. Recall that at any two honest computations of the hash function, implying the beginning of the game, A sets the key reuse variable that the hash value in question has not been signed by an δU,{c,d} indicating whether the party U reuses the long-term honest party before. keys between TLSc and TLSd. In particular, if δU,{c,d} = 1, U Finally, if Game A.2 does not abort, it is assured that an will set skU,c = skU,d. honest session outputs the signature obtained by the tested The simulation of B is as follows. First, B chooses ˆc ∈ ServerCertificateVerify client within the message. {1, . . . , nSP} and interacts with a challenger in the MCS-1 Particularly, H(CH|| ... ||SCV), containing all messages in game for TLSˆc with BCFuncc(·). B obtains the parties’ public sid1, is used for the honest party to compute the signature. keys for TLSc from the MCS-1 game. For each party U and As a consequence, the tested client and the (distinct) honest each TLSd, if δU,{c,d}=1 then B sets the public key of U in session outputting the signature agree on sid1and then cid1, TLSd to its public key in TLSc; otherwise, it generates a fresh and thus are partnered at the first stage. The adversary A key pair for TLSd. B gives all of these public keys to A. cannot test a client session without an honest first-stage Next, B proceeds as the challenger of the MCS game partner in Game A.2, resulting in the test bit btest being for A. Any queries including NewSession, Send, Reveal, unknown to A and the advantage of A in Game A.2 being Corrupt, and Test specified in the MCS game can be made negl(λ). by A. B needs to answer all of them. B will start off Case B. Tests Server without Partner every session by relaying it to the challenger of the MCS-1 The proof is similar to that in [35], and here we only security game for TLSˆc with the auxiliary signing algorithm sketch it in Table 1 (Case B part) and describe the difference BCFuncc(·). If a session ends up negotiating TLSˆc, then B brought in by the auxiliary signing algorithm BCFuncc(·). continues relaying all queries for that session to the TLSˆc Game B.2. In this game, if the tested server session re- challenger. If a session ends up negotiating TLSd other than ceives, within the ClientCertificateVerify message, TLSˆc, B needs to simulate it. If δU,{ˆc,d}=0, the simulation pk a valid signature under the public key U of some user of TLSd is trivial since B generates U’s private key for it; U ∈ U such that the hash value has not been signed by otherwise if δU,{ˆc,d}=1, according to Lemma 3, the TLSd can any of the honest sessions, the challenger aborts the game. be simulated by the signing algorithm BCFuncˆc(·). Besides, The simulation of the signature forger is the same as that in the output of the simulation is precisely a valid message for Game A.2. TLSd, and thus the simulation is perfect. Case C. Tests with Partner Suppose A breaks the match security (or key secrecy) −−→ ∗ The proof is similar to that in [35], with minor changes in TLS. Then, there exist a c ∈ {1, . . . , nSP} and a session such as the new key calculation schedule shown in [15] (on with label breaking the match security (or key secrecy) in 1 ∗ pages 76-79). We only provide a proof sketch in Table 1 (Case ∗ ˆ TLSc . With probability n , c = c . Thus B breaks the C part). SP match security (or key secrecy) of a single ciphersuite TLSˆc TLS with additional access to a signing algorithm BCFuncˆc(·). Lemma 5.3. Let d be a single ciphersuite in the TLS 1.3 mcs-match mcs-1-match A Finally, we have Adv−→ ≤ nSP · AdvTLS (B ) handshake protocol. Then TLSd can be simulated using the TLS,A c,BCFuncc mcs-secrecy,D mcs-1-secrecy,D A (·) δ = 1 and Adv−→ ≤ nSP · Adv (B ). auxiliary signing algorithm BCFuncc if U,{c,d} . TLS,A TLSc,BCFuncc

Proof. The only secret information of TLSd is the shared Theorem 1 now follows immediately from Lemmas 5.1- long-term keys with TLSc. What the simulation algorithm 5.4. does is the same as what TLS does except that the sig- d Remark 2. Just like speciﬁed in TLS 1.3 draft-18, the pre- nature operation is replaced by BCFunc (·). According to c shared key (PSK) ciphersuite does not contain any public the constraint of BCFunc (·), the correct signature query c key scheme, and the only relationship with other signature- in TLS should be allowed. Thus, TLS can be simulated d d based ciphersuites comes from the derivation of the pre- correctly. shared master secret. Thus, the PSK ciphersuite is indepen- −−→ Lemma 5.4. Let TLS be the multi-ciphersuite TLS 1.3 hand- dent of other ciphersuites, and our model and proof provide shake protocol with each of the nSP ciphersuites TLSc being the security guarantee for PSK.

12 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

6 ONTHE BACKWARDS-COMPATIBILITY SECURI- configure the popular TLS server implementation OpenSSL TYOFTHE TLS 1.3 HANDSHAKE PROTOCOL such that different RSA certificates are used for different TLS versions or different ciphersuite families. Another obvious In this section, we analyze the backwards-compatibility solution is to invalidate vulnerable ciphersuites in these security of TLS 1.3. By recalling the cross-version attack versions, however, which breaks standard-conformance, s- of Jager et al. [19], we show why TLS 1.3 is not secure ince PKCS #1 v1.5 encryption based key transport is the in our security model. Furthermore, we prove that the only mandatory-to-implement ciphersuite in TLS 1.1 and TLS 1.3 draft-18 multi-ciphersuite handshake protocol meets 1.2. Thus, the need for backwards compatibility and inter- our strong notion of backwards-compatibility security if an operability in practice makes it impossible to employ these older version (such as TLS 1.2) has been upgraded with the countermeasures. countermeasures recommended in the standard [1]. Even though PKCS #1 v1.5 is abolished in TLS 1.3, the coexistence with older TLS versions is still a large 6.1 Capturing Jager et al.’s Attack in Our Model barrier to achieve the backwards security of TLS 1.3. It We recall the backwards compatibility attack on TLS 1.3 is worth mentioning that the TLS standards [1], [42], [43] draft-07 proposed by Jager et al. in 2015 [19]. Specifically, we have added a note to describe countermeasures to avoid consider a setting where there is a TLS client C that supports Bleichenbacher’s padding oracle attack: “In any case, a TLS only TLS 1.3, and thus may expect that it is immune to the server MUST NOT generate an alert if processing an RSA- weakness in older versions (e.g., the Bleichenbacher RSA encrypted premaster secret message fails, or the version number is padding oracle attack [20] on TLS 1.2). However, in order to not as expected. Instead, it MUST continue the handshake with a maximize compatibility with different TLS clients, a server randomly generated premaster secret.” Intuitively, this method S supports TLS 1.3 and TLS 1.2 simultaneously, and thus the hides the decryption failure from the adversary, makes server may use the same RSA certificate for both versions. the adversary unable to distinguish incorrectly formatted Note that PKCS #1 v1.5 encryption is supported in TLS 1.2, message blocks and/or mismatched version numbers from and then we show that the vulnerability of TLS 1.2 against correctly formatted RSA blocks, and finally invalidates the Bleichenbacher’s attack allows an adversary to impersonate ciphertext checking oracle. S towards C. In particular, Bleichenbacher’s attack enables the adversary to decrypt PKCS #1 v1.5 ciphertexts without 6.3 Backwards-Compatibility Security of TLS 1.3 with knowing the private key of RSA, as long as there exists an Countermeasures “oracle” that allows the adversary to distinguish “valid” In this subsection, we prove that the proposed counter- from “invalid” PKCS #1 v1.5 padded ciphertext. Such an or- measures on TLS 1.2 (as mentioned in Section 6.2) provide acle may in practice be given by a TLS 1.2 server’s response. good protection for TLS 1.3 against backwards compatibility It is sufficient for the adversary to compute a “forged” RSA attacks. signature using the decrypted plaintext message, which in Definition 9. (EUF-CMA security in the presence of an turn is sufficient for the adversary to impersonate S towards auxiliary oracle) Let Sig = (Sig.Gen, Sig.Sign, Sig.Verify) C in TLS 1.3. be a signature scheme, BCFunc be an algorithm sharing Formally, this attack is captured by our security model in keys with Sig. The existential unforgeability of the signature Section 4 as follows. The adversary A can query an auxiliary scheme under an adaptive chosen message attack (EUF- oracle BCAux(S, c, m), where δ =1, TLS denotes a ci- S,{c,d} c CMA) in the presence of an auxiliary oracle is defined phersuite in TLS 1.3 containing RSA signature, TLS denotes d through the following game: a ciphersuite in TLS 1.2 containing PKCS #1 v1.5 encryption, 1) The adversary A receives the public key pk with and the same RSA certificate of S is shared between TLSc (pk, sk) ← Sig.Gen(1κ) and TLS . In this case, the BCFunc is the server’s response . d A m for queried PKCS #1 v1.5 ciphertext, which returns the 2) makes signature queries for messages of his choice, decryption result on message m (“valid” or “invalid”). This and the challenger responds to each signature query σ =Sig.Sign sk, m A is sufficient for the adversary to compute a forged signature with a signature ( ). Additionally, c on m. This means sessions are not partnered with intended makes an auxiliary oracle queries for messages of his sk c (authenticated) participants, and thus the match security of choice, and the challenger responds with BCFunc( , ) ⊥ the protocol is broken. Furthermore, if the queried message or a failure symbol . 3) A outputs the signature of a message m0 which was not is chosen by the adversary, the key secrecy of the protocol is queried for signature before. also broken. Therefore, TLS 1.3 cannot provide backwards- EUF-CMA compatibility security if an older version is not upgraded The advantage AdvSig,BCFunc of an adversary A is the prob- with the countermeasures recommended in the standard. ability he wins the above game. A signature scheme is existentially unforgeable under an adaptive chosen message attack in the presence of an auxiliary oracle if for 6.2 Lessons from Jager et al.’s Attack EUF-CMA any polynomial-time bounded adversary, AdvSig,BCFunc is The backwards compatibility attack on TLS 1.3 is mainly negl(λ). due to the fact that the server uses the same RSA certificate To prove the backwards-compatibility security of TLS 1.3 in TLS 1.3 and older versions. In order to prevent this with countermeasures, we introduce two lemmas first. attack, a first obvious approach is therefore to enforce key −−→ separation, that is, to use different keys for different protocol Lemma 6.1. Let TLS be the multi-ciphersuite TLS 1.3 hand- versions. However, in practice there is no effective way to shake protocol with each of the nSP ciphersuites TLSc

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 13

being a signed-Difﬁe-Hellman ciphersuite as in Section 3, this particular random oracle can be used to solve the RSA and BCFuncc(·) be an algorithm instantiated by server’s problem. response in TLS 1.2. Then for any efﬁcient adversary A, for Second, in order to resist Bleichenbacher’s attack, the all ciphersuites c, we have TLS standard has adopted the countermeasures [1] that bc-match 2 1 −l EUF-CMA require the server to continue the handshake with a ran- Adv−→ ≤ nSP · (ns · · 2 + nu · AdvSig , ) TLS,A q c BCFuncc domly generated premaster secret (pms) if the decryption and of an RSA-encrypted premaster secret message fails. As

bc-secrecy,D COLL EUF-CMA described in [30], the KEM underlying the TLS-RSA (PKCS Adv−→ ≤ 4nSP · ns · 2Adv + 2nu · Adv TLS,A Hashc Sigc,BCFuncc #1 v1.5 with these countermeasures) satisfies the IND-CCCA COLL PRF-ODH PRF-sec (indistinguishability against constrained chosen-ciphertext +ns · Adv + Adv + 3Adv , Hashc PRFc,Gc PRFc attack) security based on the known result that PKCS #1 v1.5 is OW-PCA (one-way against plaintext checking attacks) where ns is the maximum number of the sessions, nu is the maximum number of the users, q is the group order, and l secure [48]. In the security game, the adversary is provided CDec is the bit length of the nonces. with a constrained decryption oracle that returns the correct session key and the unencrypted Finished message Proof. In TLS 1.3, all the supported public key schemes are only when the PKCS #1 v1.5 ciphertext is valid. signature algorithms including RSASSA-PSS, ECDSA, and In our proof, we want to prove that the RSASSA-PSS is EdDSA. Correspondingly, in TLS 1.2, the supported public EUF-CMA secure even if the long-term keys are shared with key schemes include RSAES-PKCS1-v1 5, RSASSA-PKCS1- the PKCS #1 v1.5 encryption in TLS 1.2. Since we consider v1 5, DSA, and ECDSA. Therefore, the key reuse cases the case of TLS 1.2 with proposed countermeasures, accord- across versions may be RSASSA-PSS & RSAES-PKCS1-v1 5, ing to the result of [30], the adversary of RSASSA-PSS has RSASSA-PSS & RSASSA-PKCS1-v1 5, or ECDSA & ECD- extra access to CDec in [30], which is the BCFunc(·) in our SA. We have captured all of them through the backwards lemma. compatibility oracle BCAux (instantiated as different BC- Now the challenge of the proof is to simulate the CDec Funcs) in our model. More specifically, if SPd contains an oracle without knowing the secret key for signing. Just as encryption scheme such as RSA PKCS #1 v1.5 used in the we have mentioned, the TLS-RSA (PKCS #1 v1.5 with these TLS-RSA public key encryption mode, then the BCFuncc(m) countermeasures) can be extracted as a KEM, which is IND- represents a decryption oracle on arbitrary message m; if CCCA secure based on the OW-PCA security of PKCS #1 SPd contains a signature scheme, then the BCFuncc(m) v1.5 (with a plaintext checking oracle PCA(·)). Note that in represents a signature oracle on arbitrary message m, ex- our proof, we model KDF(·) as a random oracle and there cept that the ciphersuite identifier contained in the queried exists a KDF-query list. If an adversary queries the CDec message m is equal to c (in order to exclude trivial attacks). oracle with the message m for decryption, the simulator Thus the proof is similar to that of Theorem 1, and the will parse m to get a ciphertext c for unknown pms. Then difference is caused by the auxiliary oracle. In particular, for each KDF-query in the form (pms, ∗) ever issued by AdvEUF-CMA in Theorem 1 is replaced with AdvEUF-CMA . the adversary, the simulator uses its PCA(·) oracle to check Sigc Sigc,BCFuncc In addition, we show that any key reused ciphersuite whether the pair (pms, c) is a valid plaintext-ciphertext pair in TLS 1.2 can be simulated using specific BCFunc. As we and if so it answers that query with pms. have elaborated above, BCFunc(·) provides a private key Thus, the adversary cannot get any decryption infor- operation result on its queried message, and the limitation mation on a manipulated ciphertext, and cannot use this of the input for BCFunc(·) is only reflected on the current decryption oracle to forge valid signatures on any freely version (i.e., TLS 1.3) when the BCFunc(·) represents a chosen messages. In brief, even for the share of long-term signing algorithm. Thus, the simulation of BCFunc(·) for keys, the PKCS #1 v1.5 in TLS with the proposed fixes can- any key reused ciphersuite in TLS 1.2 is perfect. not help the PSS scheme’s forger to forge a valid signature on the arbitrary message he chooses. The remaining proof is Since RSA is the only algorithm which is used both in the the same as that in [47], we omit it here. encryption (PKCS #1 v1.5) and in the signature (RSASSA- PSS), in Lemma 6.2 we will prove the EUF-CMA security Theorem 2. If the recommended countermeasures are of the RSASSA-PSS in the presence of an auxiliary oracle adopted in TLS 1.2, then TLS 1.3 draft-18 multi-ciphersuite as given in Definition 9, where BCFunc(·) is a constrained handshake protocol is backwards-compatibility secure w.r.t. decryption oracle. TLS 1.2. Lemma 6.2. The RSASSA-PSS used in TLS 1.3 is EUF- CMA secure in the presence of an auxiliary oracle, if the Proof. According to Lemma 6.1, to complete the proof of this theorem, we only need to prove AdvEUF-CMA is negligible. BCFunc(·) is a constrained decryption oracle in the IND- Sigc,BCFuncc CCCA secure KEM instantiated by TLS-RSA in 1.2 with In our setting, there are only three kinds of key reuse recommended countermeasures. scenarios: (1) key reuse between two ciphersuites in TLS 1.3, which has been proved in Section 5; (2) key reuse Proof. First, according to [47], EUF-CMA security of the between a signature scheme in TLS 1.3 and a signature RSASSA-PSS scheme is reduced to the RSA problem by scheme in TLS 1.2, which can be proved in the same way embedding the challenge in the inverse of RSA problem into as in (1) with BCFunc(·) as the auxiliary signing algorithm; the simulation of a particular random oracle. Specifically, (3) key reuse between a signature scheme in TLS 1.3 and a successful signature forgery on the message queried to a public encryption scheme in TLS 1.2 (RSASSA-PSS and

14 IEEE TRANSACTIONS ON DEPENDABLE AND SECURE COMPUTING

RSAES-PKCS1-v1 5, respectively), which has been proved [9] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud, C. Fournet, in Lemma 6.2. M. Kohlweiss, A. Pironti, P. Strub, and J. K. Zinzindohoue, “A messy state of the union: Taming the composite state machines of Remark 3. The backwards-compatibility security of TLS 1.3 TLS,” in Proc. IEEE S&P, May 2015, pp. 535–552. [10] D. Adrian, K. Bhargavan, Z. Durumeric, P. Gaudry, M. Green, J. A. with other older versions such as TLS 1.1 or TLS 1.0 can be Halderman, N. Heninger, D. Springall, E. Thome,´ L. Valenta et al., achieved in the same way if they have been upgraded with “Imperfect forward secrecy: How diffie-hellman fails in practice,” the countermeasures recommended in the standards [42], in Proc. ACM CCS, Oct. 2015, pp. 5–17. [43]. [11] M. R. Albrecht and K. G. Paterson, “Lucky microseconds: A timing attack on amazon’s s2n implementation of TLS,” in Proc. EUROCRYPT, May 2016, pp. 622–643. [12] R. Bricout, S. Murphy, K. G. Paterson, and T. van der Merwe, 7 CONCLUSIONS “Analysing and exploiting the mantin biases in RC4,” IACR Cryp- tology ePrint Archive, Report 2016/063, 2016. http://eprint.iacr. The IETF is currently developing the next-generation TLS, org/. version 1.3. The transparency of the standardization process [13] K. Bhargavan and G. Leurent, “Transcript collision attacks: Break- allows for comprehensive investigation of the protocol prior ing authentication in TLS, IKE and SSH,” in Proc. NDSS, Feb. 2016. [14] M. Green, “On the (provable) security of TLS,” Sep. 2012. https: to adoption, and we are motivated to take this opportunity //blog.cryptographyengineering.com/2012/09/06/on-provable- to look into the vexing and recurring problem of key reuse security-of-tls-part-1/, https://blog.cryptographyengineering. in such a critical Internet standard. com/2012/09/28/on-provable-security-of-tls-part-2/. We have developed a formal security model for multi- [15] E. Rescorla, “The Transport Layer Security (TLS) protocol version 1.3 draft-ietf-tls-tls13-18,” Oct. 2016. https://tools.ietf.org/html/ ciphersuite key exchange protocols, covering all known draft-ietf-tls-tls13-18. kinds of compositional interactions of different ciphersuites [16] “Transport Layer Security (TLS) parameters,” http://www.iana. and protocol versions, and providing reasonably strong org/assignments/tls-parameters/tls-parameters.xhtml. security guarantees. We have proved the multi-ciphersuite [17] “Survey of the SSL implementation of the most popular web sites,” https://www.trustworthyinternet.org/ssl-pulse/. security of the TLS 1.3 candidate draft-18, and further [18] T. Jager, K. G. Paterson, and J. Somorovsky, “One bad apple: Back- validated the design of the TLS 1.3 handshake protocol. In wards compatibility attacks on state-of-the-art cryptography,” in addition, we have identified the backwards compatibility Proc. NDSS, Feb. 2013. attack on TLS 1.3 draft-07 [19] in our model. We have [19] T. Jager, J. Schwenk, and J. Somorovsky, “On the security of TLS 1.3 and QUIC against weaknesses in PKCS#1 v1.5 encryption,” in also shown that TLS 1.3 draft-18 is backwards-compatibility Proc. ACM CCS, Oct. 2015, pp. 1185–1196. secure with the countermeasures recommended in the TLS [20] D. Bleichenbacher, “Chosen ciphertext attacks against protocols 1.2 standard [1], which can be summarized as follows: to based on the RSA encryption standard PKCS #1,” in Proc. CRYP- prevent a malicious client from misusing the server as a TO, Aug. 1998, pp. 1–12. [21] N. Aviram, S. Schinzel, J. Somorovsky, N. Heninger, M. Dankel, decryption oracle, the server should continue the handshake J. Steube et al., “DROWN: Breaking TLS using SSLv2,” in Proc. (without triggering an alert) with a randomly generated USENIX Sec., Aug. 2016, pp. 689–706. premaster secret even if it fails to process the premaster [22] S. Haber and B. Pinkas, “Securely combining public-key cryp- secret encrypted with RSA by the client. tosystems,” in Proc. ACM CCS, Nov. 2001, pp. 215–224. [23] J.-S. Coron, M. Joye, D. Naccache, and P. Paillier, “Universal Concerning the key reuse problem, our model-based padding schemes for RSA,” in Proc. CRYPTO, Aug. 2002, pp. 226– treatment is also applicable to the analysis of other protocols 241. such as QUIC. Future work includes proposing a generic [24] Y. Komano and K. Ohta, “Efficient universal padding techniques analysis framework of multi-ciphersuite and backwards- for multiplicative trapdoor one-way permutation,” in Proc. CRYP- TO, Aug. 2003, pp. 366–382. compatibility security in a modular fashion. We also hope [25] K. G. Paterson, J. C. Schuldt, M. Stam, and S. Thomson, “On our research effort can shed light on practical issues in and the joint security of encryption and signature, revisited,” in Proc. facilitate the design of relatively complex security protocols. ASIACRYPT, Dec. 2011, pp. 161–178. [26] J. P. Degabriele, A. Lehmann, K. G. Paterson, N. P. Smart, and M. Strefler, “On the joint security of encryption and signature in EMV,” in Proc. CT-RSA, Feb. 2012, pp. 116–135. EFERENCES R [27] F. Bergsma, B. Dowling, F. Kohlar, J. Schwenk, and D. Stebila, [1] T. Dierks, “The Transport Layer Security (TLS) protocol ver- “Multi-ciphersuite security of the Secure Shell (SSH) protocol,” sion 1.2,” IETF RFC 5246, Aug. 2008. https://tools.ietf.org/html/ in Proc. ACM CCS, Nov. 2014, pp. 369–381. rfc5246. [28] M. Bellare and P. Rogaway, “Entity authentication and key distri- [2] K. G. Paterson and T. van der Merwe, “Reactive and proactive bution,” in Proc. CRYPTO, Aug. 1993, pp. 232–249. standardisation of TLS,” in Proc. SSR, Dec. 2016, pp. 160–186. [29] T. Jager, F. Kohlar, S. Schage,¨ and J. Schwenk, “On the security of [3] M. Ray and S. Dispensa, “Renegotiating TLS,” Nov. 2009. TLS-DHE in the standard model,” in Proc. CRYPTO, Aug. 2012, [4] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and B. Pre- pp. 273–293. neel, “A cross-protocol attack on the TLS protocol,” in Proc. ACM [30] H. Krawczyk, K. G. Paterson, and H. Wee, “On the security of the CCS, Oct. 2012, pp. 62–72. TLS protocol: A systematic analysis,” in Proc. CRYPTO, Aug. 2013, [5] N. J. AlFardan and K. G. Paterson, “Lucky thirteen: Breaking the pp. 429–448. TLS and DTLS record protocols,” in Proc. IEEE S&P, May 2013, [31] F. Giesen, F. Kohlar, and D. Stebila, “On the security of TLS pp. 526–540. renegotiation,” in Proc. ACM CCS, Nov. 2013, pp. 387–398. [6] N. J. AlFardan, D. J. Bernstein, K. G. Paterson, B. Poettering, and [32] Y. Li, S. Schage,¨ Z. Yang, F. Kohlar, and J. Schwenk, “On the J. C. N. Schuldt, “On the security of RC4 in TLS,” in Proc. USENIX security of the pre-shared key ciphersuites of TLS,” in Proc. PKC, Sec., Aug. 2013, pp. 305–320. Mar. 2014, pp. 669–684. [7] J. Cooperband, “The heartbleed bug,” Apri. 2014. http:// [33] K. Bhargavan, C. Fournet, M. Kohlweiss, A. Pironti, P.-Y. Strub, heartbleed.com. and S. Zanella-Beguelin,´ “Proving the TLS handshake secure (as it [8] K. Bhargavan, A. D. Lavaud, C. Fournet, A. Pironti, and P. Y. is),” in Proc. CRYPTO, Aug. 2014, pp. 235–255. Strub, “Triple handshakes and cookie cutters: Breaking and fixing [34] B. Dowling and D. Stebila, “Modelling ciphersuite and version authentication over TLS,” in Proc. IEEE S&P, May 2014, pp. 98– negotiation in the TLS protocol,” in Proc. ACISP, Jun. 2015, pp. 113. 270–288.

LAN et al.: INVESTIGATING THE MULTI-CIPHERSUITE AND BACKWARDS-COMPATIBILITY SECURITY OF THE UPCOMING TLS 1.3 15

[35] B. Dowling, M. Fischlin, F. Gunther,¨ and D. Stebila, “A crypto- Zhen-Feng Zhang received the PhD degree graphic analysis of the TLS 1.3 handshake protocol candidates,” from Academy of Mathematics and Systems Sci- in Proc. ACM CCS, Oct. 2015, pp. 1197–1210. ence, Chinese Academy of Sciences in 2001. [36] M. Fischlin and F. Gunther,¨ “Multi-stage key exchange and the He is currently a research professor and director case of google’s QUIC protocol,” in Proc. ACM CCS, Nov. 2014, PLACE with Trusted Computing and Information Assur- pp. 1193–1204. PHOTO ance Laboratory, Institute of Software, Chinese [37] B. Dowling, M. Fischlin, F. Gunther,¨ and D. Stebila, “A cryp- HERE Academy of Sciences. His main research inter- tographic analysis of the TLS 1.3 draft-10 full and pre-shared ests include applied cryptography, security pro- key handshake protocol,” IACR Cryptology ePrint Archive, Report tocol and trusted computing. He is a member of 2016/081, 2016. http://eprint.iacr.org/. Chinese Association for Cryptologic Research. [38] H. Krawczyk and H. Wee, “The OPTLS protocol and TLS 1.3,” IACR Cryptology ePrint Archive, Report 2015/978, 2015. http:// eprint.iacr.org/. [39] C. Cremers, M. Horvat, S. Scott, and T. Van Der Merwe, “Auto- mated analysis and veriﬁcation of TLS 1.3: 0-RTT, resumption and delayed authentication,” in Proc. IEEE S&P, May 2016, pp. 470– 485. [40] X. Li, J. Xu, Z. Zhang, D. Feng, and H. Hu, “Multiple handshakes security of TLS 1.3 candidates,” in Proc. IEEE S&P, May 2016, pp. 486–505. [41] K. Bhargavan, C. Fournet, M. Green, M. Kohlweiss, and S. Z. Beguelin,´ “Downgrade resilience in key-exchange protocols,” in Proc. IEEE S&P, May 2016, pp. 506–525. [42] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) protocol version 1.1,” IETF RFC 4346, Apr. 2006. https://tools.ietf. org/html/rfc4346. [43] T. Dierks and C. Allen, “The Transport Layer Security (TLS) protocol version 1.0,” IETF RFC 2246, Jan. 1999. https://tools.ietf. org/html/rfc2246. [44] J. Katz and Y. Lindell, Introduction to Modern Cryptography (Chap- man & Hall/ CRC Cryptography and Network Security Series), Chap- man & Hall/CRC, 2007. [45] O. Goldreich, S. Goldwasser, and S. Micali, “How to construct random functions,” J. ACM, vol. 33, no. 4, pp. 792–807, 1986. [46] S. Goldwasser, S. Micali, and R. L. Rivest, “A digital signature scheme secure against adaptive chosen-message attacks,” SIAM J. Comput., vol. 17, no. 2, pp. 281–308, 1988. [47] M. Bellare and P. Rogaway, “The exact security of digital signatures-How to sign with RSA and Rabin,” in Proc. EURO- CRYPT, May 1996, pp. 399–416. [48] J. Jonsson and B. S. Kaliski Jr, “On the security of RSA encryption Wen-Tao Zhu received the B.E. and Ph.D. de- in TLS,” in Proc. CRYPTO, Aug. 2002, pp. 127–142. grees from University of Science and Technology of China, in 1999 and 2004, respectively. Since July 2004, he has been a faculty member with PLACE State Key Laboratory of Information Security, PHOTO which is now part of Institute of Information Engi- HERE neering, Chinese Academy of Sciences, where he has been a full professor since Oct. 2011. His research interests include network and infor- Xiao Lan received the B.E. degree in information mation security as well as applied cryptography. security from Sichuan University, Chengdu, Chi- He is a senior member of the IEEE Computer na, in 2012. She is currently a PhD candidate in Society. Since Aug. 2011, he has been on the editorial board of Journal information security with State Key Laboratory of of Network and Computer Applications published by Elsevier. PLACE Information Security, Institute of Information En- PHOTO gineering, Chinese Academy of Sciences, Bei- HERE jing, China. Her major research interests include applied cryptography and authenticated key exchange protocol.

Jing Xu received the PhD degree in Computer Theory from Academy of Mathematics and Sys- tems Science, Chinese Academy of Sciences in June 2002. She is currently a research professor PLACE with Trusted Computing and Information Assur- PHOTO ance Laboratory, Institute of Software, Chinese HERE Academy of Sciences. Her research interests include applied cryptography and security protocol. She is a member of Chinese Association for Cryptologic Research.