Merge pull request #5 from certtools/main

publish intermediate version

Author: aaronkaplan

ai-gen-report/claude-sonnet-4-on-rfc9460.md

@@ -39,9 +39,9 @@ example.com. IN HTTPS 1 . ech="ATTACKER_CONTROLLED_KEY"
 **Severity: High**
 
 **Attack Vector:**
-- Network intermediaries selectively drop SVCB/HTTPS queries
+- Network intermediaries selectively drop SVCB/HTTPS queries or connections to DoH/DoT servers
 - Clients fall back to cleartext SNI when ECH configuration unavailable
-- As noted in draft-ietf-tls-esni-24: "an active attacker could mount a downgrade attack by denying the user access to the SvcParams"
+- As noted in RFC9460: "[an active attacker could mount a downgrade attack by denying the user access to the SvcParams](../RFC-drafts/rfc9460.txt)"
 
 **Technical Details:**
 From the specification:
@@ -114,7 +114,7 @@ From draft-ietf-tls-wkech-07:
 **Attack Vector:**
 - ECH only provides privacy within servers sharing same configuration
 - Traffic analysis can identify target with probability 1/K where K is anonymity set size
-- Timing, packet size, and flow characteristics leak information
+- Timing, packet size, and flow characteristics might leak information
 
 **Technical Details:**
 From draft-ietf-tls-svcb-ech-07:

mkdocs.yml

@@ -5,16 +5,16 @@ site_dir: build/
 
 nav:
   - Home: index.md
-  - About: about.md
   - Scope: scope.md
+  - Intended audience: intended_audience.md
   - Deployment considerations:
       - Overview: deployment/overview.md
       - Incentives: deployment/incentives.md
       - Separation issues: deployment/separation.md
   - Weaknesses: 
       - Complexity: weaknesses/complexity.md
+      - DNS: weaknesses/dns.md
       - WKECH: weaknesses/wkech.md
-      - DoH/DOT: weaknesses/dependency_on_doh.md
       - Others: weaknesses/others.md
   - Clients considerations: 
       - Browsers: clients/browsers.md

report/about.md

@@ -4,8 +4,8 @@ Various existing research on this
 
 "Encrypted (Network) Traffic Classification"
 
-* https://www.sciencedirect.com/science/article/pii/S2090447923002502
-* https://ieeexplore.ieee.org/document/8622812
-* https://www.mdpi.com/2073-8994/13/6/1080
+* <https://www.sciencedirect.com/science/article/pii/S2090447923002502>
+* <https://ieeexplore.ieee.org/document/8622812>
+* <https://www.mdpi.com/2073-8994/13/6/1080>
 
 Does *not* depend on unencrypted SNI!

report/attacks/correlations.md

@@ -2,8 +2,8 @@
 
 ## RU
 
-* Russia disallowing CDNs in order to block ECH: https://github.com/net4people/bbs/issues/417
-  * https://therecord.media/russia-blocks-thousands-of-websites-that-use-cloudflare-service
+* Russia disallowing CDNs in order to block ECH: <https://github.com/net4people/bbs/issues/417>
+  * <https://therecord.media/russia-blocks-thousands-of-websites-that-use-cloudflare-service>
 
 ## CN
 
@@ -15,7 +15,7 @@
 ## KR
 
 - Blocking by SNI:
-	- https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/
-	- https://www.technadu.com/south-korea-extend-site-blocking-snooping-sni/58125/
+	- <https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/>
+	- <https://www.technadu.com/south-korea-extend-site-blocking-snooping-sni/58125/>
 - Workaround: VPNs and ESNI
 	- ESNI was removed from browses, ECH follows but harder to adopt

report/censorship.md

@@ -23,7 +23,7 @@ SOCKS, HTTPS
 Downloaded via HTTP but signed by the CA
 Blocking the access to the lists is possible with packet inspection due to the traffic being unencrypted
 Browser soft-fail by default
-OCSP is dead: https://letsencrypt.org/2022/09/07/new-life-for-crls/
+OCSP is dead: <https://letsencrypt.org/2022/09/07/new-life-for-crls/>
 Work ongoing to fix these issues
 
 ### QUIC and SPDY

