Change:
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!

Discussion:
content deemed as morally or commercially harmful to companies or consumers in some jurisdictions SIDN2020. <del> There are typically three types of blocklist elements: Keyword, domain name, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP, whereas IP blocking tends to take place using IP addresses in IPv4/ IPv6 headers.  The mechanisms for building up these blocklists vary. Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight-2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking.  Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </del> <ins> There are typically a few types of blocklist elements: Keyword, domain name, protocol, or Internet Protocol (IP) address.  Keyword and domain name blocking take place at the application level, e.g., HTTP; protocol blocking often occurs using Deep Packet Inspection to identify a forbidden protocol; IP blocking tends to take place using IP addresses in IPv4/IPv6 headers.  Some censors also use the presence of certain keywords to enable more aggressive blocklists Rambert-2021 or to be more permissive with content Knockel-2021. The mechanisms for building up these blocklists vary.  Censors can purchase from private industry "content control" software, such as SmartFilter, which lets censors filter traffic from broad categories they would like to block, such as gambling or pornography Knight- 2005.  In these cases, these private services attempt to categorize every semi-questionable website as to allow for meta-tag blocking. Similarly, they tune real-time content heuristic systems to map their assessments onto categories of objectionable content. </ins> Countries that are more interested in retaining specific political control typically have ministries or organizations that maintain

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

political opinions in relation to the 2019 Hong Kong protests Victor- 2019.  See also discon. <del> 4.2.4. </del> <ins> 4.2.5. </ins> DPI (deep packet inspection) technically is any kind of packet analysis beyond IP address and port number and has become

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.

traffic of censorship circumvention tools appear indistinguishable from other kinds of traffic Tor-2020. <ins> Censors have also used protocol identification in the past in an 'allowlist' filtering capacity, such as by only allowing specific, pre-vetted protocols to be used and blocking any unrecognized protocols Bock-2020.  These protocol filtering approaches can also lead to over-blocking if the allowed lists of protocols is too small or incomplete, but can be cheap to implement, as many standard 'allowed' protocols are simple to identify (such as HTTP). </ins> Empirical Examples: Protocol identification can be easy to detect if it is conducted in real time and only a particular protocol is blocked, but some types of protocol identification, like active

unusable Anonymous-2007 and by China to identify and block Tor relays Winter-2012.  Protocol identification has also been used for traffic management, such as the 2007 case where Comcast in the United States <del> used RST injection to interrupt BitTorrent Traffic Winter-2012. </del> <ins> 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 censored any connection it could not identify Bock-2020. 4.4. Another feature of some modern censorship systems is residual censorship, a punitive form of censorship whereby after a censor disrupts a forbidden connection, the censor continues to target subsequent connections, even if they are innocuous Bock-2021. Residual censorship can take many forms and often relies on the methods of technical interference described in the next section. An important facet of residual censorship is precisely what the censor continues to block after censorship is initially triggered. There are three common options available to an adversary: 2-tuple (client IP, server IP), 3-tuple (client IP, server IP+port), or 4-tuple (client IP+port, server IP+port).  Future connections that match the tuple of information the censor records will be disrupted Bock-2021. Residual censorship can sometimes be difficult to identify and can often complicate censorship measurement. Trade-offs: The impact of residual censorship is to provide users with further discouragement from trying to access forbidden content, though it is not clear how successful it is at accomplishing this. Empirical Examples: China has used 3-tuple residual censorship in conjunction with their HTTP censorship for years and researchers have reported seeing similar residual censorship for HTTPS.  China seems to use a mix of 3-tuple and 4-tuple residual censorship for their censorship of HTTPS with ESNI.  Some censors that perform censorship via packet dropping often accidentally implement 4-tuple residual censorship, including Iran and Kazakhstan Bock-2021. </ins> 5.

is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped <del> the connection, the session is terminated.  QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (See I-D.ietf-quic-transport for more details). </del> <ins> the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (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

about the TCP stream they are injecting into, they can simply enumerate all ~70000 possible windows; this is particularly useful for interrupting encrypted/obfuscated protocols such as SSH or Tor <del> Gilad.  RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </del> <ins> Gilad.  Some censorship evasion systems work by trying to confuse the censor into tracking incorrect information, rendering their RST Packet Injection useless Khattak-2013, Wang-2017, Li-2017, Bock-2019, Wang-2020. RST Packet Injection relies on a stateful network, making it useless against UDP connections.  RST Packet Injection is among the most popular censorship techniques used today given its versatile nature and effectiveness against all types of TCP traffic.  Recent research shows that a TCP RST packet injection attack can even work in the case of an off-path attacker Cao-2016. </ins> Empirical Examples: RST Packet Injection, as mentioned above, is most often paired with identification techniques that require splitting,

India was the country that saw the largest number of internet shutdowns per year in 2016 and 2017 Dada-2017. <ins> 5.3.3. Often, censors implement multiple techniques in tandem, creating "censorship in depth".  Censorship in depth can take many forms; some censors block the same content through multiple techniques (such as blocking a domain by DNS, IP blocking, and HTTP simultaneously), some deploy parallel systems to improve censorship reliability (such as deploying multiple different censorship systems to block the same domain), and others can use complimentary systems to limit evasion (such as by blocking unwanted protocols entirely, forcing users to use other filtered protocols). Trade-offs: Censorship in depth can be attractive for censors to deploy, as it offers additional guarantees about censorship: even if someone evades one type of censorship, they may still be blocked by another.  The main drawback to this approach is the cost to initial deployment, as it requires the system to deploy multiple censorship systems in tandem. Empirical Examples: Censorship in depth is present in many large censoring nation states today.  Researchers have observed China has deployed significant censorship in depth, often censoring the same resource across multiple protocols Chai-2019, Bock-2020b or deploying additional censorship systems to censor the same content and protocol Bock-2021b.  Iran also has deployed a complimentary protocol filter to limit which protocols can be used on certain ports, forcing users to rely on protocols their censorship system can filter Bock-2020. </ins> 6. 6.1.