rTLS: Lightweight TLS Session Resumption for Constrained IoT Devices

. The Transport Layer Security (TLS) 1.3 protocol supports a fast zero round-trip time (0-RTT) session resumption mechanism, enabling clients to send data in their ﬁrst ﬂight of messages. This protocol has been designed with Web infrastructure in mind, and requires these ﬁrst messages to not change any state on the server side, as it is susceptible to replay attacks. This is disastrous for common IoT scenarios, where sensors often transmit state-changing data to servers. As bandwidth is a huge concern in the IoT, the ﬁeld stands to beneﬁt signiﬁcantly from an eﬃcient session resumption protocol that does not suﬀer from these limitations. Building on the observation that in IoT scenarios the set of clients is often bounded and fairly static, we propose rTLS (ratchet TLS), an eﬃcient 0-RTT session resumption protocol that dramatically decreases bandwidth overhead, while adding forward secrecy and break-in resilience, and is not susceptible against replay attacks.


Introduction
There are many examples of well-established communication protocols that are able to satisfy contextually-defined requirements and are in use in modern technology.Arguably the most well-known example is the TLS protocol [16].This protocol is widely used in today's Internet, with Web security as its main focus.Recently, this protocol has been gaining traction in the Internet of Things (IoT) domain as well.To better suit the heterogeneous needs present in this domain, new extensions of the TLS protocol are needed, specifically to enable extremely lightweight devices to partake in TLS connections as well.
A typical TLS handshake can require anywhere between 1 and 4 KB of traffic.This is a large amount of traffic overhead for lightweight devices running on battery power, where powering a wireless radio is very costly.Therefore, there is a need to reduce this handshake overhead as much as possible.To aid in reducing bandwidth and latency, TLS 1.3 features a new session resumption protocol capable of transmitting application data already in the first flight of messages.This allows users to quickly reopen a session without having to go through the expensive handshake again.Unfortunately, this resumption protocol is only marginally useful for IoT applications, as it does not allow for data that might change server-sided state, as a result of its weakness against replay attacks.
A second motivator for reducing traffic overhead is that the financial costs of sending this data might become unbearable.For example, it is expected that with 5G Low-Power Wide Area Networks (LPWAN) services such as Long Term Evolution -Machine (communication) (LTE-M) and Narrow Band Internet of Things (NB-IoT), network providers will charge users based on data usage [2,21,9].Moreover, if the cost of setting up a secure connection is tens of times the cost of the payload itself, users might opt not to secure it at all, or implement their own cryptographic protocol, with associated risks.
In a standard TLS setup, servers are not likely to keep state on a client in between sessions, and the protocol is designed with that assumption in mind.In an IoT setting, however, the set of clients is fairly static, and often even known a priori, or traceable through some key infrastructure.Keeping state on these clients between connections can help in reducing the handshake overhead, but this is not yet utilized in TLS 1.3.There is thus a pressing need for IoT-focused TLS extensions that enable secure yet efficient communication with lightweight devices.
In this work, we introduce rTLS, a TLS extension that can authenticate two endpoints and set up a secure connection with minimal additional overhead, given that the client and server have initiated a session in the past.In particular, we introduce an extension to TLS 1.3 that changes the 0-RTT session resumption protocol, reducing overhead compared to the standard protocol, while adding new security features including replay protection, forward secrecy, and break-in protection.We build the protocol on the assumption that servers can store state on clients, with the IoT in mind.We provide equations on the lower bound for traffic overhead of any TLS resumption protocol as well as our proposed extension, and compare it to overhead observed from the OpenSSL [13] implementation of TLS 1.3.We also provide estimations for storage overhead for both client and server.
The remainder of this paper is organized as follows: In Section 2 we briefly discuss the foundations necessary to understand our proposed extension.In Section 5 we discuss related work on lightweight protocols and other TLS extensions.Then, in Section 3 we explain our extension in detail.After that, we evaluate the storage and transmission overhead as well as the security properties in Section 4, after which we conclude this work in Section 6

Preliminaries
This work proposes an improvement of session resumption for the TLS 1.3 protocol, building on Key Derivation Function (KDF)-chains, described in the double ratchet protocol description in the Signal documentation [14].In this section, we briefly discuss the essentials needed to understand our proposed solution.

