some smaller changes: index, censorship, references

Author: sebix

report/censorship.md

@@ -1,10 +1,8 @@
 # Censorship
 
-XXX Feedback - section 9: probably needs a caveat that this just considers a few places - OTF also fund OONI and other related projects in this space
+This section provides a short overview of the regions currently use SNI for censorship purposes, those blocking ECH usage, and countries that may soon implement similar measures.
 
-This section provides an overview of the regions currently use SNI for censorship purposes, those blocking ECH usage, and countries that may soon implement similar measures.
-
-For a comprehensive analysis of internet censorship practices around the globe, see [A Survey of Worldwide Censorship Techniques](https://www.ietf.org/archive/id/draft-irtf-pearg-censorship-10.html).
+For a comprehensive analysis of internet censorship practices around the globe, see [A Survey of Worldwide Censorship Techniques](https://www.ietf.org/archive/id/draft-irtf-pearg-censorship-10.html) and [Open Observatory of Network Interference](https://ooni.org/).
 
 ## Russia
 

report/index.md

@@ -5,22 +5,22 @@ It is part of the [DEfO project - Developing ECH for OpenSSL](https://defo.ie/).
 
 In the DEfO project, task 9.1 deals with:
 
->>>  Deployment Scenarios Analysis: there are many variations in how ECH can be deployed and the varying relationships between the client and server entities involved. There therefore remains a need to map out residual privacy leaks in such scenarios and how to plug those, given the existence of additional privacy mechanisms such as Qname Minimization, Oblivious DNS-over-HTTPS, and MASQUE.
->>> 
->>> This task will accumulate practical documentation (for deployers) and analyses covering these issues. It is clear ECH reduces metadata leakage, but it is not yet clear how censors might react. This task will audit and review the metadata in a properly functioning ECH interaction and explore remaining avenues for de-anonymisation, filtering, blocking and censorship. This touches relevant protocols required in an ECH setup, such as: DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), OCSP (Online Certificate Status Protocol), certificate revocation list (CRLs), etc. We will also focus on “medium scale” web sites such as found on a University campus, smaller hosters or NREN member organisation – CDNs already see the benefits of ECH and have a clear path to deployment, but it is important to enable smaller, but still significant, scale organizations to enjoy the benefits of ECH. The task will result in one report.
+>  Deployment Scenarios Analysis: there are many variations in how ECH can be deployed and the varying relationships between the client and server entities involved. There therefore remains a need to map out residual privacy leaks in such scenarios and how to plug those, given the existence of additional privacy mechanisms such as Qname Minimization, Oblivious DNS-over-HTTPS, and MASQUE.
+>
+> This task will accumulate practical documentation (for deployers) and analyses covering these issues. It is clear ECH reduces metadata leakage, but it is not yet clear how censors might react. This task will audit and review the metadata in a properly functioning ECH interaction and explore remaining avenues for de-anonymisation, filtering, blocking and censorship. This touches relevant protocols required in an ECH setup, such as: DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), OCSP (Online Certificate Status Protocol), certificate revocation list (CRLs), etc. We will also focus on “medium scale” web sites such as found on a University campus, smaller hosters or NREN member organisation – CDNs already see the benefits of ECH and have a clear path to deployment, but it is important to enable smaller, but still significant, scale organizations to enjoy the benefits of ECH. The task will result in one report.
 
 # Overall conclusions and summary of the report
 
 XXX Feedback - the main "success" criteria for ECH might be worth stating, to get deployed and to be an incremental improvement (i.e. it's not a goal that all traffic to a site be ECH protected the day after deployment) - ECH is a thing that'll grow over time (or fail over time)
 XXX Feedback - there are no simple solutions available for this problem, so ECH being a complex solution is inherent - RFC8744 provides lots of background for that
 XXX Feedback - if you've time to write text: no harm to add a para or 3 about the process you followed
 
-While ECH provides privacy improvements over cleartext SNI, the protocol also introduces complexity and new attack vectors primarily centered around DNS manipulation and complex deployment scenarios. The greatest risks arise from the protocol's dependency on DNS infrastructure and as well on the potential for downgrade attacks. Successful ECH deployments require close attention to 
+While ECH provides privacy improvements over cleartext SNI, the protocol also introduces complexity and new attack vectors primarily centered around DNS manipulation and complex deployment scenarios. The greatest risks arise from the protocol's dependency on DNS infrastructure and as well on the potential for downgrade attacks. Successful ECH deployments require close attention to
 
 XXX Feedback - mandatory DNSSEC won't fly, ever
 
-- operational security, 
-- comprehensive monitoring, 
+- operational security,
+- comprehensive monitoring,
 - and potentially mandatory DNSSEC adoption.
 
 From the clients' perspective, the main question is:
@@ -38,15 +38,13 @@ XXX Feedback - centralisation is fair, not sure risk increases is right though
 
 1. ECH depends on multiple protocols and specifications to work together seamlessly. The protocol's fundamental reliance on DNS creates a large attack surface that inherits all DNS security issues.
 In addition to DNS, quite a few other protocols are involved. This creates an even bigger attack surface. The interfaces between protocols are usually interesting targets for attackers. We recommend that the authors of the RFC drafts closely take a look at these edge-case vulnerabilities. The report highlights some of those such as the WKECH interface between DNS zones and CFS/backend servers.
-2. ECH leads to more centralization of the internet: the CDNs will profit. More centralization actually leads to more data being in the hands of only one or just a handful of organisations. Therefore, the risk of de-anonymization by combining and correlating different data sets (ECH configs, DNS recursor query logs (such as [passive DNS](https://www.ietf.org/archive/id/draft-dulaunoy-dnsop-passive-dns-cof-12.html), DNS query traces), [Certificate transparency logs (CTLs)](https://datatracker.ietf.org/doc/rfc6962/)) actually *increases*: any organisation combining these data sets could most probably completely de-anonymize the traffic. 
-3. The complexity of the protocol and the setup costs (in terms of manpower) favor the large players. Smaller players might make mistakes in their setups. 
+2. ECH leads to more centralization of the internet: the CDNs will profit. More centralization actually leads to more data being in the hands of only one or just a handful of organisations. Therefore, the risk of de-anonymization by combining and correlating different data sets (ECH configs, DNS recursor query logs (such as [passive DNS](https://www.ietf.org/archive/id/draft-dulaunoy-dnsop-passive-dns-cof-12.html), DNS query traces), [Certificate transparency logs (CTLs)](https://datatracker.ietf.org/doc/rfc6962/)) actually *increases*: any organisation combining these data sets could most probably completely de-anonymize the traffic.
+3. The complexity of the protocol and the setup costs (in terms of manpower) favor the large players. Smaller players might make mistakes in their setups.
 4. Small and medium size organisations often don't host that many services on one IP address anyway. See "[The web is still small after more than a decade](https://www.researchgate.net/publication/341627684_The_web_is_still_small_after_more_than_a_decade)", Nguyen Phong Hoang, et. al. Therefore the anonymity data set is usually small. Guessing and inferring which hostname a client connected to is trivial in the case that one IP address only hosts one service with one hostname.
 5. Smaller and medium sized organisations won't necessarily profit from protecting the clients' privacy. Exceptions are listed in [incentives](deployment/incentives.md). So why should they bother deploying ECH (and risking downtime)? We have a game-theoretic problem here. Which in turn will only lead to more centralization (see 3.) which will lead to 2.
 
-Nevertheless, apart from these overall considerations, we recommend that organizations wishing to deploy ECH should prioritize 
+Nevertheless, apart from these overall considerations, we recommend that organizations wishing to deploy ECH should prioritize
 
-- security controls around DNS infrastructure, 
-- implement robust monitoring for ECH-related attacks, 
+- security controls around DNS infrastructure,
+- implement robust monitoring for ECH-related attacks,
 - and prepare for the operational complexity introduced by the protocol's multi-layer dependencies.
-
-

report/references.md

@@ -1,3 +1,5 @@
 - [DNS over QUIC - sidn.nl](https://www.sidn.nl/en/news-and-blogs/new-dns-over-quic-protocol-makes-encrypted-dns-traffic-faster-and-more-efficient)
 - [DNS over QUIC - nordvpn.com](https://nordvpn.com/blog/dns-over-quic/)
 - [Encrypted Client Hello (ECH) - Frequently asked questions - support.mozilla.come](https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_how-do-i-enable-ech-in-firefox)
+* Tor protocol overview: http://i3xi5qxvbrngh3g6o7czwjfxwjzigook7zxzjmgwg5b7xnjcn5hzciad.onion/rend-spec/protocol-overview.html
+- Detailed explanation on Tor's non-usage of DoH can be found here: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-dev@lists.torproject.org/thread/6GDO7CYEFIKID7QQCRVYVFNIVETWWWWY/#6ZBFGNSRPWRCEO7PVPSHHVLAOGF7KN3C>