Change:
4.2.3. <ins> Similar to HTTP, censors have deployed a variety of techniques towards censoring Transport Layer Security (TLS) (and by extension 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 certificates. 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 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. Domain fronting has been one popular way to avoid identification by censors Fifield-2015.  To avoid identification by censors, applications using domain fronting put a different domain name in the SNI extension than in the Host: header, which is protected by HTTPS. The visible SNI would indicate an unblocked domain, while the blocked domain remains hidden in the encrypted application header.  Some encrypted messaging services relied on domain fronting to enable their provision in countries employing SNI-based filtering.  These services used the cover provided by domains for which blocking at the domain level would be undesirable to hide their true domain names. However, the companies holding the most popular domains have since reconfigured their software to prevent this practice.  It may be possible to achieve similar results using potential future options to encrypt SNI. Tradeoffs: Some clients do not send the SNI extension (e.g., clients 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 infrastructurally expensive and improper configuration of an SNI- based block can result in significant overblocking, e.g., when a 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 application providers. Empirical Examples: There are many examples of security firms that offer SNI-based filtering products Trustwave-2015 Sophos-2015 Shbair- 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 Chai-2019 Grover-2019 Singh-2019. 4.2.3.2. With the data leakage present with the SNI field, a natural response is to encrypt it, which is forthcoming in TLS 1.3 with Encrypted Client Hello (ECH).  Prior to ECH, the Encrypted SNI (ESNI) extension is available to prevent the data leakage caused by SNI, which encrypts only the SNI field.  Unfortunately, censors can target connections that use the ESNI extension specifically for censorship. This guarantees overblocking for the censor, but can be worth the cost if ESNI is not yet widely deployed within the country. Encrypted Client Hello (ECH) is the emerging standard for protecting the entire TLS Client Hello, but it is not yet widely deployed. Tradeoffs: The cost to censoring Encrypted SNI (ESNI) is significantly higher than SNI to a censor, as the censor can no longer target censorship to specific domains and guarantees over- blocking.  In these cases, the censor uses the over-blocking to discourage the use of ESNI entirely. Empirical Examples: In 2020, China began censoring all uses of Encrypted ESNI (ESNI) Bock-2020b, even for innocuous connections. The censorship mechanism for China's ESNI censorship differs from how China censors SNI-based connections, suggesting that new middleboxes were deployed specifically to target ESNI connections. 4.2.3.3. Researchers have observed that some clients omit the SNI extension entirely.  This omitted-SNI approach limits the information available to a censor.  Like with ESNI, censors can choose to block connections that omit the SNI, though this too risks over-blocking. Tradeoffs: The approach of censoring all connections that omit the SNI field is guaranteed to over-block, though connections that omit the SNI field should be relatively rare in the wild. Empirical Examples: In the past, researchers have observed censors in Russia blocking connections that omit the SNI field Bock-2020b. 4.2.3.4. During the TLS handshake after the TLS Client Hello, the server will respond with the TLS certificate.  This certificate also contains the domain the client is trying to access, creating another avenue that censors can use to perform censorship.  This technique will not work in TLS 1.3, as the certificate will be encrypted. Tradeoffs: Censoring based on the server certificate requires deep packet inspection techniques that can be more computationally expensive compared to other methods.  Additionally, the certificate is sent later in the TLS Handshake compared to the SNI field, forcing the censor to track the connection for longer. Empirical Examples: Researchers have observed the Reliance Jio ISP in India using certificate response fields to censor connections Satija- 2021. 4.2.4. </ins> Many governments pressure content providers to censor themselves, or provide the legal framework within which content distributors are incentivized to follow the content restriction preferences of agents

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!