TLS 1.3
The TLS 1.3 protocol [16] negotiates a secure communication channel (a session) between two parties, typically referred to as client and server.In the most typical scenario, one-way authentication is provided, that is, the server authenticates itself to the client, building on the certificate authority paradigm for key distribution.The protocol also supports session resumption, allowing users to more quickly renegotiate a session, leveraging state data from past sessions between those two users.In this section, we only briefly discuss necessary elements of the protocol.For a more in-depth discussion, we refer to the standard [16].
In order to speed up session negotiation, TLS 1.3 provides several improvements over its predecessor, TLS 1.2 [17].One of the major improvement points is the introduction of 0 Round Trip Time session resumption, or 0-RTT.This allows clients to send application data already in their first message to the server when initiating a session resumption.In the standard, this comes with the caveat that this so-called early data must be idempotent; it should not result in state changes.This is due to 0-RTT handshakes being weak against replay attacks.
The 0-RTT key data is transmitted to the client in a NewSessionTicket message.The server bundles up necessary data for it to continue the session later on, along with a Pre-Shared Key (PSK).The standard describes a structure for NewSessionTicket messages, but not for the tickets which these encapsulate, essentially leaving room for a variety of implementations from e.g.databases with lookup keys to self-encrypted and authenticated messages.In this work, we assume the mechanism first explained in RFC 5077 [10], a solution optimized for the Web, and which requires no server-side state variables on closed sessions.With this approach, the server encrypts the necessary state variables with a secret key, before handing them over to the client.Upon session resumption, the client sends over this encrypted bundle again, and these variables are then decrypted and in turn, can be used to decrypt the early data.

Double Ratchet Algorithm
The Double Ratchet Algorithm [14] is a cryptographic protocol enabling highly secure, asymmetric message exchange.Originally developed for Signal [20], it is now also used in WhatsApp [22].It has received significant cryptographic attention and has been formally verified [5].
At the heart of this protocol lies a KDF-chain, which is a feedback loop where part of its output is fed back into the function as input for the next iteration, while also providing key material for encrypting messages.This creates a ratchetlike construction, because of the one-way nature of the KDF function; new keys can be generated constantly, while one can never retrieve old keys.Therefore, it is also common to refer to this construction as a ratchet.These properties provide ratchets with protection against replay attacks as well as forward secrecy.
A double ratchet is a setup where one "outer" ratchet and one or more "inner" ratchets work together to provide stronger security properties.The outer ratchet uses external entropy from a Diffie-Hellman (DH) handshake as input.
When the outer ratchet is spun (i.e. its KDF function is executed), it generates new input keys for its inner ratchets, thereby resetting them, and providing post-compromise, or break-in, protection.When only the inner ratchet is spun, it generates encryption keys for messages, and uses its own output as input for the next inner KDF execution.The outer ratchet is often called the DH ratchet, while the inner ratchets are called symmetric ratchets.
In the Double Ratchet Algorithm, both parties maintain one DH ratchet and two symmetric ratchets, for outgoing respectively incoming messages.In our work, we use only one symmetric ratchet, as only the client will ever initiate a connection, and the client will thus only need a ratchet for sending, while the server only needs one for receiving.For more details on the double ratchet algorithm, we refer the reader to [14].

ratchet TLS (rTLS)
In this section we describe our proposed extension in detail.Note that it is designed with the goal of making maximal use of existing extensions and utilities available in the TLS suite, and requiring only a minimal amount of change, to increase ease of verification and implementation.
This extension uses a Symmetric Ratchet mechanism to generate the keys involved in session resumption.Additionally, it uses standard TLS mechanisms to provide an outer DH ratchet, providing forward secrecy and break-in protection.The original TLS specification leaves room to enable this elegantly by allowing us to transmit relevant data as a PSK.Then, we can make use of the existing psk key exchange modes extension included in the RFC [16], by specifying a custom exchange mode for ratcheting to let the server know that we want to use this mode for session resumption.As we will see in the following sub-sections, this leads to a minimal number of changes in the protocol itself.
In the remainder of this section, we will first explore the differences between standard TLS handshakes and ratchet-mode handshakes in Sections 3.1 and 3.2, after which we explain the protocol setup and operation in detail in Section 3.3

