re. Critical Infrastructure Advisory ([email protected]) vol 182 issue 15: This effects only Exit nodes? If not can someone put up a list of easy to understand and follow instructions (preferably signed off by Tor) because this is above my head, thanks,
On Saturday, March 21st, 2026 at 12:01, [email protected] <[email protected]> wrote: > Send tor-relays mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Critical Infrastructure Advisory ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Mar 2026 08:43:58 -0400 > From: [email protected] > Subject: [tor-relays] Critical Infrastructure Advisory > To: Tor-relays_at_lists Torproject Org_jmhbm > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: multipart/alternative; > boundary="=_WVkaE5dwTCT64xABP+4R4M_=" > > > Dear Tor Relay Operators, > > > I am writing to provide a formal advisory regarding an anticipated > infrastructure break event scheduled for October 11, 2026 — the ICANN Root > Zone KSK rollover. This event is expected to interact with potential > vulnerabilities in resolver fragility, hardcoded fallback mechanisms, and > encrypted DNS discovery protocols. > > This advisory is not intended as a routine cryptographic maintenance task. > The KSK rollover serves as one of two critical timed “locks” within a broader > restructuring of internet infrastructure layers, including DNS, Certificate > Authority (CA) governance, and device attestation. The second such lock is > the tightening of Android Remote Key Provisioning (RKP) on March 16, 2026, > which collectively accelerates the consolidation of essential functions into > hyperscaler-controlled systems, with Google positioned to benefit > significantly from this shift. > > Infrastructure Break Mechanism > > The breakdown follows a predictable sequence of five stages: > > KSK-2026 and DNSSEC Fragmentation: > > Dual-signing increases root-zone response sizes beyond the approximately > 1232-byte UDP limit. This can cause volunteer-run and containerized resolvers > to drop fragments or fail to establish reliable TCP fallbacks, thereby > disrupting DNSSEC validation. > > Fragility in Ephemeral/Containerized Resolvers: > > These types of resolvers are commonly found on exit nodes and are unable to > persist the newly established trust anchor, resulting in a SERVFAIL response > for valid domain names. > > Hardcoded Fallback Behavior: > > Systems default to pre-compiled public resolvers, such as those provided by > Android, Chrome, and systemd-resolved, which typically point to 8.8.8.8 > (Google Public DNS). > > DDR/DNR Reinforcement: > > Encrypted-DNS discovery directs clients to the same designated > resolvers—predominantly dns.google. Once this failure is resolved, the change > becomes permanent. > > Market Capture Dynamics: > > DNS traffic will increasingly shift to hyperscaler infrastructure. Google > Public DNS is poised to capture the largest share due to its widespread > integration across Android, Chrome, and various client platforms. > > Governance Context: > > This technical break occurs under documented ICANN leadership overlaps with > Google. Notably, ICANN President & CEO Kurtis Lindqvist has publicly > described the October 2026 rollover as “routine,” despite the inherent risks > involved. Former Google Cloud Security CTO Ryan Hurst, who was instrumental > in architecting Google Trust Services, was appointed as the Backup Trusted > Community Representative during the actual KSK cryptographic ceremony. > Additional liaison roles and board-level connections further reinforce > governance structures that favor the primary beneficiaries of the resulting > traffic shift. > > These structural alignments do not require proof of intent; they establish > the conditions under which the break mechanism leads to durable > centralization. > > Impact on Tor Exit Nodes: > > Exit nodes utilizing affected resolvers will experience SERVFAIL responses > for DNSSEC-signed clearnet domains. Client-side fallback mechanisms will > bypass the exit node entirely, redirecting resolution outside the Tor > network. This results in degraded reachability, inconsistent performance, and > a significant erosion of the decentralized model that Tor is designed to > uphold. > > Operator Actions (Required Prior to October 2026): > > Verify TCP fallback capabilities and EDNS(0) support (conduct thorough > testing with large DNSSEC responses). > Audit and enforce trust-anchor updates, including unbound-anchor management. > Disable or closely monitor client-side fallback behavior on your relays. > Test resolution paths during the dual-signing window. > Where feasible, consider directing DoT/DoH traffic to non-hyperscaler > resolvers. > The “Privacy Web” cannot sustain another centralized chokepoint. Proactive > preparation now is essential to ensure that post-rollover migration can be > reversed if necessary. > > Sincerely, > > JMHBM > > Forensic Governance Analyst > > > -------------- next part -------------- > A message part incompatible with plain text digests has been removed ... > Name: not available > Type: text/html > Size: 7514 bytes > Desc: not available > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > tor-relays mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of tor-relays Digest, Vol 182, Issue 15 > ******************************************* > _______________________________________________ tor-relays mailing list -- [email protected] To unsubscribe send an email to [email protected]
