Draft: draft-irtf-pearg-censorship

Commentary: 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 . 
  , 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 - Just wanted to give this a bump as I close this tab . Let me know if there 's any other work that should be !
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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
scanning, are much more difficult to detect.  Protocol identification
has been used by Iran to identify and throttle SSH traffic to make it
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
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.
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.
Packet injection, generally, refers to a man-in-the-middle (MITM)
network interference technique that spoofs packets in an established
traffic stream.  RST packets are normally used to let one side of TCP
connection know the other side has stopped sending information, and
thus the receiver should close the connection.  RST Packet Injection
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
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).
Packet injection, generally, refers to a man-in-the-middle (MITM)
network interference technique that spoofs packets in an established
traffic stream.  RST packets are normally used to let one side of TCP
connection know the other side has stopped sending information, and
thus the receiver should close the connection.  RST Packet Injection
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
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).
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.
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.
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.