Initial handshake
Figure 1a depicts the communication pattern of a typical initial handshake for a TLS session making use of our extension.To improve ease of comparison with the RFC [16], we have adopted the same syntax and included the same common extensions.In fact, the communication pattern of this handshake is indistinguishable from a standard TLS handshake.However, we further extend PSK-related extensions to achieve our goals.We denote those elements in the communication pattern that are relevant to this extension in blue.
The inclusion of the psk key exchange modes extension in the first flight of messages signals to the server that the client wants to obtain a session ticket.To create our desired ratchet construction, we need to know what symmetric ciphers should be used during resumption, and also agree on a KDF.In principle, any  secure cipher and KDF can be used for this, however, in an effort to keep the number of required protocol changes to a minimum, we reuse the TLS ciphersuite agreed upon by the client and server, since this already includes apt choices for the required primitives while also guaranteeing that these are supported by the client.Note that the choice of cipher-suite is only definite after the server has replied with its own ServerHello and key share messages.The DH secret key that is established through the key share elements is used to derive all secrets used in TLS, including the PSK resumption secret.This means that whenever the key share extension is included, the subsequently generated PSK resumption secret is derived from a fresh entropy source.The psk key exchange modes extension list of a byte-sized enumerated type, indicating a PSK type.The currently standardized values are 0 for a static PSK and 1 for PSK with (EC)DHE key establishment.We add another value 3 indicating a PSK with key ratcheting.This list of types indicates to the server which PSK types are supported by the client.
After the initial handshake is done, the server sends a NewSessionTicket to the client.While it is allowed for a server to send multiple of these tickets in one session, this is not necessary: session resumption can add entropy when needed and thus provide fresh resumption tickets at a later point in time.Table 2 contains all fields in this structure, as specified in the TLS specification.
The ticket field contains an identifier that the client can later send to the server allowing it to identify the connection and access corresponding stored state.It does not contain an encryption key for resumption.Instead, a resumption master secret is derived as described in the standard: from the ticket nonce and master secret.The extension field must also contain the early data indication extension indicating that the PSK may be used for early data.

Session resumption
Upon resumption of a session using the ratchet PSK mode, the communication pattern once again looks identical to that of a standard TLS 0-RTT session resumption, as can be seen in Figure 1b.The blue text indicates fields that deviate in usage or content in this mode.Firstly, the client chooses whether to include a key share extension.This is not strictly necessary for every resumption, but depends on the desired granularity of break-in resilience; including a DH handshake in every resumption handshake implies that break-in recovery occurs after every resumption, while including these every n resumption handshakes implies break-in recovery after every n handshakes and so on.If the server receives a key share from the client during resumption, it includes a key share extension in its response carrying the necessary DH parameters, otherwise it does not need to include this extension.
The client also includes a psk key exchange modes extension to indicate which PSK mode is used for the pre shared key field.This is mandated by the standard, and the content of this field is identical to the same field in the initial handshake.
Further, the client now includes a pre shared key field containing necessary data for the server to identify the connection as well as the ratchet index currently used by the client.This value is used by the server to determine if it missed any previous connection attempts, and if so, how many times it should ratchet its symmetric ratchet before decrypting the received early data.The pre shared key extension consists of two components: a list of PskIdentity and a list of PskBinderEntry structures.The latter is a list of Hash-Based Message Authentication Code (HMAC) values that authenticate the ClientHello up-to-and-including the list of PskIdentity entries, while the former consists of an identity and obfuscated ticket age value.The ticket age is further described in the standard and not important to this work, so we refrain from discussing it in detail.The identity value is defined as an opaque value in the standard, allowing us to populate it with a connection ID received from the server during the initial handshake (4 bytes), and the 1-byte ratchet index indicating the index of the symmetric KDF chain (after having derived the latest resumption master secret).
Every time the client initiates a resumption handshake with the server, the resumption master secret is ratcheted, going one step further down the KDF chain.From the ratcheted resumption master secret an early traffic secret is derived, which is used to encrypt the early application data sent by the client.
Once the server has received a ClientHello with the necessary extensions for a ratchet-mode resumption, it can find the correct ratchet based on the connection ID obtained from the received identity field.It then spins this ratchet until the number of spins equals the ratchet index in the identity field.
When the resumption handshake includes the key share extension, i.e. it initiates a DH handshake, the resulting shared secret is used to derive all subsequent secrets for a TLS session, as specified in its key schedule [16].Notably, when a resumption secret already exists, the newly derived master secret depends on both the existing resumption secret and the DH shared secret.From this new master secret a new resumption master secret is then generated for use in future resumptions, and the ratchet index must be reset to 0. This construction ensures that an adversary cannot attack the protocol by replacing the client's shared key field with its own parameters, as the adversary will not have access to the existing resumption and therefore cannot derive a correct next resumption secret.
We only reserve 1 byte for the ratchet index because we expect it to be reset to 0 well before 255 communication attempts have been made.Nevertheless, we add the requirement that if the ratchet index is 255, both parties must delete their PSK and negotiate a new PSK after a standard handshake.

