Hi Nick, Big thanks for so many efforts! But you underestimate how big the guns of some governments are. I am not an expert on sanctions but inevitably know a little about this topic. In addition to sanctions, there are "secondary sanctions". It is a situation when the government that "should not be mentioned" frighten by sanctions any legal entity on the planet helping to bypass the original sanctions. In your case below, the officer of the respective agency would call the Browser_Vendor office and ask to immediately delete the particular IP-CA pairs from the SECURE MIRROR BOOTSTRAP file that could be traced through a chain of SECURE MIRRORS to the target SECURE MIRROR, Then some SECURE MIRRORS could be reconnected back when they confirm manually that they have no downstream trace to the target SECURE MIRROR. The officer would ask the Browser_Vendor to automate trace to the target SECURE MIRROR for the future, and trace it manually meanwhile. If the target SECURE MIRROR would be in the chain for too long, you could guess what would happen to the CEO of the Browser_Vendor. All trust chains that is possible to invent start from form some human who should do something manually. This human is very vulnerable to electricity, soldering iron and many other things. Hence, only something decentralized like blockchain could help for real independence from governments. PS: DNSSEC does not make sense - governments do much bigger harm than criminals. Believe me, I know. Eduard -----Original Message----- From: Nick Lockheart <lists@xxxxxxxxxxxxxx> Sent: Thursday, August 15, 2024 02:30 To: ietf@xxxxxxxx Subject: Near-Real-Time TLS and DNS Validation using a Multi-Vantage-Point Network of Secure Mirrors Near-Real-Time TLS and DNS Validation using a Multi-Vantage-Point Network of Secure Mirrors ** A THOUGHT EXPERIMENT ** The following is a thought experiment I've been working on, with the goal of allowing websites to use TLS Certificates signed by their own organization, without the need for 3rd-party Certificate Authorities to ship with browsers, and without the need for cryptographically-secured DNS. These are the criteria: (1) Each organization manages its own Public/Private CA key pair. (2) Each organization signs the TLS Certificate for its own services using its own organization's CA. (3) A web browser ships with *no* CAs pre-installed, except for its own vendor CA. (4) The DNS system is *not* cryptographically-secure. It is mostly honest, but not to be completely trusted. (5) Each domain registrant publishes a set of special DNS records which identify the fingerprint of the Certificate Authority authorized to sign Certificates on behalf of that (sub)domain. Problem: If we can't rely on DNSSEC, how could we bootstrap a TLS security model that allows arbitrary, unknown CAs to sign Certificates for websites? ** INVERTING DANE ** With DANE and DNSSEC, the logic goes: if the DNS record is signed by a trusted authority, then the browser can trust the DNS records that identify an unknown Certificate Authority. But this logic works the other way, too. If the browser already knows the fingerprint of the CA Certificate used by example.com, but the browser does not know the IP address, and the browser does not trust the DNS system, then, if the browser asks the untrusted DNS for a resolution of example.com, and the browser gets an IP address from the DNS, and the browser does a TLS handshake with the server at that IP address, the browser can check the fingerprint of the server's Certificate and know if the DNS was honest. Or in other words, cryptographically-secure DNS could verify a Certificate Authority, but a Certificate Authority could verify insecure DNS. Thus, the real problem is: how can we bootstrap trusted information into the browser? ** A BOTTOM-UP TRUST CHAIN ** We need a chain of trust, but it doesn't need to be top-down, it could also work bottom-up. We could build a trust model that works the other way around. Consider this example: I don't want to pick on anyone, but it's easier to explain if we use absolute names here, so let's use Firefox as an example. The Mozilla Foundation rolls its own CA. This CA key pair is internal to Mozilla, and doesn't need signed or approved by anyone. Mozilla uses the Mozilla Foundation's CA to sign all of the server Certificates for their own services. This Mozilla CA does not sign anything other than services owned by Mozilla. Mozilla places the public CA Certificate of the Mozilla Foundation into all of their browsers. This is the *only* CA Certificate that comes with the browser. Right now, the newly installed browser trusts no one. On first run, this happens: The browser makes a DNS request for mozilla.org and gets an IP Address from local DNS. This DNS response is not trusted. The browser establishes a connection to the IP address that it just got, and does a TLS handshake. The Certificate returned from the server is signed by the Mozilla Foundation's CA. Since the Mozilla Foundation's CA is already known to the browser, the browser now trusts that it is talking to the real mozilla.org server. This creates a secure channel from the browser to the browser vendor, which I will call BROWSER SECURE CHANNEL. This BROWSER SECURE CHANNEL allows the browser to bootstrap trust from the bottom up, starting by trusting itself, then by trusting its vendor. ** BUILDING OUT TRUST ** BROWSER SECURE CHANNEL lets the browser update itself from the browser vendor, but it also allows the browser to request something called a SECURE MIRROR BOOTSTRAP file. This file, requested only once when the browser is first installed, contains a hash/map of IP addresses and CA Fingerprints. There would be about 100 IP-CA pairs in this file. Each pair represents the identify of a SECURE MIRROR. The bootstrap file is not an exhaustive list of SECURE MIRRORS. It is only a small subset used for bootstrapping. Once the browser has the SECURE MIRROR BOOTSTRAP file, it will contact the SECURE MIRRORS on the list by their IP addresses, confirm that the CA fingerprint in the TLS handshake matches, then, if the server is validated by its CA fingerprint, the browser requests a SECURE MIRROR LIST from that SECURE MIRROR. The SECURE MIRROR LIST is much larger than the SECURE MIRROR BOOTSTRAP file, and contains IP-CA pairs for substantially more SECURE MIRRORS. The SECURE MIRRORS in this file are also grouped by region code. The browser compares the SECURE MIRROR LISTS it receives from the multiple SECURE MIRRORS it found in its SECURE MIRROR BOOTSTRAP file, and makes a master list based on consensus. This process occurs only once on browser install, and perhaps periodically, such as when the browser version updates. ** VALIDATING A CA ** I will come back to the question of exactly what a SECURE MIRROR is, how the browser vendors know about them, and how they are validated later. For now though, the browser has a HASH of SECURE MIRRORS, organized by region, that it can call via IP address, and verify by CA fingerprint. At this point, we can think of a SECURE MIRROR as a DNS proxy, but they are more than that, which we will get to in a bit. Now the user visits example.com in their browser. The browser will do several things in *parallel*: (1) The browser will make a local DNS request for example.com's A record. (2) The browser will select three random SECURE MIRRORS from its pre- built HASH, each from a different region, and query them for example.com. (3) Once a local DNS record is returned, the browser will do a TLS handshake with the IP Address that is supposedly for example.com, per local DNS. Because the above actions happen in parallel, by the time the browser has its A record from local DNS and has started the TLS handshake, it should have responses from the three SECURE MIRRORS with CA information from the DNS servers that each SECURE MIRROR queried. Because the connections to the SECURE MIRRORS by the browser are based on IP, it is not subject to local DNS poisoning. Further, the SECURE MIRROR'S Server Certificate must be signed by the CA that is in the browser's SECURE MIRROR HASH for that IP Address. The browser must pick SECURE MIRRORS from different regions for each requested domain. The browser now has: (1) The local DNS record with the A record for example.com, and the local DNS record for example.com's CA information. (2) SECURE MIRROR #1's DNS response, from its network vantage point, which also has an A record and CA information. (3) SECURE MIRROR #2's DNS response, from its network vantage point, which has an A record and CA information. (4) SECURE MIRROR #3's DNS response, from its network vantage point, which has an A record and CA information. (5) example.com's Server's Certificate and the Server's CA's Public Certificate (and their corresponding fingerprints). Now, the browser can compare the DNS records (did all the A records from the three SECURE MIRRORS match local DNS?) and the CA info (did all the SECURE MIRRORS report the same CA fingerprint as authorized to sign example.com's certificate?) If all the fingerprints match, and all the A records match, the browser trusts the CA and the IP. ** HOW SECURE IS THIS? ** Let's Encrypt is considered very secure. Let's look at how they validate domain ownership with the ACME protocol. When a Certificate Signing Request comes in, the ACME server gives the requester a random code that must be placed either in the domain's DNS records, or on the website at a special URL. We'll look at the DNS option here. Let's Encrypt does not rely on DNSSEC, but rather on multiple DNS proxies querying DNS records from multiple network vantage points. If the multiple vantage points agree, the DNS record is deemed canonical. The process described in the previous sections works in exactly the same way: querying multiple DNS proxies from multiple network vantage points to obtain consensus. But, instead of an ACME server making those queries, it's the browser making the queries, and the browser is verifying both the A records and the TLS CA's fingerprint at the same time. Because SECURE MIRRORS are queried by IP Address, and verified by CA fingerprint, they are resistant to local DNS poisoning. As far as domain validation goes, this is arguably more secure than Let's Encrypt, because it is done in near-real-time, which means a revocation is also near real-time. Additionally, this method also verifies the A record for the server. (I'm not trying to pick on Let's Encrypt, I'm merely using a model that is considered secure for comparison, and pointing out how an alternative can provide both greater security, and more openness on the Internet.) ** HOW FAST IS THIS? ** Writing out a detailed process like this makes it seem slow. But since the browser's request for information from SECURE MIRRORS happens at the same time as the normal DNS lookup, and in parallel, this should not add time to the page load. ** WHO OWNS THE SECURE MIRRORS? ** Everybody with an interest or stake in the Open Internet is invited and encouraged to operate their own SECURE MIRROR as part of a world-wide SECURE MIRROR NETWORK. This includes: (1) Corporations (2) Non-profits (3) Governments(*) (4) Universities (5) Individual Enthusiasts (*) - Government run SECURE MIRRORS are equal peers in the network and have no more or less authority than any other SECURE MIRROR. The requirements to operate a SECURE MIRROR are only technical, never political. SECURE MIRRORS can be written in any programming language that can implement the SECURE MIRROR PROTOCOL. Ideally, these implementations would be FLOSS software that anybody can install and run on their own server. To be a SECURE MIRROR in good standing, the SECURE MIRROR must: (1) Have a dedicated IP Address. (2) Have a registered domain name. (3) Have an Average Ping Time to the next closest SECURE MIRROR under a threshold. (4) Have a Request Response Time under a threshold. (5) Have 99.9% uptime. (6) Not deny any requests (cannot be behind an application firewall with CAPTCHAs, for example). (7) Have a very low percentage of DISSENTS. (A DISSENT occurs when one SECURE MIRROR returns results that differ from the other two. This can occur during DNS propagation.) There should be thousands of SECURE MIRRORS, if not more. Each entity is allowed to operate only one SECURE MIRROR. A large tech company may operate many servers behind a load balancer, but this is considered one SECURE MIRROR. The purpose of this rule is to ensure that each stakeholder gets only one "vote" in the SECURE MIRROR NETWORK. A SECURE MIRROR must implement the SECURE MIRROR PROTOCOL, which is both a server and client protocol for a RESTful API, accessed only via HTTPS. Each SECURE MIRROR should have its own Certificate Authority, and use that Certificate Authority to sign that SECURE MIRROR'S Server Certificate, and nothing else. The fingerprint of the SECURE MIRROR'S Certificate Authority is tied to that SECURE MIRROR'S reputation in the SECURE MIRROR NETWORK. ** JOINING THE NETWORK ** Any new SECURE MIRROR can join the SECURE MIRROR NETWORK by: (1) Provisioning a server that implements the SECURE MIRROR PROTOCOL. (2) Setting up a Certificate Authority to sign (only) that SECURE MIRROR'S Server Certificates. (3) Sending a Join Network Request to any other SECURE MIRROR. The SECURE MIRROR NETWORK must be fully automated, and provide utilities for established SECURE MIRRORS to vet new candidates, and also, to test and rate other established SECURE MIRRORS for performance and accuracy. No SECURE MIRROR can be blacklisted by any SECURE MIRROR operator. It should be very easy to join and remain a part of the SECURE MIRROR NETWORK. Your server must be fast and honest. That's all. All Join Requests received by a SECURE MIRROR must be accepted. The new SECURE MIRROR becomes identified to the SECURE MIRROR NETWORK by its CA fingerprint. The SECURE MIRROR receiving the Join Request must forward the identification of the new SECURE MIRROR to a certain number of peers. Each peer will perform automated tests against the new SECURE MIRROR candidate for speed and accuracy. Upon passing the tests over a reasonable period of time, the new SECURE MIRROR'S identification will be forwarded again to more peers, who repeat this process. The tests are replays of requests that the established SECURE MIRRORS have recently processed, that are sent to the new SECURE MIRROR, to see if it agrees with the expected DNS results, and responds in a timely manner. New SECURE MIRRORS will propagate this way. ** BROWSER REPORTS ** In addition to peer verification, the browser will also play a role in SECURE MIRROR NETWORK integrity testing. After the browser has verified a domain's A record and CA using the SECURE MIRROR NETWORK, the browser will, after loading the page, and without blocking, send a background report back to each of the SECURE MIRRORS that it queried. All three SECURE MIRRORS will get all three result sets and the identify of the SECURE MIRRORS that produced those results. Each SECURE MIRROR will process this result set as follows: If the other SECURE MIRRORS agreed, their reputation will increase. (Reputation is local to each SECURE MIRROR). If a SECURE MIRROR DISSENTED, a DISSENT is logged against the DISSENTING SECURE MIRROR. If the SECURE MIRROR listed in the report is not known to the SECURE MIRROR receiving the report, the SECURE MIRROR receiving the report should treat this as a Join Network request, and begin testing and propagating the unknown/new SECURE MIRROR. This offloads some of the workload of testing and propagating SECURE MIRRORS to the browsers, making them part of the SECURE MIRROR NETWORK, too. ** REMOVING A SECURE MIRROR ** Each SECURE MIRROR maintains a reputation of every other SECURE MIRROR known to it. The reputation is not propagated. Reputation is affected only by: (1) Average Ping Time. (2) Average Response Time. (3) Number of Dissents vs. Agreements. Should it become known to a SECURE MIRROR, that another SECURE MIRROR is not performing fast enough or is often inaccurate, the noticing SECURE MIRROR will send a Remove Request to several other peer SECURE MIRRORS. Those peer SECURE MIRRORS will perform tests over a period of time to see if they agree. After the tests are complete, those SECURE MIRRORS will respond to the SECURE MIRROR initiating the test with their agreement that the allegedly-non-performant SECURE MIRROR should be removed, or disagreement. The SECURE MIRROR requesting that its peers perform tests shall conform to the majority opinion of the test-performing peers, and remove or not remove the allegedly-non-performing SECURE MIRROR. Removal propagates, with each SECURE MIRROR doing its own tests of the removal candidate, and voting in a local peer cluster. Removed SECURE MIRRORS are not actually deleted, but marked as inactive due to test failure. Removed SECURE MIRRORS can be reactivated simply by passing a series of peer-initiated tests successfully. True removal only occurs if a SECURE MIRROR goes completely offline and is unresponsive for a long period of time (ie. decommissioned). The operator of a SECURE MIRROR that has been removed for slow performance or inaccuracy should be notified. The operator can request readmission by making a new Join Request after taking any corrective measures to fix speed or accuracy of thier implementation. ** SECURE MIRROR PROTOCOL ** This is not meant to be an exhaustive description of the protocol, rather, it is a brief overview of the functionality of a SECURE MIRROR. A SECURE MIRROR performs the following functions: (1) Answer DNS Request - The SECURE MIRROR runs a DNS query from it's vantage point and returns the result, to the browser or to the peer SECURE MIRROR making the request. (2) SECURE MIRROR LIST Request - The SECURE MIRROR returns a list of all other SECURE MIRRORS that are known to it, to the browser or to a peer SECURE MIRROR making the request. (3) Join Request - The SECURE MIRROR accepts a request from a newly created SECURE MIRROR wishing to join the SECURE MIRROR NETWORK. (4) Remove Request - A peer SECURE MIRROR asks this SECURE MIRROR to audit an allegedly non-performant SECURE MIRROR and vote on its speed and accuracy. Outgoing Requests: (5) Peer Verify - The SECURE MIRROR will "quiz" a peer by requesting the same data that it just provided to a client, and comparing the peer's response to its own. This is part of a Join and Remove request process, but could also be a randomly triggered event for health and safety integrity checking. ** FURTHER USES OF THE NETWORK ** This SECURE MIRROR NETWORK could also be used to verify MX records and TLS Certificates for SMTP relays, as well as to bootstrap TLS trust for a desktop or mobile operating system for system-wide usage. This protocol could also ultimately be expanded to be a DNS verification system. ** BENEFITS ** This model provides many benefits over the current model. (1) Browsers and other systems no longer trust a Certificate Authority to sign on behalf of every website or service on the Internet. Only the organization operating the service can sign its Certificates. (2) Because browser verification happens in near-real-time, Certificate Revocation Lists (CRLs) are obsolete. (3) In the event of a CA data breach, the damage is limited only to the organization that was breached. (4) In the event of a CA data breach, the CA can be immediately revoked, world-wide, by the CA's organization updating a single DNS record. The revocation happens as fast as DNS propagates. (4) A breached organization can issue itself a new CA, sign new Certificates, update its DNS records, and be back online as fast as DNS can propagate. (5) The Internet is held in trust by everyone. This model is an alternative to DNSSEC. "Governments" and "Corporations" are just proxies for humans. The people running them change over time. Respectfully, I believe that it is folly to give the "keys to the Internet" to a single person (by proxy though government or organization). A peer-to-peer consensus-based DNS security system provides the same assurance as DNSSEC, but is built on a system where every stakeholder on the Internet collectively owns it. This is essentially an agreement that no one should control the Internet, and makes it impossible for any rouge government, large corporation, and any other actor or stakeholder to unilaterally change the foundation of the Internet without the consensus of all of the Internet's stakeholders. ** CONCLUSION ** I am aware that I have omitted many small technical details. Some, I have thoughts on, and some, I would welcome the feedback of experienced software architects and network engineers in solving. I have omitted these details here, as this post is intended to explain a high-level concept, rather than become a full draft of an RFC. I welcome constructive feedback on this proposal. - Nick Lockheart