report/clients/browsers.md

@@ -1,5 +1,10 @@
-ECH currently not supported, as the Firefox base requires DoH for ECH and TOR disables DoH for privacy reasons.
+# TOR Network
 
-- Reasoning why DoH is not used: https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/6GDO7CYEFIKID7QQCRVYVFNIVETWWWWY/#6ZBFGNSRPWRCEO7PVPSHHVLAOGF7KN3C
-- Discussion on DNS over HTTPS (DoH): https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30753
-- Discussion on ECH: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42144
+Currently, Encrypted ClientHello (ECH) is not supported on the TOR network, primarily because the Firefox foundation mandates the use of DNS over HTTPS (DoH) for ECH functionality, while TOR disables DoH in order to uphold user privacy.
+TOR’s architecture is designed to enhance security and privacy, which mitigates the necessity for the additional layers that DoH and ECH provide. By operating through a decentralized network of volunteer-run relays, TOR ensures that user data remains obscured from potential surveillance.
+Contrary to Do53 and DoH, TOR employs an alternative approach, utilizing DNS over the TOR network and subsequently through the exit node.
+TOR inherently addresses the concerns that both DoH and ECH aim to resolve, particularly through its TOR onion services.
+
+- Detailed explanation on TOR's non-usage of DoH can be found here: <https://lists.torproject.org/mailman3/hyperkitty/list/[email protected]/thread/6GDO7CYEFIKID7QQCRVYVFNIVETWWWWY/#6ZBFGNSRPWRCEO7PVPSHHVLAOGF7KN3C>
+- Discussion on DNS over HTTPS (DoH) in TOR: <https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30753>
+- Discussion on Encrypted ClientHello (ECH) in TOR: <https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42144>

report/clients/tor.md

@@ -1,32 +1,38 @@
 # Deployment Incentives
 
-which medium size hoster could benefit from ECH?
-what are the incentives?
+As mentioned in the [overview](../index.md) section, we see a game-theoretic problem: most organisations which host web services might not have the proper incentives to protect the client's privacy without additional rewards: they have no incentive to do so. Instead, managing the complex ECH setup, adds additional business continuity risks. 
+
+Therefore, this section looks at organizations which could have an interest in deploying ECH.
 
 ## Anti-Censor and Anti-Oppression
 
-Whistle-blower platforms, human rights organisations
+Various organizations that address humans in countries and regions with oppression and legal pressure, like human rights organisations have an interest in protecting their website vistors' identity and thus using ECH as well as protect their website behind CDNs to reduce the risk of de-anonymization by traffic correlation analysis.
 
-## Malware - C2 operators
+In all regions, the same applies to whistle-blower platforms which are possible under close observation by political, legal or corporate organizations.
 
-`ClientHello` and TLS Metadata (cipher suite lists, advertised extensiond) is used to identify malware-generated traffic: https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption
+## Malware - C2 operators
 
-C2/malware operators implementing ECH could hinder these traffic-analysis.
+Unencypted SNI/Client Hello and TLS Metadata (cipher suite lists, advertised extensions) are being used to identify malware-generated traffic, e.g.: <https://blogs.cisco.com/security/detecting-encrypted-malware-traffic-without-decryption>
+Therefore operators of malware networks have an interest in staying stealthy and thus implementing ECH. Consequently, this will hinder these traffic-analysis.
 
 Currently, the usage of ECH is very low and thus in itself suspicious. To hide their ECH traffic, malware operators may be inclined to increase the general usage of ECH.
 
 ## Pornography industry
 