Double Ratchet setup and operation
Next, we summarize the extra steps needed for both the initial-and resumption handshakes in a step-by-step fashion.

Initial Handshake
The initial handshake is largely unmodified, but some special steps have to be taken by both the client and the server.

ID generation:
The server generates a globally unique connection ID.This ID is transmitted to the client in the NewSessionTicket; 2. Symmetric ratchet initialization: The client and server initialize the ratchet index variable to 0. The symmetric ratchet key is the resumption master secret.3. Persistent state storage: Both client and server store their state variables for anticipated session resumptions; Resumption Below we describe the extra steps needed for a typical session resumption.A DH exchange may take place, but we do not consider that as an extra step -the TLS standard already accommodates for this.Client 1. Ratchet step: The client ratchets its symmetric ratchet before the resumption master secret is used to derive any other secret.The early-data secret is thus derived from the ratcheted master secret; 2. PSK exchange: During the handshake, the client sends its ratchet index and connection ID to the server, as part of the pre shared key; Server 1. Access state: The server receives a 0-RTT resumption, and after having verified the pre shared key's HMAC field, finds the relevant state variables using the received connection ID as a key (e.g. in a hash map); 2. Replay condition The server ensures that i s < i c where i s and i c are the server respectively received client ratchet indices for this connection.3. Ratchet step: The server spins the symmetric ratchet i c − i s times where i c is the received ratchet index in pre shared key and i s its own ratchet index.The early data encryption key is derived from the new state of the sym.ratchet; Both 1. Reset ratchet index: If a DH exchange was performed during the resumption handshake, then the client and server reset their ratchet index to 0. 2. Persistent state storage: Both the client and server store their state variables for future session resumptions;

Ratchet state variables
This extension expects both the client and server to maintain some state for each connection.This state consists of the following data: 1. Mapping: a connection ID → ratchet mapping, to identify which ratchet belongs to which connection; 2. Resumption Master Secret: This is used to derive the keys used for encryption, upon next resumption (32 bytes); 3. Ratchet Index: To indicate the number of ratchet steps that occured since the last DH exchange (1 byte);

Security evaluation
In this section, we discuss the security properties of the proposed protocol extension.We only discuss the resumption handshake, as the initial handshake is left untouched by this extension.Firstly, note that because the NewSessionTicket message gets transmitted by the server as application data after the initial handshake, it is by definition authenticated, verified, and confidential.Since we require both the client and server to securely store their state variables, we can further assume that any keys derived from the resumption master secret can only be computed by the client and server.

