There are two primary modes of the TLS 1.3 handshake protocol. The document standardizing TLS 1.3, RFC 8446 , was published in August 2018 and has already seen widespread adoption.įrom a cryptographic perspective, major design changes in TLS 1.3 compared to version 1.2 include: (1) encrypting some handshake messages with an intermediate session key, to provide confidentiality of handshake data such as the client certificate (2) signing the entire handshake transcript for authentication (3) including hashes of handshake messages in a variety of key calculations (4) using different keys to encrypt handshake messages and application data (5) deprecating a variety of cryptographic algorithms (including RSA key transport, finite-field Diffie–Hellman key exchange, SHA-1, RC4, CBC mode, MAC-then-encode-then-encrypt) (6) using modern authenticated encryption with associated data (AEAD) schemes for protecting application data and (7) providing handshakes with fewer message flows to reduce latency. From 2014 through 2018, a total 29 drafts of TLS 1.3 were published, with active feedback from industry and academia, including extensive security analyses by various teams from academia (see for a chronicle of the development and analysis of TLS 1.3). With concerns rising about the security of TLS version 1.2 due to the many attacks, but also motivated by desire to deprecate old algorithms, enhance privacy, and reduce connection establishment latency, in 2014 the IETF’s TLS working group initiated a multi-year process to develop and standardize a new version of TLS, eventually called version 1.3. 1.1 Development and Standardization of TLS 1.3 Starting around 2009, there were many practical attacks on the then-current version 1.2 of TLS that received significant attention, exploiting weaknesses in underlying cryptographic primitives (such as weaknesses in RC4 ), errors in the design of the TLS protocol (e.g., BEAST, the Lucky 13 attack, the triple handshake attack, the POODLE attack, the Logjam attack ), or flaws in implementations (e.g., the Heartbleed attack, state machine attacks (SMACK )). Despite its large-scale deployment, or perhaps because of it, we have witnessed frequent successful attacks against TLS. Originally developed as the Secure Sockets Layer (SSL) protocol version 3 in 1996, TLS version 1.0 was standardized by the Internet Engineering Task Force (IETF) in 1998 , with subsequent revisions to version 1.1 (2006) and version 1.2 (2008) . The TLS handshake protocol allows a client and a server to authenticate each other and to establish a key, and the subsequent record layer protocol provides confidentiality and integrity for communication of application data. The Transport Layer Security (TLS) protocol is one of the most widely deployed cryptographic protocols in practice, protecting numerous web and e-mail accesses every day. We show that these TLS 1.3 handshake protocol modes establish session keys with their desired security properties under standard cryptographic assumptions. Our analysis in the reductionist security framework uses a multi-stage key exchange security model, where each of the many session keys derived in a single TLS 1.3 handshake is tagged with various properties (such as unauthenticated versus unilaterally authenticated versus mutually authenticated, whether it is intended to provide forward security, how it is used in the protocol, and whether the key is protected against replay attacks). We address both the full TLS 1.3 handshake (the one round-trip time mode, with signatures for authentication and (elliptic curve) Diffie–Hellman ephemeral ((EC)DHE) key exchange), and the abbreviated resumption/“PSK” mode which uses a pre-shared key for authentication (with optional (EC)DHE key exchange and zero round-trip time key establishment). We analyze the handshake protocol of the Transport Layer Security (TLS) protocol, version 1.3.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |