Paper 2020/718

Robust Channels: Handling Unreliable Networks in the Record Layers of QUIC and DTLS 1.3

Marc Fischlin and Felix Günther and Christian Janson

Abstract

The common approach in secure channel protocols is to rely on ciphertexts arriving in-order and to close the connection upon any rogue ciphertext. Cryptographic security models for channels generally reflect such design. This is reasonable when running atop lower-level transport protocols like TCP ensuring in-order delivery, as for example is the case with TLS or SSH. However, channels such as QUIC or DTLS which run over a non-reliable transport protocol like UDP, do not---and in fact cannot---close the connection if packets are lost or arrive in a different order. Those protocols instead have to carefully catch effects arising naturally in unreliable networks, usually by using a sliding-window technique where ciphertexts can be decrypted correctly as long as they are not misplaced too far. To accommodate such handling of unreliable network messages, we introduce a generalized notion of robustness of cryptographic channels. This property can capture unreliable network behavior and guarantees that adversarial tampering cannot hinder ciphertexts that can be decrypted correctly from being accepted. We show that robustness is orthogonal to the common notion of integrity for channels, but together with integrity and chosen-plaintext security it provides a robust analogue of chosen-ciphertext security of channels. We then discuss two particularly interesting targets, namely the packet encryption in the record layer protocols of QUIC and of DTLS 1.3. We show that both protocols achieve the intended level of robust chosen-ciphertext security based on certain properties of their sliding-window techniques and on the underlying AEAD schemes. Notably, the robustness needed in handling unreliable network messages require both record layer protocols to tolerate repeated adversarial forgery attempts, which means we can only establish non-tight security bounds (in terms of AEAD integrity). Our bounds have led the responsible IETF working groups to introduce concrete forgery limits for both protocol drafts.