text: QUIC is a secure transport protocol that improves the performance of HTTPS. An initial QUIC handshake that enforces a strict validation of the client's source address requires two round-trips. In this work, we extend QUIC's address validation mechanism by an out-of-band validation token to save one round-trip time during the initial handshake. The proposed token allows sharing an address validation between the QUIC server and trusted entities issuing these tokens. This saves a round-trip time for the address validation. Furthermore, we propose distribution mechanisms for these tokens using DNS resolvers and QUIC connections to other hostnames. Our proposal can save up to 50 of the delay overhead of an initial QUIC handshake. Furthermore, our analytical results indicate that 363.6ms in total can be saved for all connections required to retrieve an average website, if a round-trip time of 90ms is assumed.
  @cite_9: QUIC is a performance-optimized secure transport protocol and a building block of the upcoming HTTP 3 standard. To protect against denial-of-service attacks, QUIC servers need to validate the IP addresses claimed by their clients. So far, the QUIC protocol conducts address validation for each hostname separately using validation tokens. In this work, we review this practice and introduce a new QUIC transport parameter to allow a shared address validation across hostnames. This parameter indicates to the client, that an issued validation token can be used to abbreviate the address validation when connecting to specific other hostnames. Based on trust-relations between real-world hostnames we evaluate the performance benefits of our proposal. Our results suggest that a shared address validation saves a round-trip time on almost 60 of the required handshakes to different hosts during the first loading of an average website. Assuming a typical transatlantic connection with a round-trip time of 90ms. We find that deploying our proposal reduces the delay overhead to establish all required connections for an average website by 142.2ms.
  @cite_22: TLS can resume previous connections via abbreviated resumption handshakes that significantly decrease the delay and save expensive cryptographic operations. For that, cryptographic TLS state from previous connections is reused. TLS version 1.3 recommends to avoid resumption handshakes, and thus the reuse of cryptographic state, when connecting to a different hostname. In this work, we reassess this recommendation, as we find that sharing cryptographic TLS state across hostnames is a common practice on the web. We propose a TLS extension that allows the server to inform the client about TLS state sharing with other hostnames. This information enables the client to efficiently resume TLS sessions across hostnames. Our evaluation indicates that our TLS extension provides huge performance gains for the web. For example, about 58.7 of the 20.24 full TLS handshakes that are required to retrieve an average website on the web can be converted to resumed connection establishments. This yields to a reduction of 44 of the CPU time consumed for TLS connection establishments. Furthermore, our TLS extension accelerates the connection establishment with an average website by up to 30.6 for TLS 1.3. Thus, our proposal significantly reduces the (energy) costs and the delay overhead in the encrypted web.
summary: @cite_9 does not mitigate a stateless retry during the first connection to a member of a group of hostnames that have an exiting trust-relation with each other. Furthermore, these groups are usually rather small @cite_22 , thus only about 60 , validation tokens obtained from a member of such a group can be considered as trustworthy because these members share secret cryptographic state with each other such as a private key of a X.509 certificate.