Merge pull request #11 from certtools/main

publish it

Author: aaronkaplan

.github/workflows/mkdocs.yml

@@ -1,4 +1,4 @@
-# SPDX-FileCopyrightText: 2025 Sebastian Wagner
+# SPDX-FileCopyrightText: 2025 Sebastian Wagner, Aaron Kaplan
 # SPDX-License-Identifier: AGPL-3.0-or-later
 
 name: "Build and publish documentation"

ai-gen-report/README.md

@@ -1,8 +1,13 @@
 # AI generated "reports"
 
 For these texts, we used different models to operate on the usualy RFC drafts and "analyse" the reports.
+
 *NOTE WELL* these AI generated reports are merely an *inspiration* for us so that we think about additional possibilities and get creative.
 We do not automatically trust these reports.
+Nor did we use the texts.
+
+It's rather a cross check if we covered the main ideas.
+
 
 
 

mkdocs.yml

@@ -15,7 +15,6 @@ nav:
       - Complexity: weaknesses/complexity.md
       - DNS: weaknesses/dns.md
       - WKECH: weaknesses/wkech.md
-      - Others: weaknesses/others.md
   - Clients considerations: 
       - Browsers: clients/browsers.md
       - IoT and Libraries: clients/iot_and_libs.md

report/index.md

@@ -1,9 +1,9 @@
 ---
-title: Remaining weaknesses in ECH (Encrypted Client Hello)
+title: Remaining potential weaknesses in ECH (Encrypted Client Hello)
 author:
   - L. Aaron Kaplan
   - Sebastian Wagner
-date: 2025-06-26
+date: 2025-06-30
 keywords:
   - ECH
   - Encrypted Client Hello
@@ -27,37 +27,50 @@ In the DEfO project, task 9.1 deals with:
 >
 > 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
+# Methodology
 
-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
-XXX Feedback - I'd recommend setting the scene in the very first paragraph, e.g. saying that this report is deliberately taking an "outside" or "skeptical" view as that's a good process for finding issues.
+The authors read the RFCs and -Drafts and brainstormed after each how we might break or downgrade the security/privacy promises. In addition, we gave a presentation on the topic in front of approx. 30 IT security professionals in order to elicit feedback and further ideas on how to attack the protocols.
+The result is this report.
 
-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
+# How to read this report
+
+This report intentionally takes a skeptical perspective. Not in order to criticize ECH or the approach but rather to challenge the protocol authors, implementers and deployments to think about certain aspects we mention in the report.
+This "skeptical"/outside view helps to ask hard questions and identify potential issues which might have been overlooked.
+
+By releasing this report we aim to improve future versions.
+
+It is clear that - given such widely used code  and protocol stacks as with HTTP/HTTPS, changing things is very hard. ECH tries to achieve the maximum possible, given lots of constraints by the protocol landscape, implementors, etc. Hence, ECH has to live with all the legacy issues. It's probably not possible to find a quick, elegant and 100% compatible solution for the problem which ECH is trying to address.
+ECH being a complex solution is inherent - RFC8744 provides lots of background for these matters.
+
+Finally, we acknowledge that ECH is an incremental update step and we assume there will be an incremental roll-out of ECH globally. This has multiple implications:
+1) every deployment will protect clients a bit more ("herd-immunity" principle)
+2) weaknesses in ECH highlighted in the report do not necessarily affect all deployments (there will be variations)
+3) ECH will grow over time and add privacy over time. It's not a binary turning privacy on or off situation. 
+
+ECH will be measured by its provisioning of privacy after all.
 
-XXX Feedback - mandatory DNSSEC won't fly, ever
+With these things being said, the report will skeptically look at ECH.
+
+
+# Overall conclusions and summary of the report
+
+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
 
 - operational security,
 - comprehensive monitoring,
-- and potentially mandatory DNSSEC adoption.
+- and a secure DNS (signed zones, detectability of tampering with DNS answers, etc.)
 
 From the clients' perspective, the main question is:
 
