OPTLS and TLS 1.3 protocols
The TLS protocol (Transport Layer Security), is the most important cryptographic protocol, responsible for providing security to web communications and other applications. It's based on SSL (Secure Sockets Layer) 3.0 version. Previous versions of TLS protocol:
- TLS 1.0 – january 1999;
- TLS 1.1 – april 2006;
- TLS 1.2 – august 2008;
In spite of this fundamental role in the Internet security infrastructure, the protocol has been repeatedly shown to suffer of security weaknesses that have been addressed with occasional updates and patches. Current changes added to protocol non-trivial complexity and difficulty of implement. Key-exchange protocol TLS 1.3, namely, handshake protocol includes: «0-RTТ» options, that would reduce latency in cases where the client has a previously retrieved or cached public key of the server by allowing the client to transmit protected information already in the first flow of the protocol; adding PFS (perfect forward security) as a mandatory feature; using elliptic curves as the main cryptographic tool for the implementation of the protocol.These requirements call for moving away from the traditional RSA-centric design of the TLS Handshake in favor of a protocol that is based on Diffie-Hellman techniques. In addition, the «0-RTT» requirements requires the inclusion of a one-message key-exchange protocol which, in turn, requires a KEM mechanism for authentication (digital signatures cannot provide authentication in a one-message protocol). This mechanism needs to be based on Diffie-Hellman if implemented via elliptic curves. OPTLS protocol designed to perform needs of TLS 1.3, listed above. Due to the complexity of the TLS environments, one cannot over-emphasize the importance of laying the cryptographic foundation of TLS on a simple protocol that provides sufficient flexibility to adapt to the many different use scenarios of TLS while offering a modular and uniformlogic across its different modes.Such modularity and uniform logic is essential for aiding the specification of TLS 1.3 and its analysis, and as a basis for the many other protocols and applications that are based on TLS.
The OPTLS protocol
OPTLS based on simple protocol, illustrated in figure below, executed between client C (left side), and server S (right side).This version provides server-only authentication (the most common use case in TLS) assumes the possession by the server S of a CA-signed DH certificate certS binding the server’s identity to a DH key (where s is the server static secret key). We note that while authentication via DH certificates will not be the typical use case in TLS, this mode is useful to illustrate the logic of OPTLS (in the more common setting, this logic is preserved but the server itself will sign a static or ephemeral key using a signature certificate). Values , represent unique session nonces, and , represent protocol parameters negotiated by the parties to agree on a protocol version, cryptographic algorithms, etc. Authentication is provided by a MAC, computed with key sfk derived from the value ; values x and y are ephemeral secrets chosen by the client and server, respectively. The information shown under theMAC represents the information that must be authenticated but in the actual protocol other elements may be included. The output of the protocol is a session key derived jointly from and with the former ensuring securing for as long as the server’s private key s is secure.
Cached keys and 0-RTT
An operational mode required by TLS 1.3 and supported by OPTLS is the use of server’s static keys cached by a client or retrieved out of band. This is needed to support a “0-RTT mode" in which the client can send data already in the first message of the protocol, following the value , and protect it using authenticated encryption under a key derived from . Such a 0-RTT mode is mandatory for TLS 1.3 and is intended to decrease the latency. typical application example  is that of a user sending a TLS-protected query to a search engine; with current TLS, the browser and server need to exchange handshake-specific messages before they can establish the secure channel on which to transmit the query. Using the 0-RTT mode, the client can send its protected query already in its first message. In addition, cached server’s keys (received by the client in a previous session with the server) also allow for handshake sessions without signatures at all, something that may be particularly beneficial when using RSA signatures.
An important consideration for the use of a 0-RTT mode is the fact that data (early data) transmitted in the first message under the protection of is open to replay by an attacker. OPTLS does not include a specific anti-replay mechanism as this can be implemented in different forms by different implementations, independently of the KE mechanism.
One of the salient properties of OPTLS is its flexibility and the way it can support different performance needs. OPTLS provides variants where server signatures are not used at all (the case of DH certificates), or only used offline, or used online but amortized over repeated uses of cached keys.
TLS 1.3 requires its handshake messages to be protected to the extent possible with authenticated encryption (AEAD).This is intended to hide the contents of some messages such as the server identity/certificate from an observer. OPTLS derives an additional handshake traffic key (htk) from and starts encrypting all handshake traffic following the , value sent in the server’s message (the first client’s message is not protected, except for client’s early data in the 0-RTT case). In OPTLS and TLS 1.3, the key htk for encrypting handshake traffic is computational independent of that for application traffic, even though both keys are derived from .
OPTLS in TLS 1.3
OPTLS adapted to the current specification of TLS 1.3, together with the universal treatment of all major modes, including mode PSK. The security protocol OPTLS does not provide protection against the key timing attacks , "man in the middle" (MITM). However, the calculation of the hash session added to the mechanism of derivation keys in TLS 1.3, should resolve this issue. The figure below shows the realization of this idea.
There are four primary modes for OPTLS:
- 1-RTT semi-static, where the server has a semi-static , which can also be used to support early application data in a 0-RTT mode;
- 1-RTT non-static, where there is no static , and plays the role of ;
- PSK-DHE, which augments the PSK mode with a DH exchange to achieve forward secrecy.
PSK and PSK-DHE
OPTLS key derivation
Protocol TLS 1.3
The protocol is designed to provide cryptographic means for authenticating the sender (client) - destination (server) , integrity, and encryption of information exchange.
TLS 1.3 Handshake
When the client and the server for the first time establish a connection, they agreed on the version of the protocol, that is selected, cryptographic algorithms,and if necessary authenticate each other, and establish a shared secret. TLS 1.3 supports three basic models of the key exchange:
- Diffie-Hellman (DH)
- Pre-Shared Key (PSK)
- The combination of symmetric encryption and Diffie-Hellman
Basic connection establishment using DH shown at the figure below.
TLS 1.3 supports "0-RTT" mode, in which the client can send early data together with the Certificate and CertificateVerify in the first message thereby to reduce time of establishing the connection. At the figure below you can see message exchange using "0-RTT" mode.
Also, TLS 1.3 supports pre-shared key (PSK) mode, in which client and server have a shared secret (key) and set the connection only if has been established the authenticity of the secret. At the figure below, you can see 2 blocks of message exchanhe between client and server. At first block client and server establish a shared secret. At the second one use it.
Algorithms used in TLS 1.3
- Key exchange and authentication: DH, RSASSA-PKCS1-v1_5, ECDSA, MTI.
- Hash Functions: SHA-256, SHA-384, SHA-512.
- Encryption: RC4, AEAD.
- Perfect Forward Security (PFS)
- Authenticated Encryption with Associated Data (AEAD)
- Pre-Shared Key (PSK)
- Replay attack
- HMAC-based Extract-and-Expand Key Derivation Function or HKDF
- Symmetric encryption
Go to Bibliography of the section "OPTLS and TLS 1.3 protocols".
Goncharov S.A., 2015