Replay attacks
We divide replay scenarios into two groups: those that occur within one DH handshake period, and those that span across at least one DH handshake.In the former, when an attacker replays a session resumption handshake m without any modifications, the server will reject m and not process the associated early data, as the replay condition i s < i c will be violated.c i cannot be forged either, as it is protected by an HMAC and we assume security of the cryptographic hash function, and secrecy of the HMAC keys.In the second group, an attacker records n different resumption message m 0 , . . ., m n−1 where n is the DH handshake frequency.Let c 0 , . . ., c n−1 be the corresponding ratchet indices.Now, the attacker is certain that at least one DH handshake has been performed since m 0 was sent, and the next message m n will have ratchet index c n = c 0 .As the ratchet indices are equal, one could attempt to bypass the replay condition check.However, the resumption master keys for m 0 and m 1 are different, and therefore the HMAC keys used for the PSK binder fields are different.Thus, when an attacker sends m 0 to a server after n resumptions have passed, the HMAC validation will fail before i c gets checked, and m 0 will thus be rejected.
Forward Secrecy The 0-RTT resumption also enjoys forward secrecy, as we only store the last resumption key.After every attempt, a key is derived using a cryptographic hash function, so it is not feasible for an adversary to compute past keys based on a compromised resumption key.
Break-in protection Additionally, the protocol enjoys break-in protection, proportional to the frequency of DH exchanges in resumption handshakes.These exchanges effectively function as the DH ratchet in the Signal protocol.the shared secret resulting from such a DH exchange is used as key input for the key derivation function, adding new entropy to it.This means that if an adversary compromises one of the endpoints at some moment in time, and extracts resumption keys from it, they will not be able to decrypt any messages after the next DH exchange has occurred; they do not possess the required shared secret.

Traffic Overhead estimation
Initial handshake The number of bytes transmitted by each side during the initial handshake is unchanged -the one addition to the protocol just defines an extra value for an enumerated field (psk key exchange modes).After the handshake is done, the server transmits a NewSessionTicket message to the client.As this is part of the extension setup, in this context we consider this as part of the initial handshake; without it, resumption would not be possible.The structure and size of a minimal NewSessionTicket message is displayed in Table 2.The client does not need to send any reply to this message.We set the size of the ID field and nonce field to 4 respectively 32 bytes.Therefore, compared to no session resumption at all, minimal overhead is 14 + 4 + 32 = 50 bytes.Compared to a session ticket in standard TLS 1.3, which is typically in the hundreds of bytes, this is a significant improvement.Resumption handshake The resumption handshake will ideally be performed much more often than the initial handshake, thus it is important that the traffic overhead for this handshake is as small as possible.The fixed cost for any resumption handshake consists of boilerplate parts of the handshake that cannot be eliminated without rigorous change to the protocol.In the following, we write client and server as c and s, respectively.We map symbols to every message element in the resumption handshake in Table 3, where x can be either c or s to indicate the message sender.We refer to the size of message X as |X|.
We define the fixed cost C of any 0-RTT resumption handshake as: This cost is not a fixed number of bytes, but rather is not negotiable; any PSK extension will have to include these elements, and their size is independent of the actual PSK mode.The total cost of a minimal resumption handshake where the server does not respond with any early data is C + |psk c | + |psk s |.Note that ks c and ks s are not required for a minimal handshake.Conform to the standard, pks s is defined as a 2-byte value representing an identity index in psk c , and is wrapped in a 4-byte TLS extension structure.ks c is more complex however, and we write the full layout in Table 4.When a DH exchange is included, we will have to add the size of the ks c and ks s elements.The size of ks c is of variable length depending on the number of supported DH groups the client advertises.Each key share entry takes up 4 + l bytes where l is the size of the supported group.The smallest supported group is X25519 with a 32-byte field, while the largest is P-521 with 132 bytes.ks c also reserves 2 bytes to denote the number of listed groups, therefore ks c = 6 + l.The server replies with a single key share entry, thus ks s = 4 + l.As with any TLS extension, these entries are wrapped in an extension structure with a 4-byte type field.The total cost of a resumption with DH exchange is thus If we take into account a key share every n messages, we arrive at the final equation for the total average cost c t : where β is the hash digest size, l the elliptic curve coordinate length, n the DH handshake rate, and C the fixed cost. Figure 2 shows the average overhead versus the key exchange frequency, for various common cipher suites.
Giving an exact value for C is somewhat difficult: multiple fields in H c , H s , and ee can vary a lot in length, depending on the supported cipher suites and provided extensions among other things.Instead, we count the minimum size for these fields as they are defined in the standard, thereby giving a lower bound for C. Note that in practice, a handshake with so few extensions is not useful for overhead minimization, as more round-trips will be needed to establish necessary parameters such as the cipher suite.Moreover, it leaves out extensions meant to increase overall security.Minimal sizes, including all headers, for H c and H s are 50 and 48 bytes, respectively.ed c and eed both require 2 and 4 bytes.pex is at least 3 + m bytes in size, where m is the number of supported modes (at least 1).ee is at least 6 bytes in size, but may vary a lot, depending on the supported extensions.The length of f is determined by the chosen hash function.The record layer headers are 5 bytes in size.With one PSK key exchange mode and the SHA-256 hash function, the total cost of C is then at least 193 bytes.Therefore, the lower bound on transmission overhead of a resumption handshake with our extension is 251 bytes without, or 333 bytes with a key exchange.

