publish

README.md

@@ -4,6 +4,9 @@ Security analysis of the defo2 project + HOWTO for web admins
 
 Rendered version: https://certtools.github.io/defo-security-analysis/
 
+PDF Version: https://certtools.github.io/defo-security-analysis/document.pdf
+
+
 ## Deliverable text
 
 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.
@@ -40,10 +43,7 @@ cd report
 mkdocs serve
 ```
 
-Note well: we publish the documentation under github pages.
+or just ``make build && make serve``
 
-## Table of contents
+Note well: we publish the documentation under github pages.
 
-- [Overview what we are going to analyse](analysis_plan.md)
-- [Clients](Clients.md) -
-- [Weaknesses in ECH in combination with WKECH](wkech-considerations.md)

report/clients/browsers.md

@@ -4,10 +4,10 @@ Modern web browsers are notably permissive toward emerging standards, often prio
 
 The browser Firefox adopted DoH as their default setting, reverting back to Do53 should a DoH connection fail to establish.
 The Browsers Chrome and Edge use DoH if the system's default resolver supports it.
-Opera, Brave and Vivaldi do not use DoH by defaut.
+Opera, Brave and Vivaldi do not use DoH by default.
 
 DoH connection failures can arise from active downgrade attacks, where malicious entities intercept and manipulate traffic.
-Consequently, the usage of ECH can be silently thwarted if an attacker holds sway the network path between the user and the intended DoH server or between recursive and autoritative DNS server.
+Consequently, the usage of ECH can be silently thwarted if an attacker holds sway the network path between the user and the intended DoH server or between recursive and authoritative DNS server.
 An attacker with control over the network connection can though also block TLS and other security measures, but not without alarm bells going off in the browser and other clients.
 
 For the implementation of ECH, attention must not only be paid to pure HTTPS traffic but also to other communication channels such as WebRTC and network proxies, as neglecting ECH on these channels can introduce ways for de-anonymization.

report/index.md

@@ -39,7 +39,7 @@ This "skeptical"/outside view helps to ask hard questions and identify potential
 
 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.
+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, implementers, 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: