Short-Lived Forward-Secure Delegation for TLS

Abstract

On today's Internet, combining the end-to-end security of TLS with Content Delivery Networks (CDNs) while ensuring the authenticity of connections results in a challenging delegation problem. When CDN servers provide content, they have to authenticate themselves as the origin server to establish a valid end-to-end TLS connection with the client. In standard TLS, the latter requires access to the secret key of the server. To curb this problem, multiple workarounds exist to realize a delegation of the authentication. In this paper, we present a solution that renders key sharing unnecessary and reduces the need for workarounds. By adapting identity-based signatures to this setting, our solution offers short-lived delegations. Additionally, by enabling forward-security, existing delegations remain valid even if the server's secret key leaks. We provide an implementation of the scheme and discuss integration into a TLS stack. In our evaluation, we show that an efficient implementation incurs less overhead than a typical network round trip. Thereby, we propose an alternative approach to current delegation practices on the web. CCS CONCEPTS • Security and privacy → Web protocol security; Key management.

Secure Middlebox-Assisted QUIC

“…Yet, reasons to break up-or redefine the ends of-endto-end connections have repeatedly been put forward, e.g., to improve performance for the user and/or the network operator. Such optimizations may take different shapes, illustrated by: (a) Content Distribution Networks effectively "cheat" on the origin server certificates to allow for faster content and service delivery to the users from closer-by locations: they do maintain the end-to-end transport but redefine the server-end [1]. (b) Operators of (sub)networks with path properties that are notably different from the "typical" Internet characteristics often apply flavors of connection splitting using Performance Enhancing Proxies (PEPs) to create independent control loops, typically for congestion or error control, in order to speed up connections at the transport layer [2].…”

“…There appears to be general consensus on protecting the end-to-end information exchange from observation and modification inside the network, rendering any sort of transparent middlebox a non-starter 1 . This implies that introducing "innetwork" functions like the above require a conscious decision and consent by either or both endpoints of an end-to-end connection to selectively expose information to specific nodes.…”

“…Such controlled information exposure can basically happen in two ways: (1) In-band of the end-to-end transport connection by explicitly including middleboxes en route either during the initial setup as is the case with explicitly chosen proxies, or by inserting them later as could be achieved with redirection mechanisms, or (2) Out-of-band of the end-to-end transport connection by establishing an independent signaling channel between one or both endpoints and one or more middleboxes. In both cases, the amount of information shared is controllable by the endpoints: in the out-of-band case, this information is explicitly compiled and sent to the middleboxes while, in the in-band case, different levels of encryption can be used to selectively expose information flowing end-to-end.…”