-XXX Feedback - resursive selection is a thing, but not so much an ECH thing maybe?
-XXX Feedback - client downgreade is a fair point, maybe worth distinguishing client TLS library (somewhat under our control in DEfO) or client app
-
 - which DoH/DoT recursive servers can one use? Are they even reachable from within the country of the client? Or are they blocked, re-directed or manipulated? Untrusted DoH/DoT recursive servers pose a security as well as a privacy problem.
-- Can the client detect downgrade attacks and how does it deal with them? The RFC standard is a big vague here (SHOULD vs. MUST) ("...the client SHOULD abandon its attempt to reach the service"[^2])
+Depending on the trust the client may place into the recursive DNS server, it might get correct or incorrect answers and hence be able to reach ECH enabled servers or a mere look-alike middle-man server. It's debatable if this is an issue that ECH can address. Probably not. However, we believe it's worth noting. 
+- Can the client detect downgrade attacks and how does it deal with them? The RFC standard is a big vague here (SHOULD vs. MUST) ("...the client SHOULD abandon its attempt to reach the service"[^2]). We recommend looking at this issue when implementing ECH in TLS libraries.
 
 In addition, the authors of this report see two major concerns with ECH deployments for the internet as a whole:
 
-XXX Feedback - inherits all DNS issues seems overstated - e.g. zone transfer
-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.
+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 many of DNS's 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[^3], DNS query traces), Certificate transparency logs (CTLs)[^4]) actually *increases*: any organisation combining these data sets could most probably completely de-anonymize the traffic.
+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[^3], DNS query traces), Certificate transparency logs (CTLs)[^4]) actually *increases*: any organisation combining these data sets could most probably completely de-anonymize the traffic. The more of these datasets are in the hand of fewer organisations, the higher the risk these datasets can be combined.
 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[^5]", 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.

report/index.md.dist

@@ -1,10 +1,15 @@
 # Overall concerns with complexity
 
-This concern is that high complexity is needed for solving the task which ECH tries to address *in the given protocol landscape* (i.e. to keep compatibility with the existing protocol stack).
-However, this leads to:
+The authors of this report want to emphasize that for solving the particular
+problem which ECH tries to solve, we don't currently see an easier solution.
+Hence, the ECH protocol achieves its goal. However, this comes at the cost of
+added complexity. This complexity might come to haunt us later on.
+
+Higher complexity leads to:
 
-* complexity in configuring it properly -> things go wrong easily
-* weaknesses between protocol layers: the interface between protocols is often the weak spot
-* design omissions: there might be more hidden oversights in the design of the complex interplay between the protocols
+* issues and mistakes in configuring it properly -> things go wrong easily
+* weaknesses between protocol layers: with many protocols interacting with each other, the interface between protocols is often the weak spot
+* potential design omissions: there might be more hidden oversights in the design of the complex interplay between the protocols
 
-The authors of the report acknowledge that solving the issue is not an easy task and no easier methods are known.
+The authors of this report acknowledge that solving the issue is not an easy task and no easier methods are known.
+ECH as a protocol does its job at solving a particular issue. But at the cost of complexity. 

report/weaknesses/complexity.md

@@ -1,6 +1,16 @@
-# Downgrading
+# Downgrade attacks
 
-XXX Feedback - 7.2: arguable - incremental improvement shouldn't be ignored
+If a network operator does not want to allow the typical DoH servers, he/she essentially only has the option to block those. However, since clients will still try to use DNS over classical means then, the attacker has the possibility to promote his/her tampered recursive DNS server.
+Essentially this results in a downgrade attack on ECH as well, since DNS is a precondition to establishing a session with an ECH server.
+
+Of course, when the setup is working, the incremental security upgrade that ECH gives (according to what it was intended to do), is not to be dismissed.
+
+# Mandated use of DoH
+
+On the other hand, if we require DoH/DoT, we essentially play into the hands of those who centralize recursive DNS servers. See the arguments on centralization in the introduction.
+
+# DNSSEC is de-facto mandatory
+
+While DNS is complex, adding DNSSEC makes it even more complex. 
+However, to protect against wrong DNS answers by byzantine recursors, DNSSEC will be de-facto mandatory for a secure ECH protocol.
 
-The default fallback to cleartext SNI undermines security goals when ECH is unavailable.
-(XXX reference... proof! XXX)