Storage overhead estimation
Both the client and server need to store some state variables in between sessions.This differs from the standard session resumption protocol where only the client stores the PSK.The client needs to securely store the secret KDF key (depends on digest size), as well as its connection ID (4 bytes) and the ratchet index (1 byte).The client thus needs to store 37 bytes if SHA-256 is used.
The server needs to store the same amount of state, but for every client that it shares a ratchet for resumption with.This can be done through e.g. a hash map using the connection ID as a key, and a structure containing the other state variables as value.If state is being kept for the maximum amount of clients of 2 32 (with a 4-byte connection ID), this amounts to roughly 270GB worth of data.

Overhead comparison with TLS 1.3
Based on measurements performed on OpenSSL [13], a standard PSK in TLS 1.3 adds 571 and 603 bytes of overhead, when SHA-256 respectively SHA-384 is used.In Table 5 we compare the overhead of rTLS for various values of n to that of a standard TLS 1.3 PSK.We use a higher value of C, obtained from handshake measurements in OpenSSL, which includes a minimal number of extensions by default, and acts as an indicative value that represents a lightweight use case.In this table, the values are computed using the smallest allowed hash function (SHA-256) and curve (X25519).As can be seen, a rTLS PSK requires only roughly 11% of the traffic overhead compared to a standard TLS PSK, and can be expected to reduce the total amount of transmitted data roughly by half.

Related Work
There exist ample communication security protocols aimed at embedded devices [1].We look at the TLS protocol and its variants, specifically those that are relevant to the usage of this protocol in embedded environments.
Initially developed for Web security, TLS is now gaining traction in the IoT world, partly due to widely available libraries and broad support in software relevant to IoT.For example, many Message Queuing Telemetry Transport (MQTT) brokers support TLS as a security layer.
While this is fine for most devices (mostly upwards from class 1 in the Internet Engineering Task Force (IETF) classification [4]), it becomes problematic when working with class 0 or low-end class 1 devices, as they do not possess the capability to maintain TLS connections or can simply not afford it due to resource constraints (e.g.due to a power budget).To address this, several optimizations have been proposed over the years.One of the first was Sizzle [7], which is an implementation of the Secure Socket Layer (SSL) protocol, and is capable of running on extremely constrained devices with only tens of kilobytes of memory.While the authors showed that heavyweight cryptographic operations required for the protocol to function were certainly possible on heavily constrained devices, they did not attempt to reduce the amount of transmitted data.
Datagram Transport Layer Security (DTLS) [18] modifies the TLS protocol to work over User Datagram Protocol (UDP), while retaining most of the security guarantees provided by TLS.This reduces the data overhead and latency somewhat.There exist multiple open-source implementations [23], and several works exist detailing extremely lightweight implementations [3,11].In these works, lightweight mostly pertains to computational and memory cost, while transmission overhead is either not addressed or addressed to a much lesser degree.Other approaches have been taken as well, such as [15], compressing DTLS messages to fit into 6LowPAN frames.
Several extensions for TLS have been proposed that also bring the potential to lower message overhead.The TLS Cached Info specification [19] allows clients to store server certificates and certificate requests, making it possible to leave these out in future handshakes.The TLS Raw Public Key extension [24] allows clients and servers to authenticate each other through public keys, instead of X.509 certificates.This can significantly reduce the handshake size.This method does require an out-of-band means of verifying public keys, which might very well be possible in a controlled environment such as a factory.Another promising adaptation of TLS that might lower the size overhead of TLS significantly is the Compact Transport Layer Security (CTLS) IETF draft [6].In this draft, the authors propose optimizing the TLS protocol for size by eliminating redundancy where possible and making aggressive use of space-optimization techniques such as variable-length integers.The result is isomorphic to TLS, but not interoperable.
TLS is also proposed as the default mechanism to secure connections in the QUIC protocol, a network protocol building on UDP that provides advanced features such as multiplexing and authenticated encryption of its data by default.
Session resumption in TLS 1.3 has been subject to debate, as it is vulnerable to replay attacks and provides no forward secrecy [16].While for a Web environment, there exists some justification for these design choices, for an IoT environment where short conversations with short messages are the norm, this is less than ideal, as it effectively removes the possibility to optimize overhead through use of the session resumption protocol.None of the extensions discussed in this section address session resumption, which means that this is an open issue we think has significant potential for minimizing protocol overhead, when designed carefully.
At the time of writing, National Institute of Standards and Technology (NIST) is hosting an ongoing competition for lightweight cryptographic primitives [12].Many of the candidates specifically target very short messages.Once the candidates have received sufficient cryptanalytic attention, these can become valuable tools in future lightweight communication protocols, as well as potentially helping protocols such as TLS adapt to constrained devices.
In [8], Hall-Andersen et al. acknowledge the complexity of TLS and propose nQUIC as a lightweight, less complex alternative to QUIC's default TLS configuration.Their experiments show a significant reduction in bandwidth compared to TLS.

