Change:
could use DPI to sort and categorically search gathered traffic using technologies such as NarusInsight Hepting-2011. <del> 4.2.4.1. In encrypted connections using Transport Layer Security (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. 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.  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. </del> 4.3. 4.3.1.

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!