Change:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.

Discussion:
HTTPS).  Most of these techniques relate to the Server Name Indication (SNI) field, including censoring SNI, Encrypted SNI, or omitted SNI.  Censors can also censor HTTPS content via server <del> certificates. </del> <ins> certificates.  Note that TLS 1.3 acts as a security component of QUIC. </ins> 4.2.3.1. In encrypted connections using TLS, there may be servers that host multiple "virtual servers" at a given network address, and the client <del> will need to specify in the (unencrypted) Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I-D.ietf-tls-sni-encryption I-D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI-based filtering Chai-2019 in some countries. </del> <ins> will need to specify in the Client Hello message which domain name it seeks to connect to (so that the server can respond with the appropriate TLS certificate) using the Server Name Indication (SNI) TLS extension RFC6066.  The Client Hello message is unencrypted for TCP-based TLS.  When using QUIC, the Client Hello message is encrypted but its confidentiality is not effectively protected because the initial encryption keys are derived using a value that is visible on the wire.  Since SNI is often sent in the clear (as are the cert fields sent in response), censors and filtering software can use it (and response cert fields) as a basis for blocking, filtering, or impairment by dropping connections to domains that match prohibited content (e.g., bad.foo.example may be censored while good.foo.example is not) Shbair-2015.  There are undergoing standardization efforts in the TLS Working Group to encrypt SNI I- D.ietf-tls-sni-encryption I-D.ietf-tls-esni and recent research shows promising results in the use of encrypted SNI in the face of SNI- based filtering Chai-2019 in some countries. </ins> Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors,

that only support versions of SSL and not TLS), rendering this method ineffective (see omitsni).  In addition, this technique requires deep packet inspection techniques that can be computationally and <del> infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a </del> <ins> infrastructurally expensive, especially when applied to QUIC where deep packet inspection requires key extraction and decryption of the Client Hello in order to read the SNI.  Improper configuration of an SNI-based block can result in significant overblocking, e.g., when a </ins> second-level domain like populardomain.example is inadvertently blocked.  In the case of encrypted SNI, pressure to censor may transfer to other points of intervention, such as content and

2015, and the governments of China, Egypt, Iran, Qatar, South Korea, Turkey, Turkmenistan, and the UAE all do widespread SNI filtering or blocking OONI-2018 OONI-2019 NA-SK-2019 CitizenLab-2018 Gatlan-2019 <del> Chai-2019 Grover-2019 Singh-2019. </del> <ins> Chai-2019 Grover-2019 Singh-2019.  SNI blocking against QUIC traffic has been first observed in Russia in March 2022 Elmenhorst-2022. </ins> 4.2.3.2.

most cases can be used to infer the domain being visited Patil-2019. Port is useful for allowlisting certain applications. <ins> Combining IP address, port and protocol information found in the transport header, shallow packet inspection can be used by a censor to identify specific TCP or UDP endpoints.  UDP endpoint blocking has been observed in the context of QUIC blocking Elmenhorst-2021. </ins> Trade-offs: header identification is popular due to its simplicity, availability, and robustness.

thousands of IP addresses.  Despite these limitations, IP blocking is extremely effective because the user needs to proxy their traffic through another destination to circumvent this type of <del> identification. </del> <ins> identification.  In addition, IP blocking is effective against all protocols above IP, e.g.  TCP and QUIC. </ins> Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to

used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and <del> censored any connection it could not identify Bock-2020. </del> <ins> censored any connection it could not identify Bock-2020.  In 2022, Russia seemed to have used protocol identification to block most HTTP/3 connections Elmenhorst-2022. </ins> 4.4.

as one of its primary mechanisms of technical censorship Ensafi-2013. Iran has also used Packet Dropping as the mechanisms for throttling SSH Aryan-2012.  These are but two examples of a ubiquitous <del> censorship practice. </del> <ins> censorship practice.  Notably, packet dropping during the handshake or working connection is the only interference technique observed for QUIC traffic so far, e.g. in India, Iran, Russia and Uganda Elmenhorst-2022. </ins> 5.2.3.

the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the <del> connection has been setup, but is vulnerable during setup (See I- D.ietf-quic-transport for more details). </del> <ins> connection has been setup.  While QUIC implements a stateless reset mechanism, such a reset is only accepted by a peer if the packet ends in a previously issued stateless reset token which is hard to guess. During the handshake, QUIC only provides effective protection against off-path attackers but is vulnerable to injection attacks by attackers that have parsed prior packets.  (See I-D.ietf-quic- transport for more details.) </ins> Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it