Conclusion
In this work, we proposed an IoT-friendly and standard-compliant adaption of the TLS 1.3 0-RTT session resumption protocol.We first argued that in order to be applicable to IoT, replay resistance is a necessary property, as lightweight sensor devices are much more likely to transmit data that will change server state.
Building from the observation that in IoT scenarios the group of possible clients for a server changes relatively slowly and is typically much smaller than possible clients for a Web server, we argued that it is reasonable to require a server to keep some state variables for each of its clients.We then took inspiration from the Double Ratchet algorithm to design a 0-RTT resumption protocol that fits neatly into the existing message structure, and makes use of existing functionality where possible.In our extension, the PSK utilizes a ratchet construction, which provides replay protection as well as forward secrecy and break-in resilience to early data transmitted in a 0-RTT handshake.The introduction of these properties in the 0-RTT subprotocol is a step towards making TLS suitable for IoT scenarios.
We estimated a lower bound of 193 bytes on traffic overhead for any 0-RTT resumption protocol in TLS 1.3, and then showed that our protocol requires at least 251 bytes of traffic overhead.Compared to the standard session resumption overhead of roughly 764 bytes, this is a significant improvement.
In future work, we aim to further reduce the transmission overhead by exploring different opportunities, such as replacing the original message structure for resumption altogether, thereby reducing the fixed cost.
The communication pattern of the resumption handshake.

Fig. 1 :
Fig.1: Figure1aand 1b depict the initial respectively resumption handshake communication patterns.+ denotes an extension, * denotes an optional or situation-dependent component while {} and [] denote encryption with a derivation of the handshake or application secret, respectively.Modifications from the original handshakes are printed in blue.
As we only send one identity and binder, The size of psk c becomes |psk c | = 15 + α + β, where α denotes the size of the identity field, and β the size of the binder HMAC.The identifier field P SKID can be written as P SKID = ID||i where ID is the identifier received in the session ticket during the initial handshake and i is the symmetric KDF chain index.Now, |P SKID| = |ID| + 1 = 5.The exact value of β depends on the chosen HMAC function, which is usually either Secure Hash Algorithm (SHA)-256 (32 bytes) or SHA-384 (48 bytes).The complete traffic cost c 1 for session resumption can thus be written as c = |psk s | + |psk c | + C = 26 + β + C, and is 58 + C if SHA-256 is chosen.

Table 1 :
Layout of the NewSessionTicket structure.

Table 2 :
The message structure and size of a minimal NewSessionTicket message.Here |ID| refers to the identifier length and |N | to the size of the nonce.

Table 3 :
Symbol definitions for message elements, where x ∈ {c, s} refers to the message sender (client resp.server).

Table 4 :
Layout of the pre shared key structure and its sub-structures, when sent by a client.

Table 5 :
A comparison between rTLS session resumption and openSSL standard session resumption