- Starting with February 2019, South Korea started blocking TLS-encrypted traffic to sites forbidden by the policies, most prominently pornography.
- The porn industry being blocked has therefore a business case for using ECH, enabling them to reach customers in an entire 50-million-inhabitant country.
+Starting with February 2019, South Korea started blocking TLS-encrypted traffic to sites forbidden by the policies, most prominently pornography.
+The porn industry, being blocked, has therefore a commercial interest in using ECH, which allows them to reach customers in an entire 50-million-inhabitant country.
 
 - [South Korea to Extend Site Blocking by Snooping on SNI - technadu.com, August 1st, 2021](https://www.technadu.com/south-korea-extend-site-blocking-snooping-sni/58125/)
 - [South Korea is Censoring the Internet by Snooping on SNI Traffic - Bleepingcomputer.com, Fe-bruary 13th, 2019](https://www.bleepingcomputer.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/)
 
 ## CDNs
 
-No business model for split mode, but for shared mode if the customer pays additionally for it -> centralization
+CDNs can offer their customers ECH (shared mode) as part of their offerings, selling them a privacy feature for low internal costs as they profit highly from scaling effects.
+For website owners that want to protect their visitors and offer them enhanced privacy, it is much easier and cheaper to go to CDNs than to operate ECH on their own, given the high complexity and costs. A equivalent effect is in progress since about 15 years in the email sector. As operating email services safely got increasingly complex and difficult, more and more organizations outsourced their email infrastructure to large email service providers.
+
+For ECH's split mode the business incentive is lower than for shared mode.
 
-## Small and medium size hosters
+## Small and medium size hosters, NRENs
 
 only a customer requesting it? won't happen
+which medium size hoster could benefit from ECH?

report/deployment/incentives.md

@@ -1,54 +1,54 @@
 # Deployment considerations
 
-This section addresses ECH deployment considerations. Where relevant, it will link to subsequent sections which details possible attacks against the protocols.
+This section explores ECH deployment considerations. Relevant links to additional sections will be provided, detailing potential attacks against the protocols.
 
-## Process overview
+## Process Overview
 
-This is a simplified overview of the workflow involved in the browser opening an ECH-protected website.
+The following is a streamlined overview of the workflow involved when a browser accesses an ECH-protected website.
 
 
 ![WKECH flow](wkech-flow.png)
 
-### Client process
+### Client-side Process
 
 <ol>
-<li style="list-style: upper-roman;">To request a website, the browser first queries the A/AAAA record and the ECHConfig from the configured DoH/DoT server. The DoH/DoT server is either provided by the network owner or by a large CDN.</li>
-<li style="list-style: upper-roman;">The DoH server queries the information at the autoritative DNS server via DNS, managed by the website operator.</li>
-<li style="list-style: upper-roman;">The information is sent from the DNS server to the DoH server and potentially cached.</li>
-<li style="list-style: upper-roman;">The information is passed on to the client</li>
-<li style="list-style: upper-roman;">Using the A/AAAA record and the ECHConfig, the browser requests the website from the web server</li>
+<li style="list-style: upper-roman;">To initiate a website request, the browser first queries the A/AAAA records and the ECHConfig from the designated DoH (DNS over HTTPS) or DoT (DNS over TLS) server. This server may be provided by the network operator or a prominent Content Delivery Network (CDN).</li>
+<li style="list-style: upper-roman;">The DoH server then queries the authoritative DNS server for the required information, which is managed by the website operator.</li>
+<li style="list-style: upper-roman;">Once retrieved, the information is relayed from the authoritative DNS server to the DoH server, potentially being cached for future requests by this or other clients.</li>
+<li style="list-style: upper-roman;">The DoH server subsequently transmits the information to the client.</li>
+<li style="list-style: upper-roman;">Utilizing the A/AAAA records and the ECHConfig, the browser sends a request to the web server to access the designated website.</li>
 </ol>
 
-The DoH servers query the autoritative DNS servers mostly via traditional unencrypted UDP-based DNS (Do53), however DoT and DoH are increasingly adopted in this area too. Protocol upgrades (opportunistic or via SVCB records) are also used.
+Typically, DoH servers communicate with authoritative DNS servers using traditional unencrypted UDP-based DNS (Do53). Nonetheless, the adoption of DoT and DoH protocols is on the rise. Additionally, various protocol upgrades (either opportunistic or through SVCB records) are employed.
 
-### Server process
+### Server-side Process
 
-1. The server (re-)generates the ECH keys in a defined interval (e.g. every 1 hour) for each configured domain
-2. The server publishes the public ECH keys in the WKECH directories for each domain
-3. The Zone Factory (ZF) requests the ECK keys for each configured domain in a configured interval (e.g. more often than 1 hour)
-4. The Client-Facing Server (CFS) answers with the ECH keys
-5. The ZF pushes the generated ECHConfig to the DNS server
+1. The server regularly regenerates the ECH keys at defined intervals (for example, every hour) for each configured domain.
+2. The server publishes the corresponding public ECH keys within the WKECH directories for every domain.
+3. The Zone Factory (ZF) requests the ECH keys for each designated domain at pre-established intervals (preferably more frequent than once per hour).
+4. The Client-Facing Server (CFS) responds with the requested ECH keys.
+5. The ZF subsequently pushes the generated ECHConfig to the DNS server.
 
 ## Webserver configuration
 
-- Which component creates the ECH keys with the correct parameters?
-- Which component rotates them, and reloads the webserver?
-- and creates (or serves) the wkech directory, ensuring that only the pubkeys are exposed, not the private keys
-- Triggering the ZF after every rotation (running separately, on another host)
-- documentation: https://github.com/defo-project/ech-dev-utils#user-content-server-details
+- Which component is responsible for generating the ECH keys with the appropriate parameters?
+- Which entity handles the rotation of these keys and reloads the web server configuration?
+- What component creates (or services) the WKECH directory, ensuring only public keys are exposed and private keys remain secure?
+- How is the ZF triggered after each key rotation, ideally operating separately on a different host?
+- For documentation, refer to: <https://github.com/defo-project/ech-dev-utils#user-content-server-details>.
 
-## Complexity of configuring the Zone Factory
+## Complexity of Configuring the Zone Factory
 
-The ZF needs to know
-1. which well-known sites (`wkech`) to look at
-2. when to refresh the keys (or in a fixed interval)
-3. which zone files (located on which server) need to be updated
+The ZF must be aware of the following:
 
-The ZDF needs write access to the zone file and needs to be able to reload the nameserver.
-All of this flow is non-trivial for a sysadmin to configure and add possible steps which may break.
+1. Identifying well-known sites (`wkech`) to monitor.
+2. Establishing a refresh schedule for the keys (either on a fixed interval or responsive to activity).
+3. Knowing which zone files (housed on which servers) require updates.
 
-This sections looks at what could go wrong in case of misconfigurations or malicious attacks.
+The ZF requires write access to the zone files and must have the capability to reload the nameserver configuration. This setup is non-trivial for a systems administrator, as misconfigurations or oversights can introduce complications.
 
-WKECH directory must be secured: Only public keys, not private keys
+It is imperative to secure the WKECH directory: it must contain only public keys, be immutable (including to any aliases), and limit access solely to the web server itself. For more information, please refer to the section on [WKECH](../../weaknesses/wkech.md).
 
-...
+## DNSSEC implementation
+
+Implementing DNSSEC (Domain Name System Security Extensions) is crucial to enable clients to validate ECH-enabled domains. This not only enhances the integrity of the DNS responses but also mitigates the risk of resolvers inadvertently blocking SVCB or ECH parameters. Ensuring robust DNSSEC configuration can significantly bolster the security framework associated with ECH implementations, fostering trust and reliability in web communications.

report/deployment/overview.md

@@ -6,6 +6,10 @@ CFS and DNS can be in separate networks with firewall rules preventing any outgo
 
 ### Process separations
 
+In large organisations we often observe that different teams are responible for different tasks. ECH deployments require that at least the team for DNS (ZF) and the team responsible for hosting services talk to each other. We are not commenting on how often this might be a problem.
+
+In addition, some organisations have to deal with IT security reuglation standards (ISO certification, NIS2 law in Europe), might might impact the way how ECH is being deployed (which team does what, documents what, etc.). Since deployments of ECH pose new questions, we can't yet fully assess the impact of regulations on deployements. However, it is worth keeping an eye on so that future revisions of the ECH drafts can be deployed easier for organisations facing tight regulations.
+
 ### Organizational separations
 
 In the same way as a lot of IT services are outsources (web, e-mail, etc.) DNS Servers may be operated by third parties, e.g. a registrar, a DDoS protector etc. Thus, there is no direct access via SSH to the server administration, but rather via websites and APIs.