Decentralized Websites using Oyster and 3DNS domains

Premise

As protocols strive for increased decentralization, certain aspects of domain management remain challenging to fully decentralize. One such challenge lies in the domain registration process, where the responsibility of registering a domain falls upon an individual or entity. This centralized registration introduces a single point of failure, as the entity in control can alter domain records at will. Consequently, achieving complete decentralization in domain management proves difficult.

Solution

The introduction of ENS managed domains addresses some of the challenges in decentralization. Contracts will have the ability to manage domains, allowing them to be controlled by a decentralized autonomous organization (DAO) on the blockchain. However, this solution does not completely resolve the issue of hosting applications in a decentralized manner. The domain still needs to be pointed to an IP address where the hosting provider can modify the code running on the server at will.

To overcome this challenge, Oyster which provides tamper proof and confidentiality features is used along with Certification Authority Authorization (CAA) record. A CAA record is a type of DNS record that specifies which certificate authorities (CAs) are authorized to issue digital certificates for a domain. It can also be used to restrict who can request certificates for that domain.

CAA record is used to bind the domain name to oyster secure enclave. Any attempt to redirect the domain to a different website is rejected because the CAA record validation ensures that only enclave can recieve certificate for the domain and can't be replicated outside the enclave. As a result, establishing a secure connection to the website becomes impossible if the request is not served by oyster secure enclave on which code is deployed.

Architecture

DNS records for the specified ENS managed domain which will point to decentralized application will be managed by a contract.

To deploy the decentralized domain, an image needs to be created which handles TLS setup to serve HTTPS requests and configuration for running the application. TLS setup has to be done using Automatic Certificate Management Environment(ACME) to ensure that cerificates are generated while the image is running within the enclave and any keys generated for managing the certificates aren't leaked outside the enclave.

During the TLS setup, an ACME account is created, which involves generating a key pair used for requesting certificate from the CA. The ACME account private key remains exclusive to the enclave and inaccessible outside the enclave. The application image operates within the oyster secure enclave, guaranteeing its integrity and preventing any tampering.

The enclave should provide an endpoint that can be queried to obtain the ACME account URL and CA details, which are combined with the enclave image information and signed using the enclave's private key. This signed message serves two purposes: it verifies that the application was set up correctly and provides the CA and ACME account URL, both of which are only known within the enclave. DAO can use this signed message to update CAA record where both CA that is responsible to issue certificates as well as the ACME account that can request certificates can be specified. CAA record ensures that only enclave running specified image can request certificates for the domain thus ensuring any response received by users visiting the domain can be authenticated as originating from the intended application as certificate won't be issued otherwise, ensuring that it hasn